"inconsistent kernel build-id" message

"inconsistent kernel build-id" message

[Roland McGrath]

I don't think "byte #0 (0x6d [actual] vs. 0xbb [debuginfo])" is usefully
informative in the "inconsistent kernel build-id" message.  Modulo bugs
in the translator side (stap/libdwfl), byte-by-byte contemplation of a
build ID is utterly meaningless to everyone.  What people ever see and
can make use of is the whole ID in hex (as from eu-readelf -n,
eu-unstrip -n).

A useful message (though a bit longer) would be:

build ID mismatch: "kernel" d055e788c855fb5196f9d73b26d4ba45388b7019 != ".../vmlinux" f1d823a6d25d0774febaf7d8f3b14eb1d7625e24

where "kernel" is replaced by the short module name as used in the
script et al ("nfs", "libc.so", etc.) and ".../vmlinux" is replaced by
the main ELF file name (from libdwfl) that the translator consulted.
(Might as well use this vs debug file name, shorter and just as
normative.  OTOH, one day it's likely the debug file name for canonical
rpm packaging will encode the rpm package name/version obviously to the
eyeball so perhaps that's a better choice.  But if you used symbol-only,
you might have just a main file and not a debug file.)

That points directly at the file used, which makes it obvious if it's
just the wrong kernel binary or suchlike.  The full ID makes it possible
both to easily compare by hand (eu-unstrip -n -e foo, etc.) for sanity
checking, and (one day) to feed easily into some handy "wtf is this
build ID from" tool.  (e.g. in Fedora, a front-end for repoquery -f
/usr/lib/debug/.build-id/xx/yyy or suchlike.)


Thanks,
Roland