public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: James E Wilson <wilson@specifixinc.com>,
	 Mark Kettenis <mark.kettenis@xs4all.nl>,
	echristo@redhat.com,  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:50:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.60.0411081840080.30647@dberlin.org> (raw)
In-Reply-To: <20041108233732.GH22577@rembrandt.csv.ica.uni-stuttgart.de>



On Tue, 9 Nov 2004, Thiemo Seufer wrote:

> James E Wilson wrote:
> [snip]
>> 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.
>
> FWIW, I doubt going back unconditionally to a 32bit format is the right
> thing to do for a fully 64bit ABI. Applications tend to grow further,
> as does the accompanying debug info, so the 32bit limit comes closer.

DWARF3, which is what gcc emits, is 32 bit by "default", but if it 
became necessary, it (DWARF3) supports 64 bit sizes/offsets/etc and can 
output 
them.

The main difference between SGI's 64 bit-only dwarf2, and DWARF3's 
64bit dwarf2 is that DWARF3 allows you to mix 32 bit and 64 bit 
compilation units ( you just can't mix 32 bit and 64 bit *in* a single 
compilation unit).
SGI doesn't allow you to do this.

DWARF3 accomplishes this by using a 32 bit 0xffffffff as the 
initial length in the compilation unit to signal that this is really 64 
bit, which is followed by a 64 bit real length.

SGI does no such thing, they simply use a 64 bit initial length, which 
means you don't know whether you have 32 bit or 64 bit unless the ABI 
tells you it must be one or the other.

In short, there is no limitation in dwarf3 that SGI is solving.
It's just a matter of them not solving it in a backwards compatible way, 
and everyone else paying the consequences :)

--Dan

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

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-07 14:28 Mark Kettenis
2004-11-07 15:31 ` Daniel Jacobowitz
2004-11-07 16:29   ` Mark Kettenis
2004-11-07 17:16     ` Daniel Jacobowitz
2004-11-08 20:54 ` James E Wilson
2004-11-08 22:05   ` Mark Kettenis
2004-11-08 23:03     ` James E Wilson
2004-11-08 23:37       ` Thiemo Seufer
2004-11-08 23:50         ` Daniel Berlin [this message]
2004-11-08 23:57         ` James E Wilson
2004-11-08 23:46   ` Daniel Jacobowitz
2004-11-09  0:15     ` James E Wilson
2004-11-09 20:11 ` Dean Luick

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=Pine.LNX.4.60.0411081840080.30647@dberlin.org \
    --to=dberlin@dberlin.org \
    --cc=binutils@sources.redhat.com \
    --cc=echristo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=ica2_ts@csv.ica.uni-stuttgart.de \
    --cc=mark.kettenis@xs4all.nl \
    --cc=wilson@specifixinc.com \
    /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).