public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: echristo@redhat.com, seufer@csv.ica.uni-stuttgart.de,
	gdb@sources.redhat.com, gcc@gcc.gnu.org,
	binutils@sources.redhat.com
Subject: Re: Mixing 32-bit and 64-bit DWARF2/3 sections
Date: Mon, 08 Nov 2004 23:37:00 -0000	[thread overview]
Message-ID: <1099955006.7589.43.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <200411082204.iA8M4jws088177@elgar.sibelius.xs4all.nl>

On Mon, 2004-11-08 at 14:04, Mark Kettenis wrote:
> systems, gas currently generates the new DWARF3 64-bit format.  I
> merely want to argue that it probably would have been better if the
> default had been 32-bit for Linux.

It would be reasonable to try to use standard DWARF for non-Irix
systems, but the ambiguous SGI DWARF format complicates this.

With the SGI DWARF format, you can't tell whether you have 32-bit or
64-bit debug info by looking at the debug info alone.  You need external
info.  Currently, this is based on the ABI.  If we have N32 code, then
we have 32-bit DWARF always.  If we have N64 code, then we have
SGI-64-bit DWARF always.  (I see that neither bfd nor gdb actually do it
this way, but they are supposed to.)

In order to change this, we will need some other header flag to indicate
whether we are following the SGI scheme or the GNU scheme.  If we have
an OS field that is set consistently, then we could use that, but I as
skeptical whether this is safe in all cases.  Not all operating systems
have their own OS flags defined, especially for embedded systems.  There
is also a backwards compatibility problem.  That means we need a new
flag.  We need assembler support to set it, and an assembler directive
or option so that gcc can tell the assembler whether or not to set it. 
So we need an ELF header change, along with gcc, binutils, and gdb
patches to deal with it.  It isn't clear to me whether the benefits of
this change are worth the amount of effort needed to implement it.

Anyways, I think it is a reasonable goal, just not sure if it is worth
the trouble it will cause.

Besides the technical details, you will also need to get political buy
in from affected parties for an ABI change, which means mainly the
GNU/Linux mips64 folks.

I'd suggest that the easiest solution here is to fix gas.  Gas should
always use dwarf2_format_64bit_irix with the N64 ABI, regardless of
whether the target is Irix.  This will fix your debugging problems,
though it won't give the debug info format you want.

Checking, I see that the binutils patch came from here:
	http://sources.redhat.com/ml/binutils/2003-01/msg00442.html
This is a thread with Alexandre Oliva trying to fix some problems with
the SGI-64-bit DWARF2 format, and Daniel Jacobowitz questioning why we
are using a non-standard format for non-Irix targets, and Alex made this
change to try to make Daniel happy.  Unfortunately, this causes your
current problem, as it makes gas incompatible with gcc.  I'd suggest
reverting this gas patch to solve your problem as a short term fix. 
Incidentally, this thread contains some info explaining why Alex thought
it was a good idea to be compatible with Irix here, as it made some
things easier.  The long term fix is a new elf header flag, and gcc,
binutils, and gdb changes to set and use it.  Reverting the gas patch is
far simpler.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


  reply	other threads:[~2004-11-08 23:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-07 15:31 Mark Kettenis
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 [this message]
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=1099955006.7589.43.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=binutils@sources.redhat.com \
    --cc=echristo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --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).