From: Daniel Jacobowitz <drow@false.org>
To: Andrew Haley <aph@redhat.com>
Cc: java@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: Binary Compatibility: debug info for compiled Java programs
Date: Wed, 09 Jun 2004 22:17:00 -0000 [thread overview]
Message-ID: <20040609221710.GA16922@nevyn.them.org> (raw)
In-Reply-To: <16583.4773.74100.735457@cuddles.cambridge.redhat.com>
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
next prev parent reply other threads:[~2004-06-09 22:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-09 12:15 Andrew Haley
2004-06-09 13:09 ` Daniel Jacobowitz
2004-06-09 13:19 ` Andrew Haley
2004-06-09 13:29 ` Daniel Jacobowitz
2004-06-09 13:39 ` Andrew Haley
2004-06-09 22:17 ` Daniel Jacobowitz [this message]
2004-06-09 22:37 ` Tom Tromey
2004-06-10 16:37 ` Daniel Jacobowitz
2004-06-10 16:42 ` Tom Tromey
2004-06-10 16:47 ` Ian Lance Taylor
2004-06-10 16:58 ` Andrew Haley
2004-06-10 17:12 ` Ian Lance Taylor
2004-06-10 17:25 ` Andrew Haley
2004-06-10 16:44 ` Andrew Haley
2004-06-10 16:54 ` Daniel Jacobowitz
2004-06-09 14:13 ` Per Bothner
2004-06-09 14:20 ` Andrew Haley
2004-06-09 20:46 ` Anthony Green
2004-06-09 21:26 ` Andrew Cagney
2004-06-09 22:11 ` Anthony Green
2004-06-11 13:04 ` Andrew Haley
2004-06-11 15:11 ` Andrew Cagney
2004-06-11 15:17 ` Andrew Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040609221710.GA16922@nevyn.them.org \
--to=drow@false.org \
--cc=aph@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox