From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by sourceware.org (Postfix) with ESMTPS id 34BF43853D60 for ; Mon, 21 Nov 2022 14:35:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34BF43853D60 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=vrany.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrany.io Date: Mon, 21 Nov 2022 14:35:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrany.io; s=protonmail2; t=1669041336; x=1669300536; bh=1rEp2QUkkNb1Di39EDaGoqI2dOel5rlotduIp5iIryI=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Kao52agbsqqJV9TE3HGxb6dBVzAmYRO4+2ZH/+s02nfJM8KT5a70nmFwrYPKMhcZZ zv0iWWM8ZnuTdlQikMmV2/Q2vhH2ZPsjNXGP6NokkQJzCXKbFCXG22LgDjUPT1z3vT Xc9fYNHh86KhBwcZKgNT0bBp/Q+7G0tc1f/NkJEFe9FHrviApBTXEjucIJd1y6cOtS wxc0QPyytxcxUniGppILcih5K4feXRXlsgzmm6D/uAJFkqjW06JSgrp5HsNYwwuJtI YPvD32U0BvGlobWphyi/aErjjPBM+Gc34fIASRmCCYstPRJDKyIu+K3jPODEm/xSpN WsjVjChPCaKVg== To: Andrew Dinn , Tom Tromey , Andrew Dinn via Gdb From: Jan Vrany Subject: Re: gcj debug question Message-ID: In-Reply-To: References: <2932d319-9e73-53f1-0f97-bf2d67fdb879@redhat.com> <87h6z82jn0.fsf@tromey.com> Feedback-ID: 40767693:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Andrew, On Mon, 2022-11-21 at 14:23 +0000, Andrew Dinn via Gdb wrote: > 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" =3D=3D Andrew Dinn via Gdb writ= es: > > > > Andrew> I'm hoping there is still enough institutional memory left some= where > > Andrew> in this forum to provide info about (the now defunct) DWARF sup= port > > 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 ref= lective > > 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 hav= e > > 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. I'm confident Python is the way to go here. I'm python code to to navigate objects on (garbage-collected) heap and pret= ty-print them - the current Python API so far is sufficient (for my usecases). Things are getting a little bit more difficult when it comes to frame=C2= =A0 decorators. This spring I have extended Python API to allow building line number tables using Python and use this to demo how to map jitted code to .java source co= de. I'm about to start submitting patches next month or in January. > > > 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 >