#3 symbol info for gdbrvm


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

Future extensions:
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
other software,
described as/entitled
____, or

(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
the CPL.


  • jeremy singer

    jeremy singer - 2005-03-10

    perl script to generate stabs asm file from RVM.map

  • Ian Rogers

    Ian Rogers - 2007-05-30

    Logged In: YES
    Originator: NO

    Thanks to Daniel Frampton, as of 12206 this is now part of the Jikes RVM build system. An option to ant of -Drvm.debug-symbols=true will generate the symbols file as part of the build process, running "rvm -gdb" knows to pick up the symbol file and load it into gdb. I'd suggest closing this tracker unless we want to keep it around for people running old versions of the RVM.

  • sjfsjf

    sjfsjf - 2007-07-09

    Logged In: YES
    Originator: NO

    I am not able to set breakpoints using the instructions above, gdb complains and gives an I/O error (below). This happens on ia32-linux and ppc32-linux, I'm using the latest svn. Any suggestions would be appreciated.

    $ ant -Dhost.name=ia32-linux -Dconfig.name=prototype-opt -Drvm.debug-symbols=true
    $ ./rvm -gdb Test
    GNU gdb 6.6
    Copyright (C) 2006 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "i686-pc-linux-gnu"...
    Using host libthread_db library "/lib/libthread_db.so.1".
    add symbol table from file "./JikesRVM-symbols.o" at
    .text_addr = 0x0
    Breakpoint 1 at 0x8050a0b: file /home/sjf/soc/jikesrvm/tools/bootImageRunner/ia32/bootThread.S, line 46.
    (gdb) break 'org.jikesrvm.VM.boot__(void) volatile'
    Breakpoint 2 at 0x12bd
    (gdb) run
    Starting program: /home/sjf/soc/jikesrvm/dist/prototype-opt_ia32-linux/JikesRVM "-X:ic=./RVM.code.image" "-X:id=./RVM.data.image" "-X:ir=./RVM.rmap.image" "-X:vmClasses=./jksvm.jar:./rvmrt.jar" "-Duser.timezone=EDT" "-Djava.home=." "-Dgnu.classpath.home.url=file:." "-Dgnu.classpath.vm.shortname=JikesRVM" "-Duser.home=/home/sjf" "-Duser.dir=/home/sjf/soc/jikesrvm/dist/prototype-opt_ia32-linux" "-Duser.name=sjf" "-Dos.name=Linux" "-Dos.version=2.6.21" "-Dos.arch=i686" "Test"
    Cannot insert breakpoint 2.
    Error accessing memory address 0x12bd: Input/output error.


  • Ian Rogers

    Ian Rogers - 2007-07-09

    Logged In: YES
    Originator: NO

    Hi, you can't set a break point in the main code of the RVM when GDB starts, you need to wait until the boot image is loaded. In GDB you need to first run the RVM, GDB will then hit a breakpoint inserted after the RVM is loaded, then enable your breakpoint, then continue execution in GDB and wait for your breakpoint to be hit.
    Regards, Ian


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks