https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the good case,
_Unwind_Find_FDE (pc=0x7ffff7dc32cb <_Unwind_Backtrace+59>,
bases=bases@entry=0x7fffffffe008) at ../../../libgcc/unwind-dw2-btree.h:860
calls _dl_find_object on that pc and it gives
(gdb) p dlfo
$5 = {dlfo_flags = 0, dlfo_map_start = 0x7ffff7da0000, dlfo_map_end =
0x7ffff7dcf3c8, dlfo_link_map = 0x55555555c2d0, dlfo_eh_frame = 0x7ffff7dc8af4,
__dflo_reserved = {0, 1933,
140737353382200, 140737353867808, 140737488346600, 140737488346596, 0}}
which looks ok because that address is at 0x232cb from start of the library.
In the bad case we get for the same address in libgcc_s loaded at the same base
$7 = {dlfo_flags = 0x0, dlfo_map_start = 0x0, dlfo_map_end = 0x7ffff7ffe310,
dlfo_link_map = 0x7ffff7ffdda0, dlfo_eh_frame = 0x7ffff7ff5c58, __dflo_reserved
= {0x0, 0x78d,
0x7ffff7f47938, 0x7ffff7fbe220, 0x7fffffffdde8, 0x7fffffffdde4, 0x0}}
so it looks like the ld.so entry spans all addresses from 0 to end of the ld.so
mapping (0x7ffff7ffe310 matches
7ffff7fc6000-7ffff7fc7000 r--p 00000000 103:03 1853108
/tmp/build2/elf/ld.so
7ffff7fc7000-7ffff7fef000 r-xp 00001000 103:03 1853108
/tmp/build2/elf/ld.so
7ffff7fef000-7ffff7ffb000 r--p 00029000 103:03 1853108
/tmp/build2/elf/ld.so
7ffff7ffb000-7ffff7ffd000 r--p 00035000 103:03 1853108
/tmp/build2/elf/ld.so
7ffff7ffd000-7ffff7ffe000 rw-p 00037000 103:03 1853108
/tmp/build2/elf/ld.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
).
That is
_dl_rtld_map.l_map_start = (ElfW(Addr)) &__ehdr_start;
_dl_rtld_map.l_map_end = (ElfW(Addr)) _end;
__ehdr_start is for both the good and bad linker:
readelf -Wa build*/elf/ld.so | grep __ehdr_start
354: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 __ehdr_start
354: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 __ehdr_start
so it just seems that in the bad case the relocation for it hasn't been done.
