From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by sourceware.org (Postfix) with ESMTPS id 68B5C3858D1E for ; Wed, 9 Nov 2022 16:11:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68B5C3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw15.mail.unifiedlayer.com (unknown [10.0.90.130]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id BE86F1004539E for ; Wed, 9 Nov 2022 16:11:02 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id snfKo0VFrhuWGsnfKoO7fx; Wed, 09 Nov 2022 16:11:02 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Bbodbph2 c=1 sm=1 tr=0 ts=636bd116 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=9xFQ1JgjjksA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=nB5gGROyC4-9gWISrYMA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FGdIz96Pi7ppHUarVAipJW6gxYR9tu9nFU0fe3rfyAU=; b=qdtEIBW3GiXpZIBmElFNR9VRKQ j/pnYFZveCQqYK/Q6MeOOJLxK29AZviqfvjI/qi4o8ZZb30fuKeK+ygVp6Gt6ITurHoYIjsH9qDny jS+zuqlpCK5ttBDdItlq8YuBy; Received: from 97-122-76-186.hlrn.qwest.net ([97.122.76.186]:56802 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1osnfK-002TA8-6b; Wed, 09 Nov 2022 09:11:02 -0700 From: Tom Tromey To: Andrew Dinn via Gdb Cc: Andrew Dinn Subject: Re: gcj debug question References: <2932d319-9e73-53f1-0f97-bf2d67fdb879@redhat.com> X-Attribution: Tom Date: Wed, 09 Nov 2022 09:10:59 -0700 In-Reply-To: <2932d319-9e73-53f1-0f97-bf2d67fdb879@redhat.com> (Andrew Dinn via Gdb's message of "Tue, 25 Oct 2022 11:48:41 +0100") Message-ID: <87h6z82jn0.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.76.186 X-Source-L: No X-Exim-ID: 1osnfK-002TA8-6b X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-76-186.hlrn.qwest.net (murgatroyd) [97.122.76.186]:56802 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3022.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "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. 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