Bug 1966987 - fedora 34+ debugsource files lack assembler .S files
Summary: fedora 34+ debugsource files lack assembler .S files
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1986018
TreeView+ depends on / blocked
 
Reported: 2021-06-02 10:02 UTC by Frank Ch. Eigler
Modified: 2022-12-13 15:24 UTC (History)
15 users (show)

Fixed In Version: binutils-2.37-6.fc35
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1986018 (view as bug list)
Environment:
Last Closed: 2022-12-13 15:24:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Sourceware 26778 0 None None None 2021-08-03 17:36:23 UTC

Description Frank Ch. Eigler 2021-06-02 10:02:31 UTC
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.

Comment 1 Florian Weimer 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.

Comment 2 Frank Ch. Eigler 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.

Comment 3 Mark Wielaard 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.

Comment 4 Frank Ch. Eigler 2021-06-02 12:18:02 UTC
From my quick sampling tests, debugsource files
contain .S files <= fc33
lack .S files >= fc34

Comment 5 Frank Ch. Eigler 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.

Comment 6 Frank Ch. Eigler 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.

Comment 7 Frank Ch. Eigler 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

Comment 8 Frank Ch. Eigler 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]

Comment 9 Mark Wielaard 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 ...

Comment 10 Mark Wielaard 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

Comment 11 Mark Wielaard 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.

Comment 12 Siddhesh Poyarekar 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 */               
~~~~

Comment 13 Mark Wielaard 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...

Comment 14 Frank Ch. Eigler 2021-07-26 14:10:36 UTC
Reassigning to binutils.

Comment 15 Mark Wielaard 2021-07-26 14:15:08 UTC
(In reply to Mark Wielaard from comment #13)
> 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)

Note that comp_dir + name isn't a valid path in this case. Which is another bug in gas.

> [...]
> 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...

This is actually easier said than done.
Because in DWARF5 we don't need to track the CU comp_dir we don't actually do that in debugedit.
dwarf4 and dwarf5 debug_line reading is done is separate passes

Comment 16 Ben Cotton 2021-08-10 13:44:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 17 Nick Clifton 2021-08-11 14:11:50 UTC
Fixed in binutils-2.37-4.fc35.  

(Note: Fixed-In field set to binutils-2.37-6.fc35 since there have been a couple of other minor bug fixed in the interim).

Comment 18 Ben Cotton 2022-11-29 16:58:19 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 19 Ben Cotton 2022-12-13 15:24:24 UTC
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.