From: Mark Kettenis <kettenis@gnu.org>
To: gcc@gcc.gnu.org, binutils@sources.redhat.com
Cc: echristo@redhat.com, seufer@csv.ica.uni-stuttgart.de,
gdb@sources.redhat.com
Subject: Mixing 32-bit and 64-bit DWARF2/3 sections
Date: Sun, 07 Nov 2004 15:31:00 -0000 [thread overview]
Message-ID: <200411071428.iA7ES7Fx003013@elgar.sibelius.xs4all.nl> (raw)
Currently GDB barfs when you use it on an executable that contains
compilation units that mix 32-bit and 64-bit DWARF sections. Looking
at the (latest?) DWARF3 draft it doesn't seem to be unreasonable that
it does so:
"The 32-bit and 64-bit DWARF format conventions must not be
intermixed within a single compilation unit."
The way things are structured now, it is easy to end up with a
configuration where this happens since some DWARF sections are
generated by GCC and others by gas, i.e. if GCC is configured to
generate 32-bit DWARF, and gas will generate 64-bit dwarf. This is
currently the case for the (not yet contributed) GCC configuration
that's currently used by OpenBSD/mips64. Now this can be easily fixed
by changing either the GCC config or gas, but the DWARF3 draft also
says:
"It is expected that DWARF producing compilers will not use the
64-bit format by default. In most cases, the division of even very
large applications into a number of executable and shared objects
will suffice to assure that the DWARF sections within each
individual linked object are less than 4 GBytes in size. However,
for those cases where needed, the 64-format allows the unusual case
to be handled as well. Even in this case, it is expected that only
application supplied objects will need be compiled using the 64-bit
format; separate 32-bit format versions of system supplied shared
executable libraries can still be used."
This argues that what's currently done in gas and GCC for most 64-bit
MIPS targets is wrong, since these use the 64-bit DWARF format
unconditionally for the n64 ABI.
Fixing this would be a tricky though, since doing it requires some
coordination between GCC and binutils. We could add a switch to gas
to tell it to generate 64-bit DWARF format. But even then GCC will
probably need to support old gas versions that generate 64-bit format
by default, adding more config goo to GCC. So I think the existing
MIPS targets should probably keep doing what they do now.
However, I could make OpenBSD/mips64 do the right thing, making both
GCC and gas generate 32-bit DWARF by default. What do the MIPS people
think about that?
Cheers,
Mark
P.S. It seems that MIPS is the only 64-bit target for which this is a
problem, since all other 64-bit targets (AMD64, UltraSPARC) still
use the 32-bit DWARF format.
next reply other threads:[~2004-11-07 14:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-07 15:31 Mark Kettenis [this message]
2004-11-07 16:29 ` Daniel Jacobowitz
2004-11-07 17:16 ` Mark Kettenis
2004-11-08 0:19 ` Daniel Jacobowitz
2004-11-08 21:44 ` James E Wilson
2004-11-08 23:03 ` Mark Kettenis
2004-11-08 23:37 ` James E Wilson
2004-11-08 23:46 ` Thiemo Seufer
2004-11-08 23:55 ` Daniel Berlin
2004-11-09 0:15 ` James E Wilson
2004-11-08 23:50 ` Daniel Jacobowitz
2004-11-09 0:29 ` James E Wilson
2004-11-09 20:58 ` Dean Luick
2004-11-09 22:10 David Anderson
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=200411071428.iA7ES7Fx003013@elgar.sibelius.xs4all.nl \
--to=kettenis@gnu.org \
--cc=binutils@sources.redhat.com \
--cc=echristo@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=seufer@csv.ica.uni-stuttgart.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).