https://sourceware.org/bugzilla/show_bug.cgi?id=27303
--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> ---
(In reply to Cary Coutant from comment #2)
> I haven't yet managed to get a clean build of GCC 11 to try to reproduce,
> but I do have a suspicion. Gold reverses the .ctors entries in .init_array,
> after applying relocations, but it does not attempt to reverse any dynamic
> relocations. That's normally not an issue, as we shouldn't have dynamic
> relocations for entries in the .ctors sections, but there might be something
> forcing the linker to create them. (The clue is that you had to start the
> process in gdb before printing the .init_array entries.)
Ah, dynamic relocations is a good clue! I have dynamic relocations due to gcc
being built with --enable-default-pie. Adding -no-pie makes tests pass.
> Please attach the output of:
>
> readelf -rsW initpri3.o
Will do.
$ objdump -D -r initpri3.o
does show relocations:
Disassembly of section .ctors:
0000000000000000 <ctors>:
...
0: R_X86_64_64 .text+0x44
8: R_X86_64_64 .text
> readelf -rW initpri3a # (or ig from your example)
Will do.
> I'm tempted to remove the whole --ctors-in-init-array option and this test
> case. GCC hasn't used the .ctors section in years now, as far as I know.
>
> But I'd like to understand what's causing this failure. If the cause is
> dynamic relocations, I'd like to understand what's causing the linker to
> generate them.
--
You are receiving this mail because:
You are on the CC list for the bug.
