From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29542 invoked by alias); 10 Jun 2004 16:37:22 -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 29520 invoked from network); 10 Jun 2004 16:37:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 10 Jun 2004 16:37:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BYSYI-0006TP-La; Thu, 10 Jun 2004 12:37:18 -0400 Date: Thu, 10 Jun 2004 16:37:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: Andrew Haley , java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Binary Compatibility: debug info for compiled Java programs Message-ID: <20040610163718.GA24803@nevyn.them.org> Mail-Followup-To: Tom Tromey , 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> <20040609221710.GA16922@nevyn.them.org> <87ise0bc8y.fsf@fleche.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ise0bc8y.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-06/txt/msg00094.txt.bz2 On Wed, Jun 09, 2004 at 04:25:01PM -0600, Tom Tromey wrote: > However, this is only part of the picture. The other part is that the > Java runtime environment can differ from the compile-time environment. > In particular, a given class can be loaded into a running virtual > machine any number of times, via different ClassLoaders. And since > all references used by a class are symbolic, and since a ClassLoader > mediates the name->class lookup, it follows that each separately > loaded instance of such a class can have different superclasses. > > I.e., we load class Derived, which inherits from class Base, twice. > We load it once via ClassLoader A and once via ClassLoader B. Then we > can end up with different versions of Base, that might have different > properties. E.g., B's Base might have extra private fields. (Exactly > what changes are valid is what is described in that chapter of the > JLS.) > > > In our BC ABI, we add a new level of indirection. So, a field lookup > isn't just *(object+offset), but instead *(object+otable[index]), > where the otable ("offset table") is computed at class initialization > time. 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? Anyway, I could probably work this out if I sat down for an hour with your paper :) > 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. -- Daniel Jacobowitz