From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24372 invoked by alias); 9 Jun 2004 12:15:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23896 invoked from network); 9 Jun 2004 12:14:57 -0000 Received: from unknown (HELO cuddles.cambridge.redhat.com) (81.96.64.123) by sourceware.org with SMTP; 9 Jun 2004 12:14:57 -0000 Received: from redhat.com (localhost.localdomain [127.0.0.1]) by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id i59CDnVL015759; Wed, 9 Jun 2004 13:13:59 +0100 Received: (from aph@localhost) by redhat.com (8.12.8/8.12.8/Submit) id i59CDnH8015755; Wed, 9 Jun 2004 13:13:49 +0100 From: Andrew Haley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16582.65277.81118.189889@cuddles.cambridge.redhat.com> Date: Wed, 09 Jun 2004 12:15:00 -0000 To: java@gcc.gnu.org CC: gdb@sources.redhat.com Subject: Binary Compatibility: debug info for compiled Java programs X-SW-Source: 2004-06/txt/msg00059.txt.bz2 At the gcc summit last week, we were asked about how we're going to do debug info for programs compiled with the BC ABI. This is a problem: as we don't know the layout of objects at compile time, we can't generate the usual DWARF debugging type info. I said that there were two front-running solutions: calling into libgcj runtime routines that access the metadata, or generating DWARF debugging type info at run time. Andrew Cagney objects to calling libgcj runtime routines, because then we won't be able to debug core files. Also, if the runtime library is hosed for some reason, we won't be able to debug any structures. This is a good point, and I suppose it more or less kills the idea. Bryce pointed out that there is another solution that he favours, which involves gdb reading libgcj's metadata. I reacted badly to this idea because I found it rather distasteful. It seems to me that to do it this way is a case of pathological coupling that I'd like to avoid. However, it may well be the most efficient solution because it doesn't involve doing any extra work at runtime. Bryce pointed out that there's already some precedent for this, in that C++ debugging already does something similar. He also thinks that doing this is easier than generating DWARF in libgcj. I'm not sure about that, one way or the other. Both solutions require gdb changes: to generate DWARF data at runtime requires some changes because gdb is used to reading debug data from object files, not from the inferior process. So, I'm still unsure about how to proceed. It looks like Bryce's suggestion is preferable on efficiency grounds, although it might be possible to generate DWARF cheaply while laying out classes. Bryce, sorry if I've misstated your position. This is based on my best recollection. Comments welcome... Andrew.