Re: separated debuginfo patch

Philippe Elie
2003-07-04T23:38:31Z

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