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

[Roland McGrath <roland at redhat dot com>]

> But the first command, the one to create the separate debug info file,
> is still needed, right?

Nothing about the recommended user procedure for making separate debug
files has changed.  Using --add-gnu-debuglink is not strictly required when
using only new consumers that honor build ID notes, and dealing only with
binaries that were linked with ld --build-id.  But there is no reason not
to do it and it is still required in the event of linking without
--build-id or if concerned with all existing tools that understand
.gnu_debuglink but not build ID notes.

It is the case that strip and objcopy behavior wrt allocated notes sections
has changed, and that the new behavior is required for build IDs to be
preserved in separate debug files.  However, I don't think there is any
reason to burden the user with these details explicitly in the primary
documentation on the subject.  (Hence, there is no need to worry about how
to identify versions of binutils here in the manual.)  No version,
derivative release, snapshot, or chronological state of development in
binutils has included an ld supporting --build-id but an objcopy that
treated it with the old rules.  The objcopy and other tools involved in
splitting a binary into a separate debug file should be no older than the
ld used to create the original binary.  If anything, that's all that needs
to be said in the recipe.  It's beyond unusual for the ld and objcopy et al
one is usng not to have come from the very same build/package, so it's
really not something to worry about.

> This is fine, but there's no need to quote ``debug ID'' every time you
> use it.  I quoted it only when I used it as a name of a method of
> embedding information about the debug file; in other cases I used it
> without quotes.

The canonical term is "build ID", and I do not think it is helpful to
introduce "debug ID" in any documentation.  In fact, the feature per se
does not relate directly to debugging information, though that is indeed
the largest motivation for its use.  

It is also not good to use the term "signature" loosely with relation to
build ID bits.  I would prefer to avoid that term entirely, except perhaps
in a section devoted to discussing selection of ID bits and the issues of
uniqueness and repeatability in detail.  I am concerned about too easily
creating misunderstandings that build ID bits relate to some sort of
guarantee about the origin of binaries or security checks, which they do
not.  (As far as the fundamental feature itself goes, a build ID gives some
bits that the creator of the binary decided to tell you were useful as an
identifier for the binary.  binutils and ld have nothing more to say about
it than that.)


Thanks,
Roland