[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic Debug Packages

On 2009-08-11, Manoj Srivastava <srivasta@debian.org> wrote:
>         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?

The plan is to make --build-id the default (As it is on many other

>   * For the "build ID" method, GDB looks in the `.build-id'
>      subdirectory of the global debug directory for a file named
>      `NN/NNNNNNNN.debug', where NN are the first 2 hex characters of
>      the build ID bit string, and NNNNNNNN are the rest of the bit
>      string.  (Real build ID strings are 32 or more hex characters, not
>      10.)
>         So, we would still need to create   "/usr/lib/debug/"
>  . /full/path/to/lib_or_binary/ in either case, and instead of the

no. it would be /usr/lib/debug/.build-id/NN/NNNNNN.debug

>  lib-or-exec name, create NN/NNNNNNNN.debug file there (which is non
>  human readable, really). What have we gained? There is no potential for
>  file name conflicts, since if there are file name conflicts in the
>  debug symbol files, there would be file name conflicts in the
>  corresponding packages, which is already a bug in Debian.
>         I see added complexity with no real benefit for us: it might
>  have value in an environment where file conflicts are not verboten.

And the next step is to provide /usr/lib/debug/.build-id exported from
some internet service so that you download debugging symbols on demand,
for example thru drkonqi or bug-buddy or maybe directly with gdb.

Having a reliable way of getting from a random library version and
random executable version to get the exact corresponding debug symbols,
the build-id method is just much more reliable.


Reply to: