public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Mark Kettenis <kettenis@gnu.org>
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 21:44:00 -0000	[thread overview]
Message-ID: <418FDD06.9030404@specifixinc.com> (raw)
In-Reply-To: <200411071428.iA7ES7Fx003013@elgar.sibelius.xs4all.nl>

Mark Kettenis wrote:
> 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.

SGI Irix6 created the N64 ABI, and they decreed that one must use a 
(non-standard) 64-bit DWARF format with it.  We are just following the 
ABI here.  If we change it, then we lose compatibility with Irix6, and 
the published ABI.

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

This is because SGI decided that DWARF2 was broken, and tried to fix it 
by adding 64-bit extensions.  These extensions are only needed if you 
have more than 4GB of DWARF debug info, and hence is unlikely, but SGI 
claims that they did hit this limit.  No one else has apparently ever 
hit the limit.

Unfortunately, the way that SGI extended DWARF2 caused problems, as it 
resulted in ambiguous DWARF info, so the DWARF3 committee defined a 
different way that is self descriptive.  But since this happened after 
Irix6 had already been released, and SGI could not break backwards 
compatibility with Irix6, N64 still uses the non-standard 64-bit DWARF 
format that SGI invented.  And gcc uses this non-standard 64-bit DWARF 
format for all mips64 targets, for consistency, and to conform with the ABI.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

  parent reply	other threads:[~2004-11-08 20:54 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 [this message]
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=418FDD06.9030404@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=kettenis@gnu.org \
    --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).