public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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.

             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).