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 <j...@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
