From: Xi Ruoyao <xry111@xry111.site>
To: libc-alpha@sourceware.org
Cc: caiyinyu <caiyinyu@loongson.cn>,
Joseph Myers <joseph@codesourcery.com>,
Wang Xuerui <i@xen0n.name>, Xi Ruoyao <xry111@xry111.site>
Subject: [PATCH] LoongArch: Fix the condition to use PC-relative addressing in start.S
Date: Sun, 2 Oct 2022 22:23:09 +0800 [thread overview]
Message-ID: <20221002142309.900714-1-xry111@xry111.site> (raw)
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.
---
sysdeps/loongarch/configure | 29 +++++++++++++++++++++++++----
sysdeps/loongarch/configure.ac | 19 +++++++++++++++----
sysdeps/loongarch/start.S | 11 +++++++----
3 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/sysdeps/loongarch/configure b/sysdeps/loongarch/configure
index 6edd6d08a5..3046915ce2 100644
--- a/sysdeps/loongarch/configure
+++ b/sysdeps/loongarch/configure
@@ -10,7 +10,7 @@ if ${libc_cv_static_pie_on_loongarch+:} false; then :
$as_echo_n "(cached) " >&6
else
- cat > conftest.S << EOF
+ cat > conftest1.S << EOF
.global _start
.type _start, @function
_start:
@@ -26,14 +26,35 @@ x:
/* This should produce an R_LARCH_RELATIVE in the static PIE. */
.dword _start
EOF
+ 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
- if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest conftest.S'
+ 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
+ test $ac_status = 0; }; } \
+ && { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -shared -fPIC -o conftest2.so conftest2.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 conftest | grep -q R_LARCH_RELATIVE'
+ && { ac_try='LC_ALL=C $READELF -Wr conftest2.so | grep -q 'R_LARCH_JUMP_SLOT.*external_func''
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
@@ -42,7 +63,7 @@ EOF
then
libc_cv_static_pie_on_loongarch=yes
fi
- rm -rf conftest.*
+ rm -rf conftest*
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; }
diff --git a/sysdeps/loongarch/configure.ac b/sysdeps/loongarch/configure.ac
index a8a373bea3..06dd408ad9 100644
--- a/sysdeps/loongarch/configure.ac
+++ b/sysdeps/loongarch/configure.ac
@@ -13,7 +13,7 @@ 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, [
- cat > conftest.S << EOF
+ cat > conftest1.S << EOF
.global _start
.type _start, @function
_start:
@@ -29,13 +29,24 @@ x:
/* This should produce an R_LARCH_RELATIVE in the static PIE. */
.dword _start
EOF
+ 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
- if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest conftest.S]) \
- && AC_TRY_COMMAND([LC_ALL=C $READELF -Wr conftest | grep -q R_LARCH_RELATIVE])
+ 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
- rm -rf conftest.*])
+ rm -rf conftest* ])
if test "$libc_cv_static_pie_on_loongarch" = yes; then
AC_DEFINE(SUPPORT_STATIC_PIE)
diff --git a/sysdeps/loongarch/start.S b/sysdeps/loongarch/start.S
index 05cabd9b96..09e5a3c59c 100644
--- a/sysdeps/loongarch/start.S
+++ b/sysdeps/loongarch/start.S
@@ -60,13 +60,16 @@ ENTRY (ENTRY_POINT)
cfi_undefined (1)
or a5, a0, zero /* rtld_fini */
-#if defined(PIC) && !defined(SHARED)
+#if ENABLE_STATIC_PIE
/* For static PIE, the GOT cannot be used in _start because the GOT entries are
- offsets instead of real addresses before __libc_start_main. */
+ offsets instead of real addresses before __libc_start_main.
+ __libc_start_main and/or main may be not local, so we rely on the linker to
+ produce PLT entries for them. GNU ld >= 2.40 supports this. */
# define LA la.pcrel
#else
-/* We must get symbol main through GOT table, since main may not be local.
- For instance: googletest defines main in dynamic library. */
+/* Old GNU ld (< 2.40) cannot handle PC relative address against a non-local
+ function correctly. We deem these old linkers failing to support static PIE
+ and load the addresses from GOT. */
# define LA la.got
#endif
--
2.37.3
next reply other threads:[~2022-10-02 14:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 14:23 Xi Ruoyao [this message]
2022-10-07 9:54 ` Ping: " Xi Ruoyao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221002142309.900714-1-xry111@xry111.site \
--to=xry111@xry111.site \
--cc=caiyinyu@loongson.cn \
--cc=i@xen0n.name \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).