glibc/sysdeps/loongarch/configure

113 lines
3.8 KiB
Plaintext
Raw Normal View History

2022-07-19 01:22:07 +00:00
# This file is generated from configure.ac by Autoconf. DO NOT EDIT!
# Local configure fragment for sysdeps/loongarch/elf.
printf "%s\n" "#define HIDDEN_VAR_NEEDS_DYNAMIC_RELOC 1" >>confdefs.h
2022-07-19 01:22:07 +00:00
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking if ${CC-cc} is sufficient to build static PIE on LoongArch" >&5
printf %s "checking if ${CC-cc} is sufficient to build static PIE on LoongArch... " >&6; }
if test ${libc_cv_static_pie_on_loongarch+y}
then :
printf %s "(cached) " >&6
else $as_nop
cat > conftest.S <<\EOF
.global _start
.type _start, @function
_start:
li.w $a7, 93
li.w $a0, 0
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
libc_cv_static_pie_on_loongarch=no
if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest conftest.S'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
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
test $ac_status = 0; }; } \
&& { ac_try='LC_ALL=C $READELF -Wr conftest | grep -q R_LARCH_RELATIVE'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; } \
&& ! { ac_try='LC_ALL=C $READELF -Wl conftest | grep -q INTERP'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; }
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*
fi
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_static_pie_on_loongarch" >&5
printf "%s\n" "$libc_cv_static_pie_on_loongarch" >&6; }
if test "$libc_cv_static_pie_on_loongarch" = yes; then
printf "%s\n" "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
fi
# Check if gcc supports option -mcmodel=medium.
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking whether $CC supports option -mcmodel=medium" >&5
printf %s "checking whether $CC supports option -mcmodel=medium... " >&6; }
if test ${libc_cv_loongarch_cmodel_medium+y}
then :
printf %s "(cached) " >&6
else $as_nop
if { ac_try='${CC-cc} -c $CFLAGS -mcmodel=medium /dev/null 1>&5'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; }; then
libc_cv_loongarch_cmodel_medium=yes
else
libc_cv_loongarch_cmodel_medium=no
fi
fi
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_loongarch_cmodel_medium" >&5
printf "%s\n" "$libc_cv_loongarch_cmodel_medium" >&6; }
config_vars="$config_vars
have-cmodel-medium = $libc_cv_loongarch_cmodel_medium"
# Check if asm support vector instructions.
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for vector support in assembler" >&5
printf %s "checking for vector support in assembler... " >&6; }
if test ${libc_cv_loongarch_vec_asm+y}
then :
printf %s "(cached) " >&6
else $as_nop
cat > conftest.s <<\EOF
vld $vr0, $sp, 0
EOF
if { ac_try='${CC-cc} -c $CFLAGS conftest.s -o conftest 1>&5'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; }; then
libc_cv_loongarch_vec_asm=yes
else
libc_cv_loongarch_vec_asm=no
fi
rm -f conftest*
fi
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_loongarch_vec_asm" >&5
printf "%s\n" "$libc_cv_loongarch_vec_asm" >&6; }
if test $libc_cv_loongarch_vec_asm = no; then
as_fn_error $? "binutils version is too old, use 2.41 or newer version" "$LINENO" 5
fi