From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20078 invoked by alias); 10 Jun 2004 16:54: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 19817 invoked from network); 10 Jun 2004 16:54:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 10 Jun 2004 16:54:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BYSod-00073v-T8; Thu, 10 Jun 2004 12:54:12 -0400 Date: Thu, 10 Jun 2004 16:54:00 -0000 From: Daniel Jacobowitz To: Andrew Haley Cc: Tom Tromey , java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Binary Compatibility: debug info for compiled Java programs Message-ID: <20040610165411.GA26228@nevyn.them.org> Mail-Followup-To: Andrew Haley , Tom Tromey , 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> <20040609221710.GA16922@nevyn.them.org> <87ise0bc8y.fsf@fleche.redhat.com> <20040610163718.GA24803@nevyn.them.org> <16584.36716.621979.766824@cuddles.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16584.36716.621979.766824@cuddles.cambridge.redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-06/txt/msg00098.txt.bz2 On Thu, Jun 10, 2004 at 05:42:20PM +0100, Andrew Haley wrote: > Daniel Jacobowitz writes: > > I still don't see how this mechanism implements the above principle, > > i.e. converting symbolic field names to offsets; is the otable > > associated with the object doing the access or with the objet defining > > the class? > > The object doing the access. Every class has an otable that is fixed > up with the field offsets of every field that it accesses. Thanks, that's what I was missing. > > > Generating Dwarf that redirects through the otable, like the code > > > itself does, is tempting. But is it possible? I don't see how > > > something like 'print object' would work -- you would have to look > > > more closely at all the reflection data to discover all the fields in > > > a given class. > > > > Generating Dwarf that redirects through a particular otable is easy. > > Generating information to describe the sort of symbolic changes to > > inheritance and fields, on the other hand, is not. > > That's kinda what I expected. Is it hard to generate DWARF to > describe class layout? That depends. A decent-sized chunk of dwarf2out is devoted to this; on the other hand, you've got a much simpler problem to solve since you're only dealing with Java aggregates. The hardest part would be describing the types of fields with appropriate cross-referencing. I'm not sure how to do this without nasty runtime overhead; it might be easier to keep the logic in GDB. I haven't given it much thought, though. -- Daniel Jacobowitz