Re: gcj debug question

>>>>> "Andrew" == Andrew Dinn via Gdb <[email protected]> writes:

Andrew> I'm hoping there is still enough institutional memory left somewhere
Andrew> in this forum to provide info about (the now defunct) DWARF support
Andrew> for gcj. Specifically, does anyone have a long enough memory to recall 
Andrew> whether and, if so, how gcj advertised the presence of Java reflective
Andrew> class objects (instances of java.lang.Class) to the debugger?

You can see all the old code in commit 9c37b5ae, which removed it.
Most of what you want is in jv-lang.c.

Andrew>   - Did it insert linker symbols for e.g. org.my.Foo.class into a
Andrew>     generated binary?

I believe gcj did do this, but gdb also knew how to extract the vtable
from an object, use that to find the runtime's class object, and then
decode that object to make a gdb 'struct type'.  See
java_class_from_object and type_from_class.

It's been a long time but my recollection is that debugging Java didn't
work extremely well.  When I worked on gcj I basically knew nothing
about gdb and so I never tried to fix any of the bugs.

The main issue with this kind of thing is that there has to be a way to
communicate the Class layout from the runtime to gdb.  DWARF could be
used for this, of course, but often these kinds of system libraries are
stripped.  Ada has this problem for task objects, and there we just have
gdb know the object layout... not really ideal.

If I was doing this again I'd probably look into whether enough Python
infrastructure could be added so that the magic could be done in Python
code that was shipped alongside libgcj.  That would break this link
between the runtime and the debugger.  For basic debugging it could
maybe all be done via pretty-printers; though of course that doesn't
work if you want to support 'ptype'.

Andrew>   - Did it emit DWARF info records with tag DW_TAG_variable and
Andrew>     associated attributes like name, type, linkage name and location?

I am not sure.

One thing to note is that gcj had two ABIs.  One ABI was C++-like and
was used for the core classes.  For example, all of java.lang (IIRC)
would have been built this way.  In this mode, object and vtable layout
was mostly compatible with C++ and so (I assume, I don't recall looking
at this much) ordinary C++-ish DWARF would have been emitted.

There was also the "binary compatibility ABI", which tried to follow the
Java binary compatibility rules.  This mode deferred object and vtable
layout (and other related decisions) until class initialization.
Normally, user code would be compiled in this mode.  I'm not sure what
the DWARF would have looked like here, but it couldn't have been very
ordinary, because things like data member offsets wouldn't be known
until after class initialization, and in those days gdb didn't
understand things like dynamic type layout.

Andrew>   - In the latter case were these records located in the class (tag
Andrew>     DW_TAG_class) info record or at top level in the same compile unit
Andrew>    as the class?

In DWARF these are always nested in the DW_TAG_class.  Top-level is for
things like global variables.  (A Java static member would still be
under the class, Java doesn't have this kind of global.)

Tom