public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: 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:57:00 -0000	[thread overview]
Message-ID: <1099958254.7589.64.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <20041108233732.GH22577@rembrandt.csv.ica.uni-stuttgart.de>

On Mon, 2004-11-08 at 15:37, Thiemo Seufer wrote:
> 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.

DWARF2 debug info has a field to indicate pointer size, and uses this
for addresses.  The only limit to DWARF2 debug info is that cross
references within the DWARF2 debug info are specified by 32-bit fields. 
Thus, in order to exceed the 32-bit limit, one of the DWARF2 sections
must be larger than 4GB.  Since the DWARF2 info is spread across
multiple sections, it would be possible to have 36GB of DWARF2 debug
info, and still not exceed the 32-bit limit, if none of the individual
sections are larger than 4GB.  You can have a 1TB application, and still
not exceed the 32-bit limit, if none of the individual DWARF2 debug
section are larger than 4GB.

I don't think we should be worried about use of 32-bit DWARF2 debug
info.  We are unlikely to hit the limits anytime soon.  And if we do hit
the limits, then we will likely have other more serious problems.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


  parent reply	other threads:[~2004-11-08 23:57 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
2004-11-08 23:57         ` James E Wilson [this message]
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=1099958254.7589.64.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=ica2_ts@csv.ica.uni-stuttgart.de \
    --cc=mark.kettenis@xs4all.nl \
    /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).