[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.

["gcc-bugzilla at mkarcher dot dialup.fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>]

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