On Thu, Oct 15, 2015 at 1:50 PM, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: > A powerpc toolchain built with (or without) --enable-secureplt > currently creates a binary that uses bss plt if > > (1) any of the linked PIC objects have bss plt relocs > (2) or all the linked objects are non-PIC or have no relocs, > > because this is the binutils linker behaviour. > > This patch passes --secure-plt to the linker which makes the linker > warn in case (1) and produce a binary with secure plt in case (2). > > Without passing --secure-plt, case (2) can happen to the main executable. > Currently glibc avoids this because there is always PIC code linked > in (elf/elf-init.oS through libc_nonshared.a), but e.g. with musl libc > the linker heuristic fails to produce secure plt in the main executable. > > Shared objects have PIC code linked in from the compiler start code, > but with -nostartfiles one can create a shared object that is not secure > (has writable, executable section). > > Visible changes: > > * linking non-secureplt code with secureplt gcc will emit warnings > at link time (e.g. linking a main executable with non-secureplt > glibc). > * if binutils is old (<2.18 i think) then --secure-plt is unrecognised > (causing a link error). > > If these are undesirable then the flag can be made conditional > on musl libc. The patch is split out from the musl support patch: > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01640.html > > gcc/ChangeLog: > > 2015-10-15 Gregor Richards <gregor.richa...@uwaterloo.ca> > Szabolcs Nagy <szabolcs.n...@arm.com> > > * config/rs6000/secureplt.h (LINK_SECURE_PLT_DEFAULT_SPEC): Define. > * config/rs6000/sysv4.h (LINK_SECURE_PLT_DEFAULT_SPEC): Define. > (LINK_SPEC): Add %(link_secure_plt_default). > (SUBTARGET_EXTRA_SPECS): Add "link_secure_plt_default".
I'll let Alan comment on this. - David
