debuginfod: curious case of libicudata.so

debuginfod: curious case of libicudata.so

[Frank Ch. Eigler]

Hi -

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!

- FChE

Re: 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

Re: debuginfod: curious case of libicudata.so

[Frank Ch. Eigler]

Hi -

> 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".

Yeah.  I'm about to commit the following patch for this.


commit 1bcfab2af7e51980bdf46464bcbd367ca46aa771
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Thu Apr 15 04:49:59 2021 -0400

    debuginfod: Recognize .debug_*-less symtab-laden files as debuginfo
    
    Borrow logic from elfclassify for is_debug_only() for our own
    debuginfo identification.
    
    Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index c98a8374732b..3bd2ff606aa6 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2021-04-15  Frank Ch. Eigler <fche@redhat.com>
+
+	* debuginfod.cxx (elf_classify): Recognize symtab-only stripped files
+	like fedora's libicudata as debuginfo files.
+
 2021-03-30  Frank Ch. Eigler <fche@redhat.com>
 
 	* debuginfod.cxx (main): Set child thread names.
diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
index 473511eab921..2d73a136ae5e 100644
--- a/debuginfod/debuginfod.cxx
+++ b/debuginfod/debuginfod.cxx
@@ -2255,6 +2255,8 @@ elf_classify (int fd, bool &executable_p, bool &debuginfo_p, string &buildid, se
         throw elfutils_exception(rc, "getshdrstrndx");
 
       Elf_Scn *scn = NULL;
+      bool symtab_p = false;
+      bool bits_alloc_p = false;
       while (true)
         {
           scn = elf_nextscn (elf, scn);
@@ -2280,7 +2282,24 @@ elf_classify (int fd, bool &executable_p, bool &debuginfo_p, string &buildid, se
               debuginfo_p = true;
               // NB: don't break; need to parse .debug_line for sources
             }
+          else if (shdr->sh_type == SHT_SYMTAB)
+            {
+              symtab_p = true;
+            }
+          else if (shdr->sh_type != SHT_NOBITS
+                   && shdr->sh_type != SHT_NOTE
+                   && (shdr->sh_flags & SHF_ALLOC) != 0)
+            {
+              bits_alloc_p = true;
+            }
         }
+
+      // For more expansive elf/split-debuginfo classification, we
+      // want to identify as debuginfo "strip -s"-produced files
+      // without .debug_info* (like libicudata), but we don't want to
+      // identify "strip -g" executables (with .symtab left there).
+      if (symtab_p && !bits_alloc_p)
+        debuginfo_p = true;
     }
   catch (const reportable_exception& e)
     {

Re: debuginfod: curious case of libicudata.so

[Mark Wielaard]

Hi Frank,

On Thu, Apr 15, 2021 at 07:17:48AM -0400, Frank Ch. Eigler wrote:
> > 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".
> 
> Yeah.  I'm about to commit the following patch for this.

That looks like it does the right thing. Has SYMTAB and no allocated
sections (except for nobits and notes).

Thanks,

Mark