From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 26EFC3853D40 for ; Mon, 21 Nov 2022 14:24:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26EFC3853D40 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669040640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I8mSmhEIIaZsvbRhNrO3dND7WLKJPFDTiRnN6PI455c=; b=Jx8GCzuAp4A9h77IQpV+kb+dFcILW3XUQmgannsg3jcjGTPxYkpfhL+XJtBFOWl8JsVQfr jeDH98zJBqlb6ctMbW98nU5nRS9BfHkrSSQjxQ/CEdRE8oxrZs+m2o52sAjeypfGvWrWAb VovFXh91732adqoSxUB3w4MSy0+OUGM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-287-57vRKMJMNvCSOFKVUPI-aw-1; Mon, 21 Nov 2022 09:23:57 -0500 X-MC-Unique: 57vRKMJMNvCSOFKVUPI-aw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1C497185A78F; Mon, 21 Nov 2022 14:23:57 +0000 (UTC) Received: from [10.33.36.220] (unknown [10.33.36.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id A64F12166B26; Mon, 21 Nov 2022 14:23:56 +0000 (UTC) Message-ID: Date: Mon, 21 Nov 2022 14:23:53 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 To: Tom Tromey , Andrew Dinn via Gdb References: <2932d319-9e73-53f1-0f97-bf2d67fdb879@redhat.com> <87h6z82jn0.fsf@tromey.com> From: Andrew Dinn Subject: Re: gcj debug question In-Reply-To: <87h6z82jn0.fsf@tromey.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 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 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