Is RegisterMap updated?

David Griffiths david.griffiths at gmail.com
Wed Jan 30 10:00:11 UTC 2019


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?

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?

Cheers,

David

On Tue, 29 Jan 2019 at 13:41, Andrew Haley <aph at redhat.com> wrote:
>
> On 1/29/19 11:24 AM, David Griffiths wrote:
> > Hi, in CompiledVFrame.createStackValue there is the following code:
> >
> >       // First find address of value
> >       Address valueAddr = loc.isRegister()
> >         // Value was in a callee-save register
> >         ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber()))
> >         // Else value was directly saved on the stack. The frame's
> > original stack pointer,
> >         // before any extension by its callee (due to Compiler1
> > linkage on SPARC), must be used.
> >         : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset());
> >
> > It appears from what I can make out that for the register case the map
> > is not updated and so valueAddr is null. The only thing I can see that
> > calls setLocation is updateMapWithSavedLink. Seems like it should be
> > possible to return the register value for the frame at the top of the
> > stack though?
>
> It could be, but we don't do that. The registers in the map are those
> pushed onto the stack by generated Java code.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


More information about the serviceability-dev mailing list