Re: Automatic Debug Packages
On Tue, Aug 11 2009, Josselin Mouette wrote:
> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>> Hmm. I see very little benefit here. Firstly, to use build id,
>> you have to intercept the upstream build system and add --build-id
>> (and perhaps the --build-id-style) option to ld, instead of the current
>> method of letting the upstream build happen and working on the produced
>> objects -- this is more intrusive. And what do we gain?
>
> Without build IDs, GDB has no sure way to map the binary to the correct
> detached symbols. Therefore it will read the whole file to compute its
> CRC32 (!) and compare it to the one stored in the gnu_debuglink section
> of the binary.
>
> This sole issue is responsible for gdb taking up to several minutes to
> produce a backtrace for binaries using big libraries like xulrunner. And
> don’t even think of using the debugging symbols over the network in this
> case.
Yes, that would indeed be silly -- if you have managed to
intercept ld and added --build-id to the executable, it would be silly
not to have the file in the location gdb will look in.
However, if you do not use the build-id mechanism, and use what
we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
adds information that gdb looks at to figure out where the debug
symbols live -- and no CRC check sum is ever performed.
So a mixed mode approach would indeed be bad. But a pure debug
link method does not have these stated drawbacks.
Given the difficulty in intercepting ld commands in upstream
build systems, I would be inclined to just standardize the debug link
method, given that it produces human readable file names (so I can
determine manually if I have debugging symbols for some library or
not) as an added bonus.
manoj
--
Work is the crab grass in the lawn of life. Schulz
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: