From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22595 invoked by alias); 9 Jun 2004 22:17:13 -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 22526 invoked from network); 9 Jun 2004 22:17:11 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 Jun 2004 22:17:11 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BYBNe-0004Pm-Oq; Wed, 09 Jun 2004 18:17:10 -0400 Date: Wed, 09 Jun 2004 22:17:00 -0000 From: Daniel Jacobowitz To: Andrew Haley Cc: java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Binary Compatibility: debug info for compiled Java programs Message-ID: <20040609221710.GA16922@nevyn.them.org> Mail-Followup-To: Andrew Haley , java@gcc.gnu.org, gdb@sources.redhat.com References: <16582.65277.81118.189889@cuddles.cambridge.redhat.com> <20040609130859.GA7514@nevyn.them.org> <16583.3516.604885.805420@cuddles.cambridge.redhat.com> <20040609132951.GA8017@nevyn.them.org> <16583.4773.74100.735457@cuddles.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16583.4773.74100.735457@cuddles.cambridge.redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-06/txt/msg00084.txt.bz2 On Wed, Jun 09, 2004 at 02:37:41PM +0100, Andrew Haley wrote: > Daniel Jacobowitz writes: > > On Wed, Jun 09, 2004 at 02:16:44PM +0100, Andrew Haley wrote: > > > Daniel Jacobowitz writes: > > > > > > > > I'm not familiar with the BC ABI (and missed the talk); could you give > > > > me an example of what information you have at compile time and what you > > > > generate at runtime? > > > > > > All structures are laid out at runtime. > > > > > > http://people.redhat.com/lockhart/.gcc04/MasterGCC-2side.pdf Page 169. > > > > So: the list of members, the inheritance tree, et cetera is static at > > compile time; for their locations you have runtime tables. > > No, not exactly. It's possible to insert a class into the inheritance > chain or add new fields. That's something you can do while preserving Binary Compatibility, but if we find the loaded copy of the class, its compile-time-generated debug information will describe its fields, right? And if we find an older copy of the debug information, then the new fields will appear to be invisible but the existing fields will be located OK. OK, that's a minor problem in that we need to learn how to prefer the right copy of the debug info. > > Member offsets definitely don't have to be constant. In fact, from the > > spec: > > For a C++ virtual base, the data member location attribute will > > usually consist of a non-trivial location expression. > > The way C++ handles virtual bases is similar enough in execution that > > the same thing will work here. For a member it would look like: > > > > # Base location of the class is on the stack > > DW_OP_addr > > DW_OP_constu > > DW_OP_plus > > DW_OP_deref (or DW_OP_deref_size ) > > DW_OP_plus > > Okay, that's good. Would we also be able to cope with not being able > to resolve our superclass till runtime? It can't just be a pointer to > a symbol, because there may be many identical symbols. No, unfortunately, that won't work. Not sure what to do about that. -- Daniel Jacobowitz