+++ This bug was initially created as a clone of Bug #1966987 +++

The build process for glibc includes a mixture of C and assembly code.  The DWARF debuginfo (post-debugedit) includes file name references such as

/usr/src/debug/glibc-2.33.9000-73-ge9e7f24543/sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S

However, the -debugsource subrpm does not include any .s / .S files at all.  This makes debugging a little big harder, and makes the fedora debuginfod a little bit sad to report 404s to users.

--- Additional comment from Florian Weimer on 2021-06-02 10:04:48 UTC ---

Thanks for the report. I think this needs to be fixed in debugedit. We no longer do our own thing in glibc.

--- Additional comment from Frank Ch. Eigler on 2021-06-02 10:50:03 UTC ---

It looks as though something changed in the f34 build process.

Looking at other RPMs such as the recently built openssl-1.1.1k in koji, builds up to and including fc33 include .s files in the -debugsource.  f34 and above do not.

And ditto for GLIBC: 2.32-6.fc33 includes .S files in -debugsource.

--- Additional comment from Mark Wielaard on 2021-06-02 10:54:14 UTC ---

(In reply to Frank Ch. Eigler from comment #2)
> It looks as though something changed in the f34 build process.

That is surprising, is the same true for f35?
In f35 rpm switched to using external debugedit find-debuginfo[.sh].

But f34 should use the same rpm find-debuginfo.sh as earlier versions.

--- Additional comment from Frank Ch. Eigler on 2021-06-02 12:18:02 UTC ---

From my quick sampling tests, debugsource files
contain .S files <= fc33
lack .S files >= fc34

--- Additional comment from Frank Ch. Eigler on 2021-06-02 13:46:30 UTC ---

hand-rebuilding rawhide glibc on f33 (fedpkg local) results in a glibc-debugsource-2.33.9000-11.fc35.x86_64.rpm file that does contain .S files.

--- Additional comment from Frank Ch. Eigler on 2021-06-02 21:16:42 UTC ---

More data: gcc -gdwarf5 defaulting appears to be the driving difference.  Even for a noop assembler file

foo.s:

   main:
       nop

gcc -gdwarf-5 -c foo.s   # results in an .o with dwarf5 line records
gcc -gdwarf-5 -c foo.s   # results in an .o with old school records

and "debugedit -l FILE foo.o" only works with the latter.  Continuing to investigate.

--- Additional comment from Frank Ch. Eigler on 2021-06-02 21:17:04 UTC ---

gcc -gdwarf-5 -c foo.s   # results in an .o with dwarf5 line records
gcc -gdwarf-4 -c foo.s   # results in an .o with old school records

--- Additional comment from Frank Ch. Eigler on 2021-06-02 22:49:01 UTC ---

Yeah it appears as though debugedit just can't extract source file names from -gdwarf-5 files, not just .s but also .c:

% echo 'int main () {}' > foo.c
% gcc -gdwarf-5 foo.c
% debugedit -l foo.list a.out
% cat foo.list
[empty]

--- Additional comment from Mark Wielaard on 2021-06-22 17:29:14 UTC ---

This should at least solve the issue of comment 8. Without giving -d /foo/build/bar debugedit wouldn't actually output any file from the line number table for DWARF5.

diff --git a/tools/debugedit.c b/tools/debugedit.c
index c6975b2..75803a2 100644
--- a/tools/debugedit.c
+++ b/tools/debugedit.c
@@ -1826,8 +1826,8 @@ read_dwarf5_line_entries (DSO *dso, unsigned char **ptrp,
   /* file_names_count */
   unsigned entry_count = read_uleb128 (*ptrp);
 
-  bool collecting_dirs = dest_dir && phase == 0 && *dirs == NULL;
-  bool writing_files = dest_dir && phase == 0 && *dirs != NULL;
+  bool collecting_dirs = phase == 0 && *dirs == NULL;
+  bool writing_files = phase == 0 && *dirs != NULL;
   if (collecting_dirs)
     {
       *ndir = entry_count;
@@ -1857,15 +1857,19 @@ read_dwarf5_line_entries (DSO *dso, unsigned char **ptrp,
                {
                case DW_FORM_strp:
                case DW_FORM_line_strp:
-                 if (dest_dir && phase == 0)
+                 if (phase == 0)
                    {
                      size_t idx = do_read_32_relocated (*ptrp);
-                     if (record_file_string_entry_idx (line_strp, dso, idx))
+                     if (dest_dir)
                        {
-                         if (line_strp)
-                           need_line_strp_update = true;
-                         else
-                           need_strp_update = true;
+                         if (record_file_string_entry_idx (line_strp,
+                                                           dso, idx))
+                           {
+                             if (line_strp)
+                               need_line_strp_update = true;
+                             else
+                               need_strp_update = true;
+                           }
                        }
                      handled_strp = true;
                      if (collecting_dirs || writing_files)
@@ -1951,7 +1955,7 @@ read_dwarf5_line_entries (DSO *dso, unsigned char **ptrp,
       if (writing_files)
        {
          char *comp_dir = (*dirs)[0];
-         size_t comp_dir_len = strlen(comp_dir);
+         size_t comp_dir_len = !comp_dir ? 0 : strlen(comp_dir);
          size_t file_len = strlen (file);
          size_t dir_len = strlen (dir);
 

I am not sure this also solves the original issue because during packaging debugedit should always be invoked with --base ... and --dest ...

--- Additional comment from Mark Wielaard on 2021-07-26 12:22:36 UTC ---

As far as I can see there simply is no debuginfo for these .S files:

# eu-readelf -S ./glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu/sysdep.o
There are 11 section headers, starting at offset 0x190:

Section Headers:
[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
[ 0]                      NULL         0000000000000000 00000000 00000000  0        0   0  0
[ 1] .text                PROGBITS     0000000000000000 00000040 00000000  0 AX     0   0  1
[ 2] .data                PROGBITS     0000000000000000 00000040 00000000  0 WA     0   0  1
[ 3] .bss                 NOBITS       0000000000000000 00000040 00000000  0 WA     0   0  1
[ 4] .note.gnu.property   NOTE         0000000000000000 00000040 00000050  0 A      0   0  8
[ 5] .note.GNU-stack      PROGBITS     0000000000000000 00000090 00000000  0        0   0  1
[ 6] .gnu.build.attributes NOTE         0000000000000000 00000090 00000024  0        0   0  4
[ 7] .rela.gnu.build.attributes RELA         0000000000000000 000000f0 00000030 24 I      8   6  8
[ 8] .symtab              SYMTAB       0000000000000000 000000b8 00000030 24        9   2  8
[ 9] .strtab              STRTAB       0000000000000000 000000e8 00000001  0        0   0  1
[10] .shstrtab            STRTAB       0000000000000000 00000120 0000006a  0        0   0  1

So nothing for debugedit to extract.

This might be a gcc (or binutils gas?) bug because it does look like -g is being passed when building the file:

gcc ../sysdeps/unix/sysv/linux/x86_64/sysdep.S -c     -I../include -I/root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu  -I/root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86/include -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/11/include -isystem /usr/include -D_LIBC_REENTRANT -include /root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC -DSHARED     -DTOP_NAMESPACE=glibc -DASSEMBLER -I/root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu/. -fcf-protection -include cet.h -g -Wa,--generate-missing-build-notes=yes -Werror=undef -Wa,--noexecstack   -o /root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu/sysdep.os -MD -MP -MF /root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu/sysdep.os.dt -MT /root/glibc/glibc-2.33.9000-984-gddcc612ce9/build-x86_64-redhat-linux/csu/sysdep.os

--- Additional comment from Mark Wielaard on 2021-07-26 12:46:21 UTC ---

Strangely when removing -DPIC from the command line makes the .debug_* sections appear again... I don't know why.

--- Additional comment from Siddhesh Poyarekar on 2021-07-26 12:53:11 UTC ---

(In reply to Mark Wielaard from comment #11)
> Strangely when removing -DPIC from the command line makes the .debug_*
> sections appear again... I don't know why.

The TU is empty if PIC is defined:

~~~~
#ifndef PIC                                                                     
                                                                                
/* The syscall stubs jump here when they detect an error.                       
   The code for Linux is almost identical to the canonical Unix                 
   code, except that the error number in %rax is negated.  */                   
                                                                                
#undef CALL_MCOUNT                                                              
#define CALL_MCOUNT /* Don't insert the profiling call, it clobbers %rax.  */   
                                                                                
        .text                                                                   
ENTRY (__syscall_error)                                                         
        neg %RAX_LP                                                             
                                                                                
#define __syscall_error __syscall_error_1                                       
#include <sysdeps/unix/x86_64/sysdep.S>                                         
                                                                                
#endif  /* !PIC */               
~~~~

--- Additional comment from Mark Wielaard on 2021-07-26 13:50:40 UTC ---

So that explains the sysdep.o not having debuginfo when -DPIC is defined.

Found another example (thanks Siddhesh).
memcpy-ssse3-back.S

Which generates:

DWARF section [13] '.debug_info' at offset 0x3964:
 [Offset]
 Compilation unit at offset 0:
 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 Unit type: compile (1)
 [     c]  compile_unit         abbrev: 1
           stmt_list            (sec_offset) 0
           low_pc               (addr) .text.ssse3+000000000000000000 <__mempcpy_chk_ssse3_back>
           high_pc              (udata) 11014 (.text.ssse3+0x0000000000002b06)
           name                 (strp) "memcpy-ssse3-back.S"
           comp_dir             (strp) "/root/glibc/glibc-2.33.9000-984-gddcc612ce9/string"
           producer             (strp) "GNU AS 2.36.1"
           language             (data2) Mips_Assembler (32769)

[...]
Directory table:
      [path(line_strp)]
 0     ../sysdeps/x86_64/multiarch (0)
 1     ../sysdeps/x86_64/multiarch (28)

File name table:
      [path(line_strp), directory_index(udata)]
 0     memcpy-ssse3-back.S (56),  0
 1     memcpy-ssse3-back.S (76),  1

Note how the directory path zero is a relative path.
That isn't allowed, and it is unclear what it is relative to.
It is relative to the comp_dir entry.
But in DWARF5 the zero dir path entry is supposed to be equal to the comp_dir entry.

This is a bug in binutils GAS.

But we might be able to workaround it in debugedit. We do need to track the CU comp_dir and match it to the line table entry. Then if the zero dir path entry is relative (doesn't start with /) we need to prepend the comp_dir. We also need to do that for the first entry. Which is unfortunate, since normally relative paths are relative to the zero entry...

--- Additional comment from Frank Ch. Eigler on 2021-07-26 14:10:36 UTC ---

Reassigning to binutils.