separated debuginfo patch

[Philippe Elie]

cc'ing binutils list

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.

graydon hoare wrote:
> oh, also, to answer your questions:
> 
> Philippe Elie <phil.el@wanadoo.fr> writes:


>>calc_crc32 in a separate file but I don't like the fact we
>>need to crc32 the whole debug info file, these files can
>>be numberous and voluminous, if this feature is not already
>>in RH production distro can I ask the debuginfo file is
>>augmented with a section containing the check sum, then we
>>don't need to recalcultate the check sum but just compare
>>the checksum in .gnu_debuglink and the checksum in the debug
>>file. It'll speed up a lot operation like opreport -l.

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


> hm, but then the checksum may be incorrect. in fact it is kind of
> pointless to use a checksum at all if it is not checked; we might as
> well just use a large random binary string.

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 once. 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 step seems feasible:

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

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?

(1) 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

regards,
Phil