Re: find-debuginfo.sh change for gdb index

[Roland McGrath <roland@redhat.com>]

> One thing that came up is that the current approach of using file
> size+mtime to determine whether the index is valid is not super.

Agreed.

> Two competing ideas:
> 
> 1. Put the build-id into the index file, then verify it.

That is the method already used for .debug files today.  (The old
.gnu_debuglink CRC32 check should be ignored when there are build IDs.
I don't know about GDB, but libdw ignores it when there is a build ID.)

> 2. Require the index to be a section in the ELF object.

This is the most obvious way to handle this information.  The only real
down-sides are a) possible bugs breaking the original file and b) somewhat
more hair later if the index format has to be redone and only data
reindexed.  I don't really think either of those is something to worry much
about.

Doing this adds another interlocking requirement.  The eu-strip (libebl)
code for -g matches the individual DWARF sections by name.  (Without -g, it
strips all non-allocated sections, but for -g it only strips the sections
with recognized names.)  So that requires a (one-line) change in elfutils
for the new section name, and we'll need the new elfutils release in
buildroots before the new index-adding procedure goes in.  (It shouldn't be
any problem to push this out quickly, but it needs to go on your checklist
so we coordinate it.)

>    This has the nice property that no validation need be done.

Put another way, it implicitly takes advantage of the existing validation
mechanisms.  If you modify the unstripped file before strip-to-file, then
even the CRC32 will be correct.  (This should not really be a concern one
way or the other for Fedora, where both --build-id is always used and all
the tools should be validating by IDs rather than CRCs.  But for generic
goodness of the scheme, it is attractive in not introducing a new wrinkle
about the CRC calculation.)

>    However, it would require a further tweak to find-debuginfo.sh.

Or perhaps less change there, after a fashion.  The place to put the new
work is either right after debugedit or right before eu-strip -f.  Off hand
I think it should be the former.  That will put an index into e.g. the
unstripped vmlinux, which gets copied into /usr/lib/debug but never passed
to eu-strip.

So one approach would be to replace the debugedit invocation with the use
of another shell script.  Then that new script can run debugedit and make
the gdb index.  It can be fiddled as needed without changing the core logic
in find-debuginfo.sh again.  We could possibly let that script be supplied
by the redhat-rpm-config rpm or the gdb rpm or something else, so that its
maintenance is not directly in the path of the rpm package maintainers.


Thanks,
Roland