ld.gold error unsupported -mbss-plt code

[Chris Packham]

On Thu, Jul 25, 2024 at 5:05 AM Peter Bergner <bergner@linux.ibm.com> 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.  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?
>

For the record configuring my toolchain with --enable-secureplt seems
to resolve the issue.