Re: separated debuginfo patch

[Philippe Elie <phil.el@wanadoo.fr>]

Nick Clifton wrote:
> Hi Philippe,

[trying to avoid crc'ing the separate debug file]

I need to know how GDB guys want I deal with the gdb part, for now
gdb.diff just remove (#if 0) all duplicated code from bfd and use
bfd_follow_gnu_debuglink() to retrieve the debug info file. Is it
ok to remove this code or must I update the duplicated code according
to the change in bfd ?


> The problem binutils has is that the debuginfo file and .gnu-debuginfo
> section in the stripped file are created by two different steps (1).
> Thus adding the same timestamp to both files is tricky and would
> require that the debuginfo file be first created with a blank
> timestamp section and then later, when the .gnu-debuginfo section is
> added, the timestamp is initialised.

I avoided it by forcing user to specify the timestamp in both step

> 
> The other problem with timestamps is that it means that bootstrap
> sequences that involve the creation of debuginfo file will no longer
> work.  ie the debuginfo files and stripped executables from two
> different bootstrap stages will no longer compare as identical because
> of the timestamps.
> 
> This problem could be avoided by using a unique-binary-identifier that
> is specified on the command line, rather than a timestamp that is
> generated by the objcopy/strip program.  ie objcopy could have a new
> switch such as:
> 
>   --set-debuglink-timestamp=<number>
> 
> If this switch is not specified when --add-gnu-debuglink is used, then
> a timestamp is added, otherwise <number> is added.  Generating a
> non-trivial value for <number> however might prove difficult...

I like it, such number is packager responsiblility, for gnu
based system `date +%s` should be sufficient. I changed slightly
it, number is not optionnal and must be provided by caller, is
it a real problem ?


> We just need to agree on the format and name of the timestamp section
> in the debuginfo file, and how to distinguish old .gnu-debuglink
> sections (only containing a crc) from new ones (containing a crc and a
> timestamp).

I disambiguite the two case by looking the section size. See
bfd.diff, it's a bit ugly but I don't see how I can deal cleanly
with this problem.

> 
> Possibilities for the new section in the debuginfo file include:
> 
>   .gnu_debuglink  (ie reuse the section name that is found in the
>                    stripped executable.  The version in the debuginfo
>                    file could be exactly the same format, or it could
>                    be a shortened version with only the timestamp and
>                    not the filename or crc).
>                    
>   .gnu_debuglink_timestamp  (a bit wordy, but self documenting)

I tried to re-use exactly the same format but putting a valid
filename in the .gnu_debuglink in debug info file conduct gdb
into an infinite loop so on I preferred to play safe and use
a separate section.

The patch is a RFC rather than a submission, it needs some cleanup,
updating bfd documentation etc. btw bfd documentation gives two
alternative to use this feature but the first doesn't works with or
w/o the attached patch:

   @item Run @code{objcopy --strip-debug foo} to create a
   stripped executable.
   @item Run @code{objcopy --add-gnu-debuglink=foo.dbg foo}
   to add a link to the debugging info into the stripped executable.

gdb doesn't like file produced in this way and gdb document
only the second way which works

   @item Copy @code{foo} to  @code{foo.full}
   @item Run @code{objcopy --strip-debug foo}
   @item Run @code{objcopy --add-gnu-debuglink=foo.full foo}

The patch is tested with gdb code with and w/o gdeb.diff applied,
it works transparentely for gdb except obviously the old code
always does the crc.

patch can be tested through this two ways:

gcc -g -O2 test.cpp
cp a.out a.out.dbg
strip --strip-unneeded a.out
objcopy --set-debuglink-timestamp=12 a.out.dbg
objcopy --set-debuglink-timestamp=12 --add-gnu-debuglink=a.out.dbg a.out

gcc -g -O2 test.cpp
cp a.out a.out.dbg
strip --strip-unneeded a.out
objcopy --add-gnu-debuglink=a.out.dbg a.out

the first is now the preferred way. I don't like at all
than gdb need the full file it makes separate debug info
less usefull, can a GDB wizard gives some clues if it's
feasible to use the file stripped from it's code/data
section and if it'll be hard to implement ?

regards,
Philippe Elie