[Bug ipa/98106] New: gcc trunk miscompiles glibc dynamic loader

[Bug ipa/98106] New: gcc trunk miscompiles glibc dynamic loader

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106

            Bug ID: 98106
           Summary: gcc trunk miscompiles glibc dynamic loader
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: romain.geissler at amadeus dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi,

I would like to report a regression in trunk which for me result in glibc
segfaulting in the dynamic linker at the very beginning of symbol resolution.

I do compile binutils 2.35 (from the release branch, I use git commit
1c5243df7f8c0a18f1518825ab1dacdf40188a41), then gcc, and with the resulting gcc
+ binutils I build glibc (taken from a rather recent commit from master, git
sha1 29fddfc7dfd6444fa61a256e9a0d0127545e1f2e). I build this on x86_64, using
just the CFLAGS/CXXFLAGS "-O2" when building all these components. This
resulting glibc seems to be miscompiled, as running any program with its
dynamic linker results in this seg fault:


root@e92b8eb029ef:/# /workdir/build/temporary-system/install/lib/libc.so.6
Segmentation fault (core dumped)              
root@e92b8eb029ef:/# gdb /workdir/build/temporary-system/install/lib/libc.so.6
GNU gdb (Debian 8.2.1-2+b3) 8.2.1

 ... (snapped)

Reading symbols from
/workdir/build/temporary-system/install/lib/libc.so.6...done.
(gdb) r
Starting program: /workdir/build/temporary-system/install/lib/libc.so.6

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fdadf0 in _dl_lookup_symbol_x () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2

(gdb) bt
#0  0x00007ffff7fdadf0 in _dl_lookup_symbol_x () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2
#1  0x00007ffff7fd3627 in dl_main () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2
#2  0x00007ffff7fea277 in _dl_sysdep_start () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2
#3  0x00007ffff7fd2009 in _dl_start () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2
#4  0x00007ffff7fd1058 in _start () from
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2
#5  0x0000000000000001 in ?? ()
#6  0x00007fffffffeeae in ?? ()
#7  0x0000000000000000 in ?? ()

(gdb) info shared
>From                To                  Syms Read   Shared Object Library
0x00007ffff7fd1050  0x00007ffff7ff132e  Yes (*)    
/workdir/build/temporary-system/install/lib/ld-linux-x86-64.so.2

(gdb) disas
(*): Shared library is missing debugging information.
Dump of assembler code for function _dl_lookup_symbol_x:
   0x00007ffff7fdade0 <+0>:     push   %r15
   0x00007ffff7fdade2 <+2>:     push   %r14
   0x00007ffff7fdade4 <+4>:     push   %r13
   0x00007ffff7fdade6 <+6>:     push   %r12
   0x00007ffff7fdade8 <+8>:     mov    %rdi,%r12
   0x00007ffff7fdadeb <+11>:    push   %rbp
   0x00007ffff7fdadec <+12>:    mov    %rdx,%rbp
   0x00007ffff7fdadef <+15>:    push   %rbx
=> 0x00007ffff7fdadf0 <+16>:    mov    %fs:0x10,%rax
   0x00007ffff7fdadf9 <+25>:    sub    $0x98,%rsp
   0x00007ffff7fdae00 <+32>:    mov    %rsi,0x8(%rsp)
   0x00007ffff7fdae05 <+37>:    mov    %rcx,0x18(%rsp)
   0x00007ffff7fdae0a <+42>:    mov    %r8,(%rsp)
   0x00007ffff7fdae0e <+46>:    mov    %r9d,0x14(%rsp)
   0x00007ffff7fdae13 <+51>:    mov    %rax,0x28(%rsp)
   0x00007ffff7fdae18 <+56>:    movzbl (%r12),%edx
   0x00007ffff7fdae1d <+61>:    test   %dl,%dl
   0x00007ffff7fdae1f <+63>:    je     0x7ffff7fdb050 <_dl_lookup_symbol_x+624>
   0x00007ffff7fdae25 <+69>:    mov    %r12,%rcx
   0x00007ffff7fdae28 <+72>:    mov    $0x1505,%ebx 
   0x00007ffff7fdae2d <+77>:    nopl   (%rax)

(gdb) info reg

