This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: better detection of old powerpc bss-plt objects
- From: Jakub Jelinek <jakub at redhat dot com>
- To: binutils at sourceware dot org
- Date: Mon, 30 Jul 2007 21:19:55 +0200
- Subject: Re: better detection of old powerpc bss-plt objects
- References: <20070511063737.GB12499@bubble.grove.modra.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, May 11, 2007 at 04:07:37PM +0930, Alan Modra wrote:
> This patch fixes an irritating feature of the powerpc linker in that
> secure-plt is only available on detecting relocs generated by a newer
> gcc with -fpic or -fPIC. This isn't a big deal since secure-plt is
> aimed squarely at people who will be using pie executables, however,
> there is no real reason a non-pic executable should be forced into
> using the old bss-plt.
>
> I also improve the detection of old object files by requiring REL16
> relocs to appear in the same object file as PLTREL24 rather than just
> somewhere in the input. This should help in cases where people mix
> old-style object files that make PLT calls but don't happen to use the
> GOT, with new style libraries or other object files. Without an
> old-style GOT pointer code sequence the linker wouldn't force
> bss-plt, and the new plt call stubs would segfault since they require
> a GOT pointer.
After this change executables with all objects built with -msecure-plt
(that's what we default in gcc for quite some time on ppc32), as an
example e.g. coreutils, but even int main () { return 0; } will do,
are suddenly using BSS PLT rather than the new
secure PLT. That has bad consequences with SELinux, all such
binaries are causing execmod audit messages when non-enforcing
or will not run at all when enforcing.
Was that just unintended side-effect of this patch, or do you want
gcc built with --enable-secure-plt pass --secure-plt to ld unless
-mbss-plt (and --disable-secure-plt gcc pass --secure-plt when
-msecure-plt)?
Jakub