https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On April 7, 2020 5:09:02 PM GMT+02:00, "gcc-bugzilla at mkarcher dot dialup.fu-berlin.de" <gcc-bugzi...@gcc.gnu.org> wrote: >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 Ah, I tried with -m32 and a cross to ppc64 which might end up using a different ABI
