Re: gcj debug question

[Andrew Dinn <adinn@redhat.com>]

Hi Tom,

Thanks every much for your helpful response -- and also very nice to 
hear from you again.

On 09/11/2022 16:10, Tom Tromey wrote:
>>>>>> "Andrew" == Andrew Dinn via Gdb <gdb@sourceware.org> 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.

That's the most useful thing I could have asked for, not just for this 
issue but for any other questions I might need to answer.

> 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.

Wow, that's nice. Of course I'm able to generate all the required info 
up front as DWARF (because GraalVM has a closed world model).

> 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.

Hmm, much like when I started on gdb support for GraalVM ... ;-)

> 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.

Well, without runtime class loading its much less of a two way street. 
Being able to generate all the DWARF info you need up front means you 
are able provide complete file and line info, frame info (without 
needing to rely on a valid fp), static field and local var locations, 
etc. I even lookup and cache sources at build time so they can be pulled 
out of a hat (along with a .dwz file) when you want to debug an image.

> 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'.

I had not thought much about using the python APIs (mainly because my 
python skills ... how can I best express this ... sit comfortably in the 
[0, epsilon) interval. I will have a think about what python might be 
useful for though.

> 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.

Ok, so this starts to make sense of the way that all those core classes 
are defined as they are using C code. Effectively Java objects, 
including Java Class objects, are implemented as near as possible to the 
way g++ implements C++ objects (i.e. using closely similar conventions 
for data and code layouts).

That's never really been a guiding principle for the operation of the 
compiler I am generating DWARF for. However, I *have* effectively found 
a way to model the Java objects in DWARF that makes it look like they 
originated from a C++ type & class base derivable from the original Java 
class base via a simple source to source mapping. That's enough to fake 
Java debugging.

> 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.)
Yes, that makes sense. Thanks for the history lesson and, most of all, 
for a link to the source.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill