RFC: Support for separate debug info files

RFC: Support for separate debug info files

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

Hi Guys,

  OK, here is a heavily revised patch to implement support for
  generating separate debuginfo files in binutils.  The highlights of
  this version are:

    * Adds a new switch to objcopy "--add-gnu-debuglink=<file>", which
      creates a .gnu_debuglink section in the output file which points
      to the specified <file>.

    * It no longer adds a "--strip-nondebug" or "--only-keep-debug" switch
      to strip and objcopy - it is not needed.  (Although this is open
      to debate, see below).

    * Exports the CRC32 computing function that was already in BFD so
      that it can be used by other tools.  This would allow the
      version in GDB to be made obsolete...

  Here is an example of the patch in action:

    % cat hello.c
    int main (void) { return printf ("hello world\n"); }

    % gcc hello.c -g -o hello
    % strip --strip-all hello hello.stripped.all
    % strip --strip-debug hello hello.stripped.debug
    % objcopy --add-gnu-debuglink=hello hello.stripped.all hello.stripped.all.with-link
    % ls -l
    -rwxrwx---    12031 Jun 11 10:09 hello*
    -rw-rw----       54 Jun 11 10:09 hello.c
    -rwxrwx---     2804 Jun 11 10:10 hello.stripped.all*
    -rwxrwx---     4382 Jun 11 10:10 hello.stripped.debug*
    -rwxrwx---     2872 Jun 11 10:11 hello.stripped.all.with-link*

    % gdb hello.stripped.all.with-link
    GNU gdb 2003-06-09-cvs
    Copyright 2003 Free Software Foundation, Inc.
    (gdb) break main
    Breakpoint 1 at 0x8048364: file hello.c, line 1.
    (gdb) run
    Starting program: /builds/FSF/native/tests/debug-info-test/hello.stripped.with-link
 
    Breakpoint 1, main () at hello.c:1
    1       int main (void) { return printf ("hello world\n"); }

  So the fully stripped executable "hello.stripped.all.with-link" is
  only 2872 bytes long, but it can be fully debugged when accompanied
  by the original, unstripped executable "hello".  (Which at 12031
  bytes is 4 times the size of the stripped version).

  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.

  My theory is that the only benefit gained by being able to ship a
  stripped debuginfo file as opposed to an unstripped one is that it
  reduces the shipping size, making a distribution smaller.  I am
  assuming that hard disk space is not really an issue, just the size
  of the shipped binaries.

  Any comments ?

Cheers
        Nick

bfd/ChangeLog
2003-06-11  Nick Clifton  <nickc@redhat.com>

	* opncls.c (calc_crc32): Rename to
	bfd_calc_gnu_debuglink_crc32 and export.
        (GNU_DEBUGLINK): Define and use to replace occurrences of
	hard-coded ".gnu_debuglink" in the code.
        (get_debug_link_info): Prevent aborts by replacing call to
	xmalloc with a call to malloc.
        (find_separate_debug_file): Prevent aborts by replacing calls
	to xmalloc and xstrdup with calls to malloc and strdup.
        (bfd_add_gnu_debuglink): New function.  Add a .gnu_debuglink
	section to a bfd.
	* bfd-in2.h: Regenerate.

binutils/ChangeLog
2003-06-11  Nick Clifton  <nickc@redhat.com>

	* objcopy.c (gnu_debuglink_filename): New variable.
        (OPTION_ADD_GNU_DEBUGLINK): New switch
        (copy_options): Describe --add-gnu-debuglink switch.
        Mention that --strip-debug removes sections as well.
        (is_strip_section): Process the sections removed and kept
        lists before checking for debugging sections.
        (add_redefine_syms_file): Make function static.
        (copy_object): Use is_strip_section.
        Check to see if a .gnu_debuglink section should be added.  If
        so, call bfd_add_gnu_debuglink.
        (setup_section): Use is_strip_section.
        (copy_section): Use is_strip_section.
        (copy_main): Handle OPTION_ADD_GNU_DEBUGLINK.
	* NEWS: Mention new objcopy switch.
        * doc/binutils.texi: Document new switch.