rax            0x7fffffffe980      140737488349568
rbx            0x7fffffffe9a0      140737488349600
rcx            0x7ffff7ffeb08      140737354132232
rdx            0x7fffffffe978      140737488349560
rsi            0x7ffff7ffe770      140737354131312
rdi            0x7ffff7ff32ea      140737354085098
rbp            0x7fffffffe978      0x7fffffffe978
rsp            0x7fffffffe8b8      0x7fffffffe8b8
r8             0x7fffffffe9a0      140737488349600
r9             0x0                 0
r10            0x70000022          1879048226
r11            0x32                50
r12            0x7ffff7ff32ea      140737354085098
r13            0x7ffff7ffe770      140737354131312
r14            0x7fffffffe978      140737488349560
r15            0x0                 0
rip            0x7ffff7fdadf0      0x7ffff7fdadf0 <_dl_lookup_symbol_x+16>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0


Gcc's trunk from early november had no problem, but trunk from 1st december
does expose this problem. I could bisect this regression, pointing at this
commit:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=520d5ad337eaa15860a5a964daf7ca46cf31c029;hp=2873c8af66e1248734bb638a49e6bc53f5e45382

commit 520d5ad337eaa15860a5a964daf7ca46cf31c029
Author: Jan Hubicka <jh@suse.cz>
Date:   Sat Nov 14 13:52:36 2020 +0100

    Detect EAF flags in ipa-modref

    A minimal patch for the EAF flags discovery.  It works only in local
ipa-modref
    and gives up on cyclic SSA graphs.  It improves pt_solution_includes
    disambiguations twice.


I don't know how to progress further on investigating this problem.


For what it is worth, here is an assembly dump of the same function on a
working glibc built from the sources of early november more or less the same
way (using the exact same glibc source commit
29fddfc7dfd6444fa61a256e9a0d0127545e1f2e):

Dump of assembler code for function _dl_lookup_symbol_x:
=> 0x00007ffff7fdae20 <+0>:     push   %r15
   0x00007ffff7fdae22 <+2>:     push   %r14
   0x00007ffff7fdae24 <+4>:     push   %r13
   0x00007ffff7fdae26 <+6>:     mov    %rdx,%r13
   0x00007ffff7fdae29 <+9>:     push   %r12
   0x00007ffff7fdae2b <+11>:    mov    %rdi,%r12
   0x00007ffff7fdae2e <+14>:    push   %rbp
   0x00007ffff7fdae2f <+15>:    push   %rbx
   0x00007ffff7fdae30 <+16>:    sub    $0x98,%rsp
   0x00007ffff7fdae37 <+23>:    movzbl (%rdi),%edx
   0x00007ffff7fdae3a <+26>:    mov    %rsi,0x10(%rsp)
   0x00007ffff7fdae3f <+31>:    mov    %rcx,0x20(%rsp)
   0x00007ffff7fdae44 <+36>:    mov    %r8,0x8(%rsp)
   0x00007ffff7fdae49 <+41>:    mov    %r9d,0x1c(%rsp)
   0x00007ffff7fdae4e <+46>:    test   %dl,%dl
   0x00007ffff7fdae50 <+48>:    je     0x7ffff7fdb090 <_dl_lookup_symbol_x+624>
   0x00007ffff7fdae56 <+54>:    mov    %rdi,%rcx
   0x00007ffff7fdae59 <+57>:    mov    $0x1505,%ebx
   0x00007ffff7fdae5e <+62>:    xchg   %ax,%ax
   0x00007ffff7fdae60 <+64>:    mov    %rbx,%rax


Where we don't see and %fs access.

Cheers,
Romain

[Bug ipa/98106] gcc trunk miscompiles glibc dynamic loader

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say the next step after bisecting a gcc change is bisect which source file
it is on (if you have a suspect one, just confirm that, e.g. if you compile the
whole dynamic linker with the trunk gcc (or the r11-5029 version) and just that
single TU with r11-5028, does it still work?  And vice versa, if you compile
everything with r11-5028 and only the single TU with r11-5029, does it crash
too?

In that case, please attach preprocessed source of that TU and state exact gcc
command line options.

Thanks.

[Bug ipa/98106] gcc trunk miscompiles glibc dynamic loader

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-12-02

[Bug ipa/98106] [11 Regression] gcc trunk miscompiles glibc dynamic loader

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|gcc trunk miscompiles glibc |[11 Regression] gcc trunk
                   |dynamic loader              |miscompiles glibc dynamic
                   |                            |loader
   Target Milestone|---                         |11.0
           Severity|normal                      |blocker

[Bug ipa/98106] [11 Regression] gcc trunk miscompiles glibc dynamic loader

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98106

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another PR has more details.

*** This bug has been marked as a duplicate of bug 98110 ***