From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AB8523887016; Tue, 7 Apr 2020 17:14:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB8523887016 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586279692; bh=92r1wO3zNckeKanANnQ778IUyZgrLyN+Yg8BKJyTnVo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DAN3P/Hgwv1vrWSYoPZFTqtPz13KF6hsHBE6JtLOd3SxvW7DC5NQIAl7ivroPsRL+ UJSYKajESoLSXgN/SliF6Kz5JNvkLkXuHkoIiFoLcpwjnp3vhygfdqHDGzEhkCRvl6 luZXsdJ9e6IlQ7nPUBHonFvRDwc8ujQzaHjvnpIs= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables. Date: Tue, 07 Apr 2020 17:14:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 9.3.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 17:14:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94504 --- Comment #4 from 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" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94504 > >--- Comment #3 from Michael Karcher 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 diffe= rent ABI=