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

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

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

            Bug ID: 94504
           Summary: On powerpc, -ffunction-sections -fdata-sections is not
                    as effective as expected for PIE executables.
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

I try to compile the following test program using

gcc -ffunction-sections -fdata-sections -pie -Wl,--gc-sections input.c

The linking step fails, because g is not defined. On most architectures except
powerpc (32 bit), the garbage collection is able to discard both fptr and f,
and so the reference to g vanishes. This is not the case on powerpc, where f is
referencing fptr through a GOT entry in the .got2 section.

This issue (I don't dare to call it "bug" yet) is the cause of of
https://bugs.debian.org/955845. The librsvg build process is quirky and
building the tests only works if garbage collection is able to collect a hughe
amount of dead code. Garbage collection is able to do that on all architectures
Debian tried it on except for powerpc (and possibly ppc64, see
https://bugs.debian.org/895723). The attached example program does compile fine
on ppc64, though.

/* dead code */
extern void g(int x, ...);
extern void (*fptr)();
void f()
{
        /* using fptr creates a GOT entry for fptr */
        g(0, fptr);
}
/* fptr is reference from the GOT. Let's reference f from fptr */
void (*fptr)() = f;

/* Non-dead code */
int x = 5;
int main(void)
{
        /* using x goes through the GOT. This prevents the GC to kill it */
        return x;
}

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
gc-sections with a GOT is probably difficult since I'm quite sure we don't have
an extra section for every datum in the GOT.  Likely applies to the PLT as
well.

Of course relying on --gc-sections to "fix" your link because you are missing
definitions is more than fragile...

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?

[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]

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

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

[rguenther at suse dot de]

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-bugzilla@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

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

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

--- Comment #5 from Michael Karcher <gcc-bugzilla at mkarcher dot dialup.fu-berlin.de> ---
I got the command line of gcc wrong. "-pie" just sets the linker flags for PIE
linking, but it does *not* compile source code as PIE. If I use "-fpie",
garbage collection does what it is supposed to do.

As I found out, the acutal problem I have is completely unrelated to gcc (sorry
for the noise here), because it concerns object files created by rustc (which
has an llvm backend) linked by binutil's ld tool. At the moment I was able to
reproduce the same symptom I have with those rust objects with a ten-line C
program, I considered fixing the problem (if possible) for C first a good idea.

As it stands now, the issue in gcc (no effective garbage collection for non-PIE
executables with function pointers in global data structures) still stands, so
I am not closing the bug right away.

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

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX
            Summary|On powerpc,                 |On powerpc,
                   |-ffunction-sections         |-ffunction-sections
                   |-fdata-sections is not as   |-fdata-sections is not as
                   |effective as expected for   |effective as expected for
                   |non-PIE executables.        |PIE and PIC

--- Comment #6 from Alan Modra <amodra at gmail dot com> ---
For -fPIC or -fPIE on ppc32 gcc uses a per-object file compiler managed GOT
(.got2).  Fixed position code doesn't use a GOT.  -fpic/-fpie uses a linker
managed GOT but with limited size.  So, correcting the summary.

The problem reported here is due to the per-object file nature of .got2. (.got2
is similar to the per-object file ppc64 .toc, where compiling the testcase with
-mcmodel=large gives the same link failure.)  To handle -gc-sections properly,
ld needs to treat .got2 specially so that a relocation reference to .got2 does
not mark .got2 but rather the section referenced by the relevant .got2 entry,
and then remove unneeded .got2 entries.  No one has cared enough to write such
linker support for ppc32 or for large code model ppc64 .toc.  Alternatively gcc
code generated for -fPIC/-fPIE could be changed, but again no one has cared
enough to do that.

Since it is very unlikely that a bugzilla entry for gcc or binutils will prompt
anyone to write the necessary linker support or change gcc, I'm closing this as
won't fix.

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

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504

--- Comment #7 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Alan Modra from comment #6)
> Since it is very unlikely that a bugzilla entry for gcc or binutils will
> prompt anyone to write the necessary linker support or change gcc, I'm
> closing this as won't fix.

Isn't that what "severity: wishlist" is for?

You just explained that there is a limitation in binutils on POWER and we have
seen at least one case where this limitation causes problems, so I think it's
fair to keep this bug report open in case someone else runs into this
particular problem and decides to fix the bug.

I don't think it's safe to assume that no one is going to fix this bug unless
you have a crystal ball.