From: Andrew Haley <aph@redhat.com>
To: java@gcc.gnu.org
Cc: gdb@sources.redhat.com
Subject: Binary Compatibility: debug info for compiled Java programs
Date: Wed, 09 Jun 2004 12:15:00 -0000 [thread overview]
Message-ID: <16582.65277.81118.189889@cuddles.cambridge.redhat.com> (raw)
At the gcc summit last week, we were asked about how we're going to do
debug info for programs compiled with the BC ABI. This is a problem:
as we don't know the layout of objects at compile time, we can't
generate the usual DWARF debugging type info.
I said that there were two front-running solutions: calling into
libgcj runtime routines that access the metadata, or generating DWARF
debugging type info at run time. Andrew Cagney objects to calling
libgcj runtime routines, because then we won't be able to debug core
files. Also, if the runtime library is hosed for some reason, we
won't be able to debug any structures. This is a good point, and I
suppose it more or less kills the idea.
Bryce pointed out that there is another solution that he favours,
which involves gdb reading libgcj's metadata.
I reacted badly to this idea because I found it rather distasteful.
It seems to me that to do it this way is a case of pathological
coupling that I'd like to avoid. However, it may well be the most
efficient solution because it doesn't involve doing any extra work at
runtime.
Bryce pointed out that there's already some precedent for this, in
that C++ debugging already does something similar. He also thinks
that doing this is easier than generating DWARF in libgcj. I'm not
sure about that, one way or the other.
Both solutions require gdb changes: to generate DWARF data at runtime
requires some changes because gdb is used to reading debug data from
object files, not from the inferior process.
So, I'm still unsure about how to proceed. It looks like Bryce's
suggestion is preferable on efficiency grounds, although it might be
possible to generate DWARF cheaply while laying out classes.
Bryce, sorry if I've misstated your position. This is based on my
best recollection.
Comments welcome...
Andrew.
next reply other threads:[~2004-06-09 12:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-09 12:15 Andrew Haley [this message]
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
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=16582.65277.81118.189889@cuddles.cambridge.redhat.com \
--to=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