Re: [patch] build-id .debug files load (like .gnu_debuglink)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]

Hi,

On Sat, 01 Sep 2007 12:31:07 +0200, Eli Zaretskii wrote:
...
> I attach below the changes I committed to the manual,

thanks, sure more readable.

...
>   . The Fedora site that describes the build ID features seems to say
>     that there are TWO files (actually symlinks) in the global debug
>     directory for each executable: ab/cdef1234 and ab/cdef1234.debug.
>     By contrast, you only talk about a single file.

The file ab/cdef1234 points to the main executable (or shared library), it is
not used by this patch so far.  Going to submit now the second part of the
patch which automatically finds the matching executable / shared libraries
according to the build-id signatures left stored in a core file.

There should be probably a new section in the documentation for it afterwards.


>   . The Fedora site says that the build ID symlinks are created only
>     in the global debug directory.  However, your patch seems to say
>     that GDB looks for these symlinks in all the other possible
>     locations as well:
> 
>      @value{GDBN} checks under each of these names for a debugging
>     +information file with build id content matching the build id content of the
>     +executable file - or - whose checksum matches the one given in the link in the
>     +debug link case.
> 
>     Which one is true?

Wrong/ambiguous is my wording.  Your current sectence `GDB will look for the
following debug information files, in the indicated order' is definitely right
so I expect your current documentation version can be kept this way.


>   . The objcopy commands shown in your patch seem to be relevant only
>     to the ``debug link'' method (at least that's what I understand
>     from the last objcopy command).  If so, I think we should say what
>     are the corresponding commands for the ``debug ID'' method.
>     Likewise, if there are (or going to be) features in elfutils that
>     support ``debug ID'', I think we should mention them, as we do for
>     ``debug links'' now.

``debug ID'' gets included by `ld --build-id', therefore by `gcc
-Wl,--build-id', it is still not default in FSF GCC.  There are no specific
splitting commands required (such as `objcopy --add-gnu-debuglink' for the
former "debug link".  Older binutils strip ``debug ID'' during the file split,
binutils since binutils-2.17.50.0.18 became compatible.

Included a new doc paragraph.


>   . I'm confused by your mentioning of ``all files'' in this passage:
> 
>     +@dfn{build id} is present in all the files [...]
> 
>     as opposed to ``only the executable'' in the debug link case:
> 
>     +@dfn{debug link} is present only in the executable [...]
> 
>     I don't understand this distinction.  As far as I could glean from
>     the build ID description on the Fedora site, the difference is
>     that the build ID is present both in the executable and in the
>     debug info file, whereas the debug link is present only in the
>     executable.  Thus we have two files (maybe 3, if core dumps are
>     counted), vs one, not ``only one'' vs ``all''.  Did I miss
>     something?

You are right and your wording in the doc is also OK:
	The executable contains a "build ID", a unique signature that is also
	present in the corresponding debug info file.

...
> Btw, I think this change warrants an entry in NEWS.

I delayed it after the second part (locating the files from the core file
signatures) but still the entry can be updated later.


NEWS/doc patch included below.


Thanks,
Jan

[-- Attachment #2: gdb-build-id-news-and-build.patch --]
[-- Type: text/plain, Size: 1799 bytes --]

2007-09-01  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* NEWS: Mention the build-id .debug files verification.

2007-09-01  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.texinfo (Separate Debug Files): Cosmetic quoting removal.
	New binaries build instructions for the ``build ID'' inclusion.

--- gdb/NEWS	28 Aug 2007 19:57:11 -0000	1.236
+++ gdb/NEWS	1 Sep 2007 11:29:43 -0000
@@ -61,6 +61,9 @@ Windows and SymbianOS).
 * The GDB remote stub, gdbserver, now supports dynamic link libraries
 (DLLs) on Windows and Windows CE targets.
 
+* GDB now supports a faster verification a .debug file matches its binary
+according to its build-id signature, if the signature present.
+
 * New commands
 
 set remoteflow
--- gdb/doc/gdb.texinfo	1 Sep 2007 10:28:25 -0000	1.426
+++ gdb/doc/gdb.texinfo	1 Sep 2007 11:29:53 -0000
@@ -12033,7 +12033,7 @@ following commands:
 @smallexample
 @kbd{objcopy --only-keep-debug foo foo.debug}
 @kbd{strip -g foo}
-@kbd{objcopy --add-gnu-debuglink="foo.debug" "foo"}
+@kbd{objcopy --add-gnu-debuglink=foo.debug foo}
 @end smallexample
 
 @noindent
@@ -12044,6 +12044,11 @@ Drepper's @file{elfutils} package, start
 a version of the @code{strip} command such that the command @kbd{strip foo -f
 foo.debug} has the same functionality as the three commands above.
 
+``Debug ID'' gets embedded into the main executable using @code{ld --build-id}
+or the @value{NGCC} counterpart @code{gcc -Wl,--build-id}.  ``Debug ID''
+support plus compatibility fixes for debug files separation are present in
+@sc{gnu} binary utilities (Binutils) since version 2.17.50.0.18.
+
 Since there are many different ways to compute CRC's for the debug
 link (different polynomials, reversals, byte ordering, etc.), the
 simplest way to describe the CRC used in @code{.gnu_debuglink}