Suggested improvement to X86Frame.getInterpreterFrameBCI

[David Griffiths]

Hi, I'm new to this mailing list and working on a project that makes use of
the SA classes to get stack traces from a paused in flight JVM (we can't
use JDWP). I have observed that if the top frame is in the interpreter it
reports the BCI and line number incorrectly. This is because
X86Frame.getInterpreterFrameBCI uses the value stored on the stack rather
than the actual live value stored in R13.

I have a patch for this which lets
LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess pass the R13 value to
X86Frame so that the latter can then do:

  public int getInterpreterFrameBCI() {
    Address bcp = addressOfInterpreterFrameBCX().getAddressAt(0);
    // If we are in the top level frame then R13 may have been set for us
which contains
    // the BCP. If so then let it take priority. If we are in a top level
interpreter frame,
    // the BCP is live in R13 (on x86) and not saved in the BCX stack slot.
    if (r13 != null) {
        bcp = r13;
    }
    Address methodHandle =
addressOfInterpreterFrameMethod().getAddressAt(0);

and this fixes the problem.

Does this sound like a good idea and if so should I submit a patch?

Cheers,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181121/67787aec/attachment.html>