From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 331 invoked by alias); 9 Jun 2004 22:37:02 -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 318 invoked from network); 9 Jun 2004 22:37:01 -0000 Received: from unknown (207.189.223.52) by sourceware.org with QMTP; 9 Jun 2004 22:37:01 -0000 Received: (qmail 12919 invoked from network); 9 Jun 2004 22:51:17 -0000 Received: from tf0089.peakpeak.com (HELO fleche.redhat.com) ([204.144.239.89]) (envelope-sender ) by email3.peakpeak.com (qmail-ldap-1.03) with SMTP for ; 9 Jun 2004 22:51:17 -0000 Received: by fleche.redhat.com (Postfix, from userid 1000) id 662124F810D; Wed, 9 Jun 2004 16:25:02 -0600 (MDT) To: Daniel Jacobowitz Cc: Andrew Haley , java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: Binary Compatibility: debug info for compiled Java programs 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> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Wed, 09 Jun 2004 22:37:00 -0000 In-Reply-To: <20040609221710.GA16922@nevyn.them.org> Message-ID: <87ise0bc8y.fsf@fleche.redhat.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-06/txt/msg00085.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: >> No, not exactly. It's possible to insert a class into the inheritance >> chain or add new fields. Daniel> That's something you can do while preserving Binary Compatibility, but Daniel> if we find the loaded copy of the class, its compile-time-generated Daniel> debug information will describe its fields, right? Not really. First, you can read about Java binary compatibility here: http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44872 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. 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. Tom