[Bug other/60465] New: Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[Bug other/60465] New: Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[devurandom at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

            Bug ID: 60465
           Summary: Compiling glibc-2.17,2.18 with gcc-4.8.2 and
                    binutils-2.23.2,2.24 results in segfaults in _start /
                    elf_get_dynamic_info
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: devurandom at gmx dot net

Created attachment 32309
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32309&action=edit
backtrace (glibc-2.18,binutils-2.24,gcc-4.8.2)

I tried to build glibc-2.17 and 2.18 with binutils-2.23.2 or 2.24 and
gcc-4.8.2, but always run into the same segfault when loading programs with the
new runtime linker.

Please find a backtrace for the glibc-2.18, binutils-2.24, gcc-4.8.2
combination attached.

It crashes in exactly the same way when running without --library-path and when
running with ../usr/bin/locale (from glibc-2.18) or /bin/date as argument.

Since glibc-2.17 compiled fine with gcc-4.7.3, I assume that gcc-4.8.2 is to
blame.

The context of the crash is (according to glibc-2.18/elf/get-dynamic-info.h):
elf_get_dynamic_info (struct link_map *l, ElfW(Dyn) *temp) {
  ElfW(Dyn) **info;
  info = l->l_info;
  info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
+ DT_EXTRANUM + DT_VALNUM] = dyn;
}

GDB reports this function being called as:
elf_get_dynamic_info (temp=0x0, l=0x2000000800051458 <_rtld_local+2456>)

What I find to be suspicious is the changed order of parameters.

I would like to check this with valgrind, too, but it is not available on ia64
(i.e. anything but x86, ppc and arm).

