debuginfod: curious case of libicudata.so

[Mark Wielaard]

Hi Frank,

On Thu, Apr 15, 2021 at 04:30:59AM -0400, Frank Ch. Eigler via Elfutils-devel wrote:
> Just happened to come across some odd traffic in gdb/debuginfod
> on the fedora servers.  Wonder how common this case is.  The
> RPM in question is icu:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1555665
> (f33; other versions the same)
> 
> This builds into the usual binary / -debuginfo subrpms.  Take
> a look at libicu*, and libicudata* within it: buildid
> 1600b578adeb2c27a24fbe68b88562f923d4b694.
> 
> The .debug file is a wee little baby:
> 
> -rw-r--r--. 1 root root 4144 Apr 15 07:34 /usr/lib/debug/usr/lib64/libicudata.so.67.1-67.1-4.fc33.x86_64.debug
> 
> and since it contains no .debug* sections at all, debuginfod doesn't
> think it's a debuginfo-carrying file.  eu-elfclassify --debug-only
> declares it a "yes", because it has a symtab.  Should we follow
> eu-elfclassify's lead and get debuginfod to bless this file as a
> debuginfo too?  Probably.  But what a strange little file!

Yes, it doesn't contain any DWARF, which is why libdw doesn't like
it. But it does contain a .symtab sections, so it is "debuginfo".

I don't fully get why no DWARF is generated at all in this case.  But
the whole shared library consists of just one file, which isn't empty,
but seems to be a stub and doesn't contain any real code, just some
data definitions:

*   file name:  stubdata.c
*
*   Define initialized data that will build into a valid, but empty
*   ICU data library.  Used to bootstrap the ICU build

Cheers,

Mark