glibc/sysdeps/loongarch/configure.ac

54 lines
1.9 KiB
Plaintext
Raw Normal View History

2022-07-19 01:22:07 +00:00
GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
# Local configure fragment for sysdeps/loongarch/elf.
dnl It is always possible to access static and hidden symbols in an
dnl position independent way.
AC_DEFINE(HIDDEN_VAR_NEEDS_DYNAMIC_RELOC)
dnl Test if the toolchain is new enough for static PIE.
dnl We need a GAS supporting explicit reloc (older GAS produces stack-based
dnl reloc and triggers an internal error in the linker). And, we need GCC to
dnl pass the correct linker flags for static PIE. GCC >= 13 and GAS >= 2.40
dnl satisify the requirement, but a distro may backport static PIE support into
dnl earlier GCC or Binutils releases as well.
AC_CACHE_CHECK([if the toolchain is sufficient to build static PIE on LoongArch],
libc_cv_static_pie_on_loongarch, [
LoongArch: Fix the condition to use PC-relative addressing in start.S A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
2022-10-02 14:23:09 +00:00
cat > conftest1.S << EOF
.global _start
.type _start, @function
_start:
li.w \$a7, 93
/* This ensures the assembler supports explicit reloc. */
pcalau12i \$a0, %pc_hi20(x)
ld.w \$a0, \$a0, %pc_lo12(x)
syscall 0
.data
x:
.word 0
/* This should produce an R_LARCH_RELATIVE in the static PIE. */
.dword _start
EOF
LoongArch: Fix the condition to use PC-relative addressing in start.S A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
2022-10-02 14:23:09 +00:00
cat > conftest2.S << EOF
.global f
.type f, @function
f:
/* The linker should be able to handle this and produce a PLT entry. */
la.pcrel \$t0, \$t0, external_func
jirl \$zero, \$t0, 0
EOF
libc_cv_static_pie_on_loongarch=no
LoongArch: Fix the condition to use PC-relative addressing in start.S A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
2022-10-02 14:23:09 +00:00
if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S]) \
&& AC_TRY_COMMAND([LC_ALL=C $READELF -Wr conftest1 | grep -q R_LARCH_RELATIVE]) \
&& AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -shared -fPIC -o conftest2.so conftest2.S]) \
&& AC_TRY_COMMAND([LC_ALL=C $READELF -Wr conftest2.so | grep -q 'R_LARCH_JUMP_SLOT.*external_func'])
then
libc_cv_static_pie_on_loongarch=yes
fi
LoongArch: Fix the condition to use PC-relative addressing in start.S A start.o compiled from start.S with -DPIC and no -DSHARED is used by both crt1.o and rcrt1.o. So the LoongArch static PIE patch unintentionally introduced PC-relative addressing for main and __libc_start_main into crt1.o. While the latest Binutils (trunk, which will be released as 2.40) supports the PC-relative relocs against an external function by creating a PLT entry, the 2.39 release branch doesn't (and won't) support this. An error is raised: "PLT stub does not represent and symbol not defined." So, we need the following changes: 1. Check if ld supports the PC-relative relocs against an external function. If it's not supported, we deem static PIE unsupported. 2. Change start.S. If static PIE is supported, use PC-relative addressing for main and __libc_start_main and rely on the linker to create PLT entries. Otherwise, restore the old behavior (using GOT to address these functions). An alternative would be adding a new "static-pie-start.S", and some custom logic into Makefile to build rcrt1.o with it. And, restore start.S to the state before static PIE change so crt1.o won't contain PC-relative relocs against external symbols. But I can't see any benefit of this alternative, so I'd just keep it simple. Tested by building glibc with the following configurations: 1. Binutils trunk + GCC trunk. Static PIE enabled. All tests passed. 2. Binutils 2.39 branch + GCC trunk. Static PIE disabled. Tests related to ifunc failed (it's a known issue). All other tests passed. 3. Binutils 2.39 branch + GCC 12 branch, cross compilation with build-many-glibcs.py from x86_64-linux-gnu. Static PIE disabled. Build succeeded.
2022-10-02 14:23:09 +00:00
rm -rf conftest* ])
if test "$libc_cv_static_pie_on_loongarch" = yes; then
AC_DEFINE(SUPPORT_STATIC_PIE)
fi