From: Nick Clifton <nickc@redhat.com>
To: gdb-patches@sources.redhat.com, binutils@sources.redhat.com
Subject: RFC: Support for separate debug info files
Date: Wed, 11 Jun 2003 09:43:00 -0000 [thread overview]
Message-ID: <m3ptlllzp9.fsf@redhat.com> (raw)
[-- 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 --]
next reply other threads:[~2003-06-11 9:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-11 9:43 Nick Clifton [this message]
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
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=m3ptlllzp9.fsf@redhat.com \
--to=nickc@redhat.com \
--cc=binutils@sources.redhat.com \
--cc=gdb-patches@sources.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