This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: separated debuginfo patch
- From: Philippe Elie <phil dot el at wanadoo dot fr>
- To: graydon hoare <graydon at redhat dot com>
- Cc: oprofile-list at sourceforge dot net, binutils at sources dot redhat dot com
- Date: Thu, 03 Jul 2003 08:36:41 +0000
- Subject: Re: separated debuginfo patch
- References: <87wuf3s4q3.fsf@dub.venge.net> <3F02B1A5.5000102@wanadoo.fr> <87adbwpkhj.fsf@dub.venge.net>
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