[Bug 239007] lang/gcc8 enable secure-plt by default for powerpc*

[email protected]
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239007

Mark Millard <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #5 from Mark Millard <[email protected]> ---
(In reply to Justin Hibbits from comment #3)

For system-clang-b-ased cross build contexts,
possibly including powerpc64 building its lib32,
what I've observed follows (in hopes that it
will help track things down).

For lld based ld . . .

From what I've seen via trying cc/c++ commands
that target linking for 32-bit powerpc, with with
-### added, the linker command has the likes of:

"-m" "elf32ppc_fbsd"

and I do not see anything else that it is given
on the command line that directly indicates a
32-bit powerpc context.

So my guess is that the linker needs to enable
allowing the --secure-plt option based on the
likes of that -m elf32ppc_fbsd .

lld does not do this yet and rejects the
option.



As for modern gnu ld . . .

Modern gnu ld does allow the --secure-plt (as
does the historical FreeBSD system binutils).

But, unlike the old FreeBSD binutils, modern
gnu ld returns an error code when --secure-plt
was specified but the linker reports the likes
of:

/usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ...

(and it does report such during builds when
system-clang is used).

The non-zero return status from ld stops the
build when such a modern gnu ld is used.

The easiest way to see many of using bss-plt
messages is to search building with system clang
and the historical freebsd binutils:

Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crt1.o
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(fixdfdi.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(fixsfdi.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatdidf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatdisf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatundidf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatundisf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(moddi3.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(umoddi3.o)
Using bss-plt due to accf_http.kld
Using bss-plt due to acl_nfs4.kld
Using bss-plt due to acl_posix1e.kld
Using bss-plt due to if_ae.kld
Using bss-plt due to if_age.kld
Using bss-plt due to reloc.o

Note: This stopped where it did because of:

--- agp.ko.full ---
ld: agp.kld(.text+0x37a4): R_PPC_PLTREL24 reloc against local symbol
agp.kld: could not read symbols: Bad value
*** [agp.ko.full] Error code 1

so there might be more places.

(I'll not here get into why gnu ld decides that
bss-plt is to be used for the clang output.)


Between the two types of modern ld's, I've not managed
a system-clang based 32-bit powerpc cross build since
the secure-plt switch was made.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.