getPCDescNearDbg returns incorrect PCDesc

[Doerr, Martin]

Hi David,

re-posting to serviceability mailing list since you're referring to a method from
https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html
 
Best regards,
Martin


-----Original Message-----
From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of David Griffiths
Sent: Mittwoch, 16. Januar 2019 12:08
To: hotspot-dev at openjdk.java.net
Subject: getPCDescNearDbg returns incorrect PCDesc

Hi, I'd like some help please understanding what appears to be a bug in
getPCDescNearDbg. The problem is caused by the fact that the _pc_offset
value stored in a PcDesc is actually the offset of the code contained in
the _next_ PcDesc rather than the current one. I assume it's done like this
so that obtaining stack traces works correctly. At least on x86, the last
instruction in a PcDesc chunk is the callq which means that the return
address pc points to the next PcDesc. Therefore associating the PcDesc
containing the callq with the address of the next PcDesc chunk means that
the matching works in getPCDescAt.

But this causes "off by one" errors in getPCDescNearDbg which appears to
expect the PcDesc getRealPC address to be that of the PcDesc itself rather
than the following one. So you sometimes see incorrect top of stack line
numbers when debugging. (And this would presumably also affect profilers).

I can fix the top of stack issue by changing distance to:

long distance = pcDesc.getRealPC(this).minus(pc) - 1

but this then messes up the line numbers further down the stack because
they are trying to match against return pcs.

Anybody come across this before, is my analysis correct?

Cheers,

David