This patch enables limited gdb symbol support for names
of methods in the RVM boot image. I hacked up a perl
script [parse-map.pl, attached] that generates a dummy
object file with stabs debug information about method
names and entry points extracted from the RVM.map file.
Use as follows:
1) (shell) "parse-map.pl > dummymap.s" in a terminal
with $RVM_BUILD defined correctly.
2) (shell) "as -o dummymap.o dummymap.s"
3) (shell) "gdbrvm Classname"
4) (gdb) "run" till it hits first breakpoint, when all
code from boot image should have been loaded into memory
5) (gdb) "add-symbol-file /path/to/dummymap.o"
6) (gdb) type "y" when prompted
7) (gdb) Now it should be ok to set breakpoints using
method names, for example...
(gdb) "break 'com.ibm.JikesRVM.VM.boot__' "
Note that tab completion works here!
8) (gdb) "cont" - till we hit breakpoint.
This debugging approach has been tested successfully
for JikesRVM on ARM/Linux and IA32/Linux. It should
work on other platforms, though you may need to hack
the perl script to generate syntactically correct asm
code for your GNU assembler (or equivalent).
1) The types in the method signature are mangled, to
ensure that each method name is unique and that the
names are valid GNU assembler symbols. This means that
some methods may look slightly cryptic - sorry. I used
the mangling algorithm from
gdb attempts to unmangles ints and longs (to int_t0 and
complex!?) but it can't cope with anything else.
2) The symbol support slows things down terribly!
Adding breakpoints takes for ever! I don't know if this
is because my hack is inefficient, or because gdb is
working so hard to handle so many symbols.
3) The stabs debug information has absolute addresses
of method entry points hardwired into it, based on the
info in RVM.map. When this information changes (method
recompilation, garbage collection, new methods
generated, etc) the debug information needs to be
updated. I haven't figured out how to do this yet. Any
1) get types recognised properly - this should be
possible in stabs. It's certainly feasible for pretty
printing method argument types, even if not for
inspecting object data.
2) extend approach so that (re)compiled methods and
moved methods cause debugging information to be updated
appropriately. This might require some gdb hackery, I
don't feel competent at this :-)
To Ian Rogers and Andrew Dinn for their helpful advice.
I, Jeremy Singer__:
(a) represent that either:
(i) I am the only author and owner of the software,
which was neither derived nor copied from any
(ii) that any exception to (i) is software which was
obtained under the
CPL (Common Public License),
(b) hereby agree to license this other software under
Log in to post a comment.