ld.gold error unsupported -mbss-plt code

[Alan Modra]

On Wed, Jul 24, 2024 at 12:05:40PM -0500, Peter Bergner wrote:
> On 7/24/24 3:24 AM, Chris Packham wrote:
> > On Wed, Jul 24, 2024 at 2:00 PM Alan Modra <amodra@gmail.com> wrote:
> >> Around 2007, the powerpc ABI (and gcc and binutils) gained what I
> >> called secure-plt.  Prior to that, the powerpc plt section was a bss
> >> section that was written with code generated by ld.so.  This required
> >> a section that was both writable and executable, and therefore
> >> somewhat of a target for malicious code.  The new secure-plt ABI
> >> doesn't use an executable plt, but the code generated to make a call
> >> via the plt is a little slower than bss-plt in moderately sized
> >> executables and libraries.  Your gcc might be configured to generate
> >> bss-plt code by default, so to use ld.gold when linking shared
> >> libraries or PIEs you'd need to pass -msecure-plt to gcc when
> >> compiling.  If your project has assembly that makes bss-plt style
> >> calls then more work will be needed.
> > 
> > Thanks for the explanation. I think specifying -msecure-plt helps
> > reduce the number of errors but I still have the problem that
> > crtbeginS.o from the toolchain obviously still has the bss-plt style.
> > There might be some incantation I can pass to change how that's
> > generated but I'll take the easy way out and just disable ld.gold in
> > that configuration.
> 
> I think you need to configure gcc with --enable-secureplt to get crtbeginS.o
> built with non bss-plt style calls.

True.  libgcc too.  I can't remember why I decided ppc32 gcc didn't
need secure and bss multilibs, a fairly simple change that would
provide better support for -mbss-plt and -msecure-plt.

>  To be honest, I'm not sure why we
> don't default to that after all of the years since Alan's change.
> Alan, do you remember why we didn't make --enable-secureplt a default option?

At the time we wanted continuity with older gcc's.  There is also a
quite reasonable argument that bss-plt gives superior performance, and
therefore is desirable in embedded systems where there is no
possibility of executing malicious user code.

-- 
Alan Modra