From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4875 invoked by alias); 10 Jun 2004 16:44:40 -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 4566 invoked from network); 10 Jun 2004 16:44:25 -0000 Received: from unknown (HELO cuddles.cambridge.redhat.com) (81.96.64.123) by sourceware.org with SMTP; 10 Jun 2004 16:44:25 -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 i5AGgLVL022867; Thu, 10 Jun 2004 17:42:32 +0100 Received: (from aph@localhost) by redhat.com (8.12.8/8.12.8/Submit) id i5AGgLDC022863; Thu, 10 Jun 2004 17:42:21 +0100 From: Andrew Haley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16584.36716.621979.766824@cuddles.cambridge.redhat.com> Date: Thu, 10 Jun 2004 16:44:00 -0000 To: Daniel Jacobowitz Cc: Tom Tromey , java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Binary Compatibility: debug info for compiled Java programs In-Reply-To: <20040610163718.GA24803@nevyn.them.org> 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> X-SW-Source: 2004-06/txt/msg00096.txt.bz2 Daniel Jacobowitz writes: > 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? The object doing the access. Every class has an otable that is fixed up with the field offsets of every field that it accesses. > > 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? Andrew.