This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Binary Compatibility: debug info for compiled Java programs


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 <otable location>
>  >   DW_OP_constu <otable offset>
>  >   DW_OP_plus
>  >   DW_OP_deref (or DW_OP_deref_size <size of atable entry>)
>  >   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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]