https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
--- Comment #3 from Michael Karcher <gcc-bugzilla at mkarcher dot dialup.fu-berlin.de> --- (In reply to Richard Biener from comment #2) > Huh, looking at the assembly & the object file this seems to be fully a linker > issue who seems to be responsible for building the GOT. I suggest to move > this over to sourceware. Alan? I'm not so sure about this. I think it might actually be a limitation of ELF on ppc32: If I compare the code generated by gcc on ppc32, gcc does output a GOT fragment in the .got2 section that references all globals that are used in the current object: $ objdump -r -j .got2 bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.got2]: OFFSET TYPE VALUE 00000000 R_PPC_ADDR32 fptr 00000004 R_PPC_ADDR32 x This section can not be elided, because it is referenced from main: $ objdump -r -j .text.main bla32.o bla32.o: file format elf32-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 00000022 R_PPC_REL16_HA .got2+0x00008006 00000026 R_PPC_REL16_LO .got2+0x0000800a The linker has no obvious way to detect which GOT slots are actually used inside main, because the offset(s) of the slot(s) inside .got2 used by main are hardcoded inside main. On the other hand, on ppc64, there is no GOT fragment generated by the compiler, but instead the compiler just asks the linker to create a GOT slot and fill in the necessary information: $ objdump -r -j .text.main bla64.o bla64.o: file format elf64-powerpc RELOCATION RECORDS FOR [.text.main]: OFFSET TYPE VALUE 000000000000000e R_PPC64_TOC16_HA x 0000000000000012 R_PPC64_TOC16_LO x
