Skip to end of metadata
Go to start of metadata

Sometimes it is desirable to examine the state of the Java stack whilst using GDB to step instructions, break on addresses or watch particular variables. These instructions are based on an email sent by Martin Hirzel to the rvm-devel list around 15th September 2003. The instructions have been updated by Laurence Hellyer to deal with native threading and renamed RVM classes.

1) To learn about the stack frame layout on IA32, look at rvm/src/org/jikesrvm/ia32/StackframeLayoutConstants.java

Currently (2009/10/23) the layout is: 
+4: return address
fp -> 0: caller's fp
-4: method id
(remember stack grows from high to low)

2) To learn how to get the current frame pointer and other context information, look at the genPrologue() method in rvm/src/org/jikesrvm/compilers/baseline/ia32/BaselineCompilerImpl.java. It first retrieves the thread register (esi on IA32), which points to an instance of RVMThread, and then retrieve fields from that instance.

3) To find the offset of field RVMThread.framePointer, add the following lines to the end of BootImageWriter.main(String[]):

    // added to get framePointer offset from RVMThread to manually walk stacks in GDB
    say("offset of RVMThread.framePointer== " + ArchEntrypoints.framePointerField.getOffset());

Do a build to print this info. On my config I got +148, but this can change between versions

4) To get started, let's examine an example stack that contains methods whose code is in the boot image. We pick one that is likely to be invoked even in a simple hello-world program. In my RVM.map, 0x351eae9c is the address of org.jikesrvm.mm.mmtk.ReferenceProcessor.growReferenceTable();

5) Setting a break point on this address

(gdb) break *0x351eae9c
Breakpoint 2 at 0x351eae9c

And run the program to the break point

Breakpoint 2, 0x351eae9c in ?? ()

Step some instructions into the method and then dump the registers

(gdb) stepi 30
0x351eaf03 in ?? ()
(gdb) info registers
eax            0x200	512
ecx            0x0	0
edx            0x0	0
ebx            0x7431	29745
esp            0x420e1934	0x420e1934
ebp            0xb0206ed0	0xb0206ed0
esi            0x4100758c	1090549132
edi            0x19c54	105556
eip            0x351eaf03	0x351eaf03
eflags         0x202	514
cs             0x17	23
ss             0x1f	31
ds             0x1f	31
es             0x1f	31
fs             0x1f	31
gs             0x37	55

The current FP is stored in RVMThread.framePointer which we found out in 3) is at offset +148. ESI points to the current RVMThread object so we can access the FP value like so:

(gdb) x ($esi+148)
0x41007620:	0x420e1954

Note that the FP is at a higher address than ESP which is what we would expect

The return address is at FP+4 so to get the return address we can do:

(gdb) x (*($esi+148))+4
0x420e1958:	0x351eadde

We can look in RVM.map for the largest method address smaller than 0x351eadde which is org.jikesrvm.mm.mmtk.ReferenceProcessor.addCandidate(java.lang.ref.Reference, org.vmmagic.unboxed.ObjectReference). Examining ReferenceProcessor.java we find that this is the only method that calls growReferenceTable so this is correct

Get the return address from the next frame

(gdb) x *(*($esi+148))+4
0x420e1980:	0x352ebd1e

Which corresponds to org.jikesrvm.mm.mmtk.ReferenceProcessor.addSoftCandidate(java.lang.ref.SoftReference, org.vmmagic.unboxed.ObjectReference) which is a caller of addCandidate.

We can follow the stack back up to the top where we will read a FP of 0 (look in rvm/src/org/jikesrvm/ia32/StackframeLayoutConstants.java for details)

  • No labels