Re: separated debuginfo patch

[Nick Clifton <nickc at redhat dot com>]

Hi Philippe,

> cc'ing binutils list

 [And adding gdb since this affects how debuginfo files are
 processed].
 
> hi, we was discussing about the separate debug info files.
> I've some doubt than crc is the right way to check for debug
> file match.

> Changed my mind, now I think a timestamp is better.
> This sort of problem is generally solved by a timestamp
> (64 bits) not a crc, both file contain the same timestamp and
> the timestamp must be equal, imho crc is usefull to check file
> corruption not file matching

Although by having a crc you can do both at the same time.

> crc *can*(1) be here if someone want to check if the debug file
> is corrupted but this must be a client decision to check the
> crc not a bfd one. With the current scheme I'm unusure than an
> operport -l will work enough well since we can get easily a few
> GB of debug info leading to an opreport slower by a few magnitude
> order. It can be usefull for gdb itself, what will occur if I try
> to get a bt for OpenOffice and it's 1.2 GB of debug info in separate
> debug file ?
>
> doing it in this way seems feasible:
>
> objcopy --add-gnu-link will add a timestamp section in both
> debug file and binary which can be used to check file match
> by bfd lib.
>
> BFD maintainers is this scheme sensible?

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.

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...


Still, I am not totally opposed to the idea, and if the gdb guys agree
I would be happy to consider a patch adding these features.  (I am a
bit swamped at the moment, so I do not have time to create the patch
myself).  It should not be too hard to do.

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).

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)

  .note.gnu.debuglink.timestamp (even longer, but who's counting ? :-)

 
Cheers
        Nick
        
(1) This was a deliberate choice on my part since the strip and
    objcopy tools historically only ever have one output file.  I could
    have changed their internals to handle multiple outputs, but this
    was more work than I wanted to do, and I believe in keeping things
    simple unless forced to add complications.