Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com
Subject: Re: RFC: Support for separate debug info files
Date: Wed, 11 Jun 2003 14:27:00 -0000	[thread overview]
Message-ID: <m3ptlk4rqw.fsf@redhat.com> (raw)
In-Reply-To: <20030611134532.GW24872@sunsite.ms.mff.cuni.cz> (Jakub Jelinek's message of "Wed, 11 Jun 2003 15:45:32 +0200")

Hi Jakub,

>>   This leads me to my main point.  Do we need the ability to create
>>   stripped debuginfo files ?  The original patch did this, but it
>>   turns out to be problematical since the debuginfo files need to
>>   contain dummy versions of the .text, .data, etc sections.  Doing
>>   this, rather than just stripping them out, looked non-trivial, so I
>>   decided to skip it for this version.
>
> By stripped debuginfo files you mean what eu-strip -f creates,
> right?

Err, probably.  I mean debuginfo files that work with GDB and which
can provide the necessary information to allow the debugging of a
stripped executable.  I found that just collecting together the
various .debug.* sections (and associated symbols) was not enough.
The debuginfo also needs a full section table and program header
table, with dummy entries for the stipped out sections.  And producing
this kind of file would be, IMHO, tricky.


> which is how you install it, because suddenly you have to transfer
> more bytes from the network in order to debug packages, and not
> everybody has a fast pipe.

But then not everyone wants to debug anything.  And the number of
people who are going to want to debug a big executable (eg openoffice)
is probably very small.  So by being able to ship a program as a
small, quick to download package which only becomes big if the second,
debuginfo package has to be downloaded, people will be encouraged to
use it.

Similarly for distributions, this change would allow a distribution to
be shipped in a much smaller space, possibly on less CDs, and only a
few people are going to want to download/buy the extra CDs containing
the debugging info.

Well that is my theory anyway... :-)

Cheers
        Nick


  reply	other threads:[~2003-06-11 14:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-11  9:43 Nick Clifton
2003-06-11 13:35 ` Jim Blandy
2003-06-11 13:43   ` Daniel Jacobowitz
2003-06-11 14:15     ` Nick Clifton
2003-06-11 19:28     ` Jim Blandy
2003-06-11 13:45 ` Jakub Jelinek
2003-06-11 14:27   ` Nick Clifton [this message]
2003-06-11 17:59 ` Elias Athanasopoulos

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=m3ptlk4rqw.fsf@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jakub@redhat.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