Is RegisterMap updated?

[David Griffiths]

Hi Jini, for that particular case, it just provides a simple way to
reproduce more general problems in SA: first I run a program under gdb
and with the option "-XX:CompileCommand=print,...", then I put a
breakpoint at a particular place that I suspect the stack walker code
has problems with. When the breakpoint hits, I do gcore in gdb and
then have a core file to reproduce the problem with jstack or jdb
using SACoreAttachingConnector etc. In this particular case I just
enter the jdb "locals" command.

The more general thing that I'm doing with the SA code (not sure what
is defined as SA and what is SA-JDI but I think the classes I use are
still there in Java 9, just harder to access) and that I mentioned to
Andrew once and who probably thinks I'm nuts is to use it to
effectively debug a java application under gdb. So it's a bit like the
attaching to a live process situation using the pid (or a core file
for that matter). The nature of our application means that we can't
attach to the normal JDWP agent inside the JVM - we have to use gdb
and cannot modify the state of the running JVM. I know the code I'm
using is a bit fuzzy and imprecise - AMD64CurrentFrameGuess is a prime
example that I've had to improve - but fuzzy is actually enough most
of the time.

Cheers,

David


On Sat, 2 Feb 2019 at 02:51, Jini George <jini.george at oracle.com> wrote:
>
> Hi David,
>
> This got removed in JDK-9 as a part of SA-JDI removal.
> (https://bugs.openjdk.java.net/browse/JDK-8158050). Could you let us
> know as to why are you using SA-JDI ?
>
> Thanks,
> Jini.
>
> On 2/1/2019 9:56 PM, David Griffiths wrote:
> > Had a nice simple little reproduction test, went to try it on Java 9
> > and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has
> > disappeared! Has it gone for good?
> >
> > Cheers,
> >
> > David
> >
> > On Wed, 30 Jan 2019 at 10:38, Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 1/30/19 10:00 AM, David Griffiths wrote:
> >>> I'm not sure this works though for the frame at the top of the stack.
> >>> The pushing of the registers that you mention appears to take place in
> >>> the updateRegisterMap method which is called when getting the sender.
> >>> At the top of the stack the register will be live and not saved
> >>> anywhere?
> >>
> >> No the pushing of the register happens in generated code.
> >>
> >>> Whatever, I'm seeing a NPE caused by a location that has
> >>> WHERE_IN_REGISTER and a register number of 16 that doesn't have
> >>> locationValid set in the map. If I modify createStackValue to check
> >>> valueAddr being null then it avoids the NPE and getLocals then returns
> >>> all the locals except for the one held in a register (the other ones
> >>> are on the stack). Not sure what a register number of 16 equates to on
> >>> x86, is that supposed to correspond to "not set" or something?
> >>
> >> You're not helping.  Are you sure you've got an up-to-date HotSpot
> >> checkout? You're not falling over bug 8217407?
> >>
> >> --
> >> Andrew Haley
> >> Java Platform Lead Engineer
> >> Red Hat UK Ltd. <https://www.redhat.com>
> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671