2022-07-19 09:22:07 +08:00
|
|
|
# This file is generated from configure.ac by Autoconf. DO NOT EDIT!
|
|
|
|
# Local configure fragment for sysdeps/loongarch/elf.
|
|
|
|
|
|
|
|
$as_echo "#define HIDDEN_VAR_NEEDS_DYNAMIC_RELOC 1" >>confdefs.h
|
|
|
|
|
2022-09-24 15:45:34 +08:00
|
|
|
|
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if the toolchain is sufficient to build static PIE on LoongArch" >&5
|
|
|
|
$as_echo_n "checking if the toolchain is sufficient to build static PIE on LoongArch... " >&6; }
|
|
|
|
if ${libc_cv_static_pie_on_loongarch+:} false; then :
|
|
|
|
$as_echo_n "(cached) " >&6
|
|
|
|
else
|
|
|
|
|
2023-07-06 17:25:43 +08:00
|
|
|
cat > conftest1.S <<\EOF
|
2022-09-24 15:45:34 +08:00
|
|
|
.global _start
|
|
|
|
.type _start, @function
|
|
|
|
_start:
|
2023-07-06 17:25:43 +08:00
|
|
|
li.w $a7, 93
|
2022-09-24 15:45:34 +08:00
|
|
|
/* This ensures the assembler supports explicit reloc. */
|
2023-07-06 17:25:43 +08:00
|
|
|
pcalau12i $a0, %pc_hi20(x)
|
|
|
|
ld.w $a0, $a0, %pc_lo12(x)
|
2022-09-24 15:45:34 +08:00
|
|
|
syscall 0
|
|
|
|
|
|
|
|
.data
|
|
|
|
x:
|
|
|
|
.word 0
|
|
|
|
/* This should produce an R_LARCH_RELATIVE in the static PIE. */
|
|
|
|
.dword _start
|
|
|
|
EOF
|
2023-07-06 17:25:43 +08:00
|
|
|
cat > conftest2.S <<\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 22:23:09 +08:00
|
|
|
.global f
|
|
|
|
.type f, @function
|
|
|
|
f:
|
|
|
|
/* The linker should be able to handle this and produce a PLT entry. */
|
2023-07-06 17:25:43 +08:00
|
|
|
la.pcrel $t0, $t0, external_func
|
|
|
|
jirl $zero, $t0, 0
|
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 22:23:09 +08:00
|
|
|
EOF
|
|
|
|
|
2022-09-24 15:45:34 +08:00
|
|
|
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 22:23:09 +08:00
|
|
|
if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S'
|
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
|
|
|
|
test $ac_status = 0; }; } \
|
|
|
|
&& { ac_try='LC_ALL=C $READELF -Wr conftest1 | grep -q R_LARCH_RELATIVE'
|
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
|
2023-02-27 19:08:09 +08:00
|
|
|
test $ac_status = 0; }; } \
|
|
|
|
&& ! { ac_try='LC_ALL=C $READELF -Wl conftest1 | grep -q INTERP'
|
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$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 22:23:09 +08:00
|
|
|
test $ac_status = 0; }; } \
|
|
|
|
&& { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -shared -fPIC -o conftest2.so conftest2.S'
|
2022-09-24 15:45:34 +08:00
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
|
|
|
|
test $ac_status = 0; }; } \
|
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 22:23:09 +08:00
|
|
|
&& { ac_try='LC_ALL=C $READELF -Wr conftest2.so | grep -q 'R_LARCH_JUMP_SLOT.*external_func''
|
2022-09-24 15:45:34 +08:00
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$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 22:23:09 +08:00
|
|
|
rm -rf conftest*
|
2022-09-24 15:45:34 +08:00
|
|
|
fi
|
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_static_pie_on_loongarch" >&5
|
|
|
|
$as_echo "$libc_cv_static_pie_on_loongarch" >&6; }
|
|
|
|
|
|
|
|
if test "$libc_cv_static_pie_on_loongarch" = yes; then
|
|
|
|
$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
|
|
|
|
|
|
|
|
fi
|
2022-09-07 10:33:00 +08:00
|
|
|
|
|
|
|
# Check if gcc supports option -mcmodel=medium.
|
2023-02-01 05:48:15 +08:00
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC supports option -mcmodel=medium" >&5
|
2022-09-07 10:33:00 +08:00
|
|
|
$as_echo_n "checking whether $CC supports option -mcmodel=medium... " >&6; }
|
|
|
|
if ${libc_cv_loongarch_cmodel_medium+:} false; then :
|
|
|
|
$as_echo_n "(cached) " >&6
|
|
|
|
else
|
2023-02-01 05:48:15 +08:00
|
|
|
|
|
|
|
if { ac_try='${CC-cc} -c $CFLAGS -mcmodel=medium /dev/null 1>&5'
|
2022-09-07 10:33:00 +08:00
|
|
|
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
|
|
|
|
(eval $ac_try) 2>&5
|
|
|
|
ac_status=$?
|
|
|
|
$as_echo "$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
|
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_loongarch_cmodel_medium" >&5
|
|
|
|
$as_echo "$libc_cv_loongarch_cmodel_medium" >&6; }
|
|
|
|
config_vars="$config_vars
|
|
|
|
have-cmodel-medium = $libc_cv_loongarch_cmodel_medium"
|
2023-07-06 16:30:52 +08:00
|
|
|
|
|
|
|
# Check if asm support vector instructions.
|
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for vector support in assembler" >&5
|
|
|
|
$as_echo_n "checking for vector support in assembler... " >&6; }
|
|
|
|
if ${libc_cv_loongarch_vec_asm+:} false; then :
|
|
|
|
$as_echo_n "(cached) " >&6
|
|
|
|
else
|
|
|
|
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=$?
|
|
|
|
$as_echo "$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
|
|
|
|
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_loongarch_vec_asm" >&5
|
|
|
|
$as_echo "$libc_cv_loongarch_vec_asm" >&6; }
|
|
|
|
if test $libc_cv_loongarch_vec_asm = yes; then
|
|
|
|
$as_echo "#define HAVE_LOONGARCH_VEC_ASM 1" >>confdefs.h
|
|
|
|
|
|
|
|
fi
|