[-- Attachment #2: Patch to add support for --add-gnu-debuglink switch to objcopy --]
[-- Type: application/x-bzip2, Size: 6202 bytes --]

Re: RFC: Support for separate debug info files

[Jim Blandy]

Nick Clifton <nickc@redhat.com> writes:
>   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.
> 
>   My theory is that the only benefit gained by being able to ship a
>   stripped debuginfo file as opposed to an unstripped one is that it
>   reduces the shipping size, making a distribution smaller.  I am
>   assuming that hard disk space is not really an issue, just the size
>   of the shipped binaries.

I think the idea is to omit the debug info files altogether from the
distribution.  It'll make the debug info packages take longer to
download, but it's not a show-stopper, I think.

Re: RFC: Support for separate debug info files

[Daniel Jacobowitz]

On Wed, Jun 11, 2003 at 08:36:29AM -0500, Jim Blandy wrote:
> 
> Nick Clifton <nickc@redhat.com> writes:
> >   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.
> > 
> >   My theory is that the only benefit gained by being able to ship a
> >   stripped debuginfo file as opposed to an unstripped one is that it
> >   reduces the shipping size, making a distribution smaller.  I am
> >   assuming that hard disk space is not really an issue, just the size
> >   of the shipped binaries.
> 
> I think the idea is to omit the debug info files altogether from the
> distribution.  It'll make the debug info packages take longer to
> download, but it's not a show-stopper, I think.

For me it probably is a show-stopper - the issue is not download time
or disk space, but CD size.  Duplicating all the binaries we want to
provide debug info for would probably push us over the edge.  It could
be done separately though!  This will at least let us test it...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Support for separate debug info files

[Jakub Jelinek]

On Wed, Jun 11, 2003 at 10:40:18AM +0100, Nick Clifton wrote:
>   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?
(ie. ET_DYN resp. ET_EXEC with the sections which were not stripped
turned into SHT_NOBITS sections).
I think harddrive space is not the main problem (although the difference can
be big, openoffice-debuginfo ATM takes 1.2GB and when all the .text/.data
etc. sections were in as well, I think it could grow easily by further
300MB), 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.

	Jakub

Re: RFC: Support for separate debug info files

[Nick Clifton]

Hi Daniel,

>> >   My theory is that the only benefit gained by being able to ship a
>> >   stripped debuginfo file as opposed to an unstripped one is that it
>> >   reduces the shipping size, making a distribution smaller.  I am
>> >   assuming that hard disk space is not really an issue, just the size
>> >   of the shipped binaries.
>> 
>> I think the idea is to omit the debug info files altogether from the
>> distribution.  It'll make the debug info packages take longer to
>> download, but it's not a show-stopper, I think.
>
> For me it probably is a show-stopper - the issue is not download time
> or disk space, but CD size.  Duplicating all the binaries we want to
> provide debug info for would probably push us over the edge.  It could
> be done separately though!  This will at least let us test it...

Plus you could ship the debug info CD separately.  Maybe at additional
cost to the customer, or after a delay, so that the time-to-market for
a new release is reduced ?

Cheers
        Nick
        

Re: RFC: Support for separate debug info files

[Nick Clifton]

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

Re: RFC: Support for separate debug info files

[Elias Athanasopoulos]

On Wed, Jun 11, 2003 at 10:40:18AM +0100, Nick Clifton wrote:
>   This leads me to my main point.  Do we need the ability to create
>   stripped debuginfo files ?  The original patch did this, but it

Imagine a LAN of users that occasionaly want to debug their apps. The 
debug info file can be in one machine, which can be retrieved by gdb via an
NFS mount, and users can have their stripped apps in their local machines.

Regards,
Elias

-- 
University of Athens			I bet the human brain 
Physics Department				is a kludge --Marvin Minsky 

	

Re: RFC: Support for separate debug info files

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:

> On Wed, Jun 11, 2003 at 08:36:29AM -0500, Jim Blandy wrote:
> > 
> > Nick Clifton <nickc@redhat.com> writes:
> > >   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.
> > > 
> > >   My theory is that the only benefit gained by being able to ship a
> > >   stripped debuginfo file as opposed to an unstripped one is that it
> > >   reduces the shipping size, making a distribution smaller.  I am
> > >   assuming that hard disk space is not really an issue, just the size
> > >   of the shipped binaries.
> > 
> > I think the idea is to omit the debug info files altogether from the
> > distribution.  It'll make the debug info packages take longer to
> > download, but it's not a show-stopper, I think.
> 
> For me it probably is a show-stopper - the issue is not download time
> or disk space, but CD size.  Duplicating all the binaries we want to
> provide debug info for would probably push us over the edge.  It could
> be done separately though!  This will at least let us test it...

Actually, CD size is the issue for Red Hat, too (not that our problems
are the only ones important to solve well).  It's just that Red Hat
doesn't include the debuginfo packages on the CD's at all, so we don't
care how big they are.

We used to ship executables with no debugging info, so shipping
executables with debug links is a step up for us.  If you used to ship
executables with debugging info, then just shipping debug links would
be a step down for you.