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

[Roland McGrath <roland@redhat.com>]

> We don't introduce such a new term, the above was a typo.  The manual
> does not use this term anywhere, it uses "build ID".

Great.

> > It is also not good to use the term "signature" loosely with relation to
> > build ID bits.
> 
> What alternative term would you suggest?  I have no shares in this
> particular word, if a good alternative exists.

Well, there is "ID".  Also "bit string", or "set of bits", or "sequence of
bytes" come to mind.  Whatever flows in the particular context to say what
is so, which is that it is a small chunk of data taken solely as an
identifier with no instrinsic meaning to its bits.  The text I wrote in the
ld manual (ld/ld.texinfo @node Options) uses "unique bits" and "bit string".

Also, I don't think it is proper to refer to this as GNU/Linux operating
system magic and refer to the Fedora wiki.  The build ID note is a GNU
convention for ELF binaries and the tool involved in creating it is GNU ld.
It is the linker, and how the linker is used, that determines whether
creating a binary normally gives it one.  The GDB manual should refer
directly to the GNU ld manual about how it's created.

If you mean the manual to document precise format details, then it should
not say that a build ID section is "named @code{.note.gnu.build-id}".  That
is the name of the input section that ld synthesizes under --build-id, and
will often be the name of the final section seen in an executable or DSO.
But the name is in no way magical and any tool would be broken if it worked
only on a section by that name.  It should be mentioned only as a common
case.  It is only the normative ELF data that controls what constitutes a
proper build ID in an ELF file.  That is, SHT_NOTE sections, or PT_NOTE
segments in sectionless files, with proper ELF note formats of name "GNU"
and type NT_GNU_BUILD_ID.

The wording now says "executable" a lot, while in reality it can be any
kind of ELF file that gdb would consider.  That is, executables or DSOs
(ET_EXEC/ET_DYN), or ET_REL files that are contemplated in their own right,
as is done for Linux kernel modules.  For all of these, gdb can find
separate debug info, and should use build IDs to do so.


Thanks,
Roland