See-Also: https://bugs.gentoo.org/show_bug.cgi?id=503838

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[devurandom at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #1 from devurandom at gmx dot net ---
Created attachment 32310
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32310&action=edit
emerge --info

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vapier at gentoo dot org

--- Comment #2 from Mike Frysinger <vapier at gentoo dot org> ---
*** Bug 60558 has been marked as a duplicate of this bug. ***

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[devurandom at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

devurandom at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |ia64-unknown-linux-gnu
      Known to work|                            |4.7.3
               Host|                            |ia64-unknown-linux-gnu
      Known to fail|                            |4.8.2
              Build|                            |ia64-unknown-linux-gnu

--- Comment #3 from devurandom at gmx dot net ---
 Mike Frysinger 2014-03-18 07:17:05 UTC

if you build current master glibc w/gcc-4.8.2 & binutils-2.23.2 like so:
  ../configure --prefix=/usr libc_cv_ehdr_start=no
  make -j4

then try to run a simple app like so:
  echo 'main(){puts("HI");}' | gcc -x c - -o a.out
  ./elf/ld.so --library-path $PWD ./a.out

it crashes like so:
  Segmentation fault (core dumped)

i suspect bad code generation because:
  - recompiling only elf/rtld.c w/gcc-4.7.3 produces a working build
  - the C code looks correct (via poking; see below)
  - tweaking the code slightly produces a working build w/4.8:
-  else if ((d_tag_utype) DT_ADDRTAGIDX (dyn->d_tag) < DT_ADDRNUM)
-    info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
-         + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
+    {
+      size_t i = DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
+                 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM;
+      info[i] = dyn;
+    }

throwing it into a debugger shows:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out 
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.

(gdb) run
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out

Program received signal SIGSEGV, Segmentation fault.
0x200000080000b010 in elf_get_dynamic_info (temp=0x0, l=0x2000000800051b08
<_rtld_local+2456>) at get-dynamic-info.h:61
61                   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;

(gdb) list
56            else if ((d_tag_utype) DT_VALTAGIDX (dyn->d_tag) < DT_VALNUM)
57              info[DT_VALTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
58                   + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
59            else if ((d_tag_utype) DT_ADDRTAGIDX (dyn->d_tag) < DT_ADDRNUM)
60              info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM
61                   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
62            ++dyn;
63          }
64
65      #define DL_RO_DYN_TEMP_CNT      8

the info pointer is sane:

(gdb) p &_rtld_global._dl_rtld_map.l_info 
$1 = (Elf64_Dyn *(*)[77]) 0x20000008000515d8 <_rtld_local+2520>
(gdb) print info
$2 = (Elf64_Dyn **) 0x20000008000515d8 <_rtld_local+2520>

as is the dyn tag:

(gdb) print dyn
$3 = (Elf64_Dyn *) 0x200000080004c8d8
(gdb) print *dyn
$4 = {
  d_tag = 0x6ffffef5, 
  d_un = {
    d_val = 0x2d8, 
    d_ptr = 0x2d8
  }
}

that calculated offset is 0x4c and the link map is big enough to hold it:

(gdb) print sizeof(_rtld_local._dl_rtld_map.l_info) /
sizeof(_rtld_local._dl_rtld_map.l_info[0])
$5 = 0x4d

but the assembly is clearly wrong:
(gdb) display/i $pc
1: x/i $pc
=> 0x200000080000b271 <_dl_start+2737>:       (p07) st8 [r14]=r15

(gdb) p $r15
$6 = 0x200000080004c8d8

(gdb) p $r14
$7 = 0x51838

$r15 is set to the right value (dyn), but r14 is now incomplete.  stepping
through the previous ~20 insns shows that the right value doesn't get near $r14
... but my ia64 asm skills are not great, so i could be missing something.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
How about showing the previous ~20 insns here.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #5 from Mike Frysinger <vapier at gentoo dot org> ---
Created attachment 32385
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32385&action=edit
gdb session

here's the trace from the first insn where dyn is pointing to DT_GNU_HASH.  at
this point, it has processed DT_SONAME and DT_HASH.

$ readelf -d build/elf/ld.so

Dynamic section at offset 0x3c8b8 contains 20 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             Library soname: [ld-linux-ia64.so.2]
 0x0000000000000004 (HASH)               0x190
 0x000000006ffffef5 (GNU_HASH)           0x2d8
 0x0000000000000005 (STRTAB)             0x998

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[devurandom at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #6 from devurandom at gmx dot net ---
Did anyone figure out what's going on? Did the gdb log bring new insights?

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #7 from Mike Frysinger <vapier at gentoo dot org> ---
it's beyond my (ia64 beginners) experience to track this down further

i can certainly make available ssh access to interested devs ... it's a fast
system on a fast edu connection

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[devurandom at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465

--- Comment #8 from devurandom at gmx dot net ---
(In reply to Mike Frysinger from comment #7)
> it's beyond my (ia64 beginners) experience to track this down further
> 
> i can certainly make available ssh access to interested devs ... it's a fast
> system on a fast edu connection

Similar situation and offer from me: Slow system on a fast connection available
for the dev who wants to track this down, but lacks an own machine.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #10 from Mike Frysinger <vapier at gentoo dot org> ---
i've bisected things back to r188118.  before that commit, gcc compiles rtld.c
fine and produces a working ldso.  starting at that commit, we get segfaults.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-08-14
     Ever confirmed|0                           |1

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> i've bisected things back to r188118.  before that commit, gcc compiles
> rtld.c fine and produces a working ldso.  starting at that commit, we get
> segfaults.

But not on the 4.7 branch, right?  In any case, we need preprocessed sources.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> i've bisected things back to r188118.  before that commit, gcc compiles
> rtld.c fine and produces a working ldso.  starting at that commit, we get
> segfaults.

In fact r188118 undoes a pessimization introduced just before in r188009 so the
bug was very likely preexisting on the mainline.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #12)
> > i've bisected things back to r188118.  before that commit, gcc compiles
> > rtld.c fine and produces a working ldso.  starting at that commit, we get
> > segfaults.
> 
> But not on the 4.7 branch, right?  In any case, we need preprocessed sources.

I bet the function f mentioned in the testcase from
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00932.html is enough to reproduce
the issue.  

DT_ADDRTAGIDX (dyn->d_tag) gets preprocessed as (0x6ffffeff - dyn->d_tag).

DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM is the
same as 34+0+16+3+12.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #15 from Mike Frysinger <vapier at gentoo dot org> ---
(In reply to Andrew Pinski from comment #11)

i tried 4.8.3 w/those two patches applied but still see the crash :(

(In reply to Eric Botcazou from comment #12)

correct, gcc-4.6.4 & gcc-4.7.3 work fine

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #16 from Mike Frysinger <vapier at gentoo dot org> ---
Created attachment 33321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33321&action=edit
rtld.i preprocessed source

the preprocessed output is the same between 4.7.4 & 4.8.3 (checked with `diff`)

this was generated with:
$ gcc rtld.c -E -dD -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wundef
-Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes  
-fPIC -D'SYSCONFDIR="/etc"'    -U_FORTIFY_SOURCE   -I../include
-I/home/vapier/glibc/build/elf  -I/home/vapier/glibc/build 
-I../sysdeps/unix/sysv/linux/ia64  -I../sysdeps/ia64/nptl 
-I../sysdeps/unix/sysv/linux/wordsize-64  -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 
-I../sysdeps/posix  -I../sysdeps/ia64/fpu  -I../sysdeps/ia64 
-I../sysdeps/wordsize-64  -I../sysdeps/ieee754/ldbl-96 
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754 
-I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT -include
../include/libc-symbols.h  -DPIC -DSHARED  -DNOT_IN_libc=1 -DIS_IN_rtld=1
-DIN_LIB=rtld     -D_ASM_IA64_CURRENT_H -o /home/vapier/glibc/build/elf/rtld.i

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #17 from Mike Frysinger <vapier at gentoo dot org> ---
(In reply to Eric Botcazou from comment #13)

fwiw, i took latest 4.8 branch and reverted that change, and ldso works

i'll test r188009 and related too though

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #18 from Mike Frysinger <vapier at gentoo dot org> ---
thanks for your help Eric.  new bisection shows r187042 as a possible culprit. 
feel free to de-cc yourself :).

Richard: any thoughts here ?  this change is a bit harder to test reverting in
the latest 4.8 branch to see if it makes a difference.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #19 from Mike Frysinger <vapier at gentoo dot org> ---
Created attachment 33340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33340&action=edit
rtld.s generated -- passing w/r187038

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #20 from Mike Frysinger <vapier at gentoo dot org> ---
Created attachment 33341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33341&action=edit
rtld.s generated -- failing w/r187042

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> thanks for your help Eric.  new bisection shows r187042 as a possible
> culprit.  feel free to de-cc yourself :).

I'll keep investigating because this rings a bell, we had the same issue on
SPARC 64-bit at some point and this might be a hole in the IA-64 back-end.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Mike Frysinger from comment #18)
> thanks for your help Eric.  new bisection shows r187042 as a possible
> culprit.  feel free to de-cc yourself :).
> 
> Richard: any thoughts here ?  this change is a bit harder to test reverting
> in the latest 4.8 branch to see if it makes a difference.

Well, usual errors regarding to sizetype apply - you have to treat it
as sign-extending if you promote it to larger types (but I doubt that happens
or matters for ia64 as pointers should be DImode, right?).

But you should be able to spot code-gen differences and see where they
originate
from (the revision wasn't supposed to change code-gen though zero differences
wasn't really possible).

I'll wait for Erics investigation.  (ia64 is a dead architecture IMNSHO)

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Created attachment 33349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33349&action=edit
Reduced testcase

To be compiled at -O1.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I might have a plausible scenario, but I'd need more info:

  1. the options used to link the runtime linker

  2. the value of registers r25 and r23 right after:

   0x200000080000a8f0 <+304>:   [MMI]       ld8 r25=[r25]
   0x200000080000a8f1 <+305>:               ld8 r23=[r23]
   0x200000080000a8f2 <+306>:               nop.i 0x0;;

for the invocation of _dl_start that leads to the segfault.

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gentoo dot org]

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

--- Comment #25 from Mike Frysinger <vapier at gentoo dot org> ---
here's the series of link commands:
gcc -nostdlib -nostartfiles -r -o elf/librtld.os \
  '-Wl,-(' /home/vapier/glibc/build/elf/dl-allobjs.os elf/rtld-libc.a -lgcc \
  '-Wl,-)' -Wl,-Map,elf/librtld.os.map
gcc -nostdlib -nostartfiles -shared -o elf/ld.so \
  -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
  elf/librtld.os -Wl,--version-script=./ld.map \
      -Wl,-soname=ld-linux-ia64.so.2 \
      -Wl,-defsym=_begin=0

in my disassembly it's using r24 & r22, but i'm guessing that doesn't matter
terribly much:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out 
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.
(gdb) b *_dl_start+304
Breakpoint 1 at 0xabb0: file get-dynamic-info.h, line 61.
(gdb) display /i $pc
(gdb) display $r24
(gdb) display $r22
(gdb) r
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out

Breakpoint 1, elf_get_dynamic_info (temp=0x0, l=0x20000008000510c8
<_rtld_local+2456>) at get-dynamic-info.h:61
61                   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x20000008000505d8
2: $r24 = 0x20000008000505d8
1: x/i $pc
=> 0x200000080000abb0 <_dl_start+304>:  [MMI]       ld8 r24=[r24]
(gdb) stepi
58                   + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
3: $r22 = 0x20000008000505d8
2: $r24 = 0x380050730
1: x/i $pc
=> 0x200000080000abb1 <_dl_start+305>:              ld8 r22=[r22]
(gdb) stepi
61                   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x380050730
2: $r24 = 0x380050730
1: x/i $pc
=> 0x200000080000abb2 <_dl_start+306>:              nop.i 0x0;;
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x200000080000b5f1 in elf_get_dynamic_info (temp=0x0, l=0x20000008000510c8
<_rtld_local+2456>) at get-dynamic-info.h:61
61                   + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
3: $r22 = 0x3800502b0
2: $r24 = 0x380050b10
1: x/i $pc
=> 0x200000080000b5f1 <_dl_start+2929>:       (p07) st8 [r14]=r15
(gdb)

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33349|0                           |1
        is obsolete|                            |

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Created attachment 33365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33365&action=edit
Better reduced testcase

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Thanks.  This seems to be a conjunction of several factors, the initial one
being that the 4.8+ compiler generates (e.g for the reduced testcase at -O):

        addl r14 = @ltoffx(_rtld_local#+15032385536), r1
        ;;
        ld8.mov r14 = [r14], _rtld_local#+15032385536

The huge number is not problematic per se, although it very likely runs afoul
of some limitation/quirk here, since the value loaded from the GOT is
truncated.

In fact it looks like the value loaded from the GOT is just the huge number,
that is to say the value of _rtld_local has been zeroed during the relocation.

This may come from _rtld_local being in the .sdata section, in which case there
is a relevant comment in sdata_symbolic_operand:

      /* Deny the stupid user trick of addressing outside the object.  Such
     things quickly result in GPREL22 relocation overflows.  Of course,
     they're also highly undefined.  From a pure pedant's point of view
     they deserve a slap on the wrist (such as provided by a relocation
     overflow), but that just leads to bugzilla noise.  */

In other words, the compiler skips the efficient @gprel relocation on purpose,
only to generate the @ltoffx relocation, which doesn't work either here...