* [PATCH 0/3] Make glibc build with LLD
@ 2020-12-28 19:48 Fangrui Song
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
` (4 more replies)
0 siblings, 5 replies; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 19:48 UTC (permalink / raw)
To: libc-alpha; +Cc: Fangrui Song
I sent the first two in April. Resending in a patch series to be
clearer.
install: Replace scripts/output-format.sed with objdump -f
replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
by leveraging objdump -f.
With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
`make` with ld pointing to ld.lld (LLVM linker) works.
Fangrui Song (3):
configure: Allow LD to be a linker other than GNU ld and gold
elf: Replace a --defsym trick with an object file to be compatible
with lld
install: Replace scripts/output-format.sed with objdump -f
Makerules | 13 ++-----
.../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
config.make.in | 1 -
configure | 32 +++++------------
configure.ac | 24 +++++--------
elf/Makefile | 11 +++---
scripts/output-format.sed | 35 -------------------
7 files changed, 23 insertions(+), 94 deletions(-)
delete mode 100644 scripts/output-format.sed
--
2.29.2.729.g45daf8777d-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
@ 2020-12-28 19:48 ` Fangrui Song
2020-12-28 20:46 ` H.J. Lu
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
` (3 subsequent siblings)
4 siblings, 1 reply; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 19:48 UTC (permalink / raw)
To: libc-alpha; +Cc: Fangrui Song
When using lld as the linker, configure prints a confusing message.
*** These critical programs are missing or too old: GNU ld
lld>=8 can build glibc with very few patches. lld may be built with a
custom version information (e.g. git commit ID), so a version check is not
useful at all.
---
configure | 13 ++++++++-----
configure.ac | 13 ++++++++-----
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/configure b/configure
index 6a35553805..6dcd2270f8 100755
--- a/configure
+++ b/configure
@@ -4601,9 +4601,10 @@ if test $ac_verc_fail = yes; then
fi
-if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
+case $($LD --version) in
+ "GNU gold"*)
# Accept gold 1.14 or higher
- for ac_prog in $LD
+ for ac_prog in $LD
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
@@ -4666,8 +4667,9 @@ if test $ac_verc_fail = yes; then
LD=: critic_missing="$critic_missing GNU gold"
fi
-else
- for ac_prog in $LD
+ ;;
+ "GNU ld"*)
+ for ac_prog in $LD
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
@@ -4730,7 +4732,8 @@ if test $ac_verc_fail = yes; then
LD=: critic_missing="$critic_missing GNU ld"
fi
-fi
+ ;;
+esac
# These programs are version sensitive.
diff --git a/configure.ac b/configure.ac
index 43cfac9d48..1a2054cd1a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -979,18 +979,21 @@ AC_CHECK_PROG_VER(AS, $AS, --version,
[2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
AS=: critic_missing="$critic_missing as")
-if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
+case $($LD --version) in
+ "GNU gold"*)
# Accept gold 1.14 or higher
- AC_CHECK_PROG_VER(LD, $LD, --version,
+ AC_CHECK_PROG_VER(LD, $LD, --version,
[GNU gold.* \([0-9][0-9]*\.[0-9.]*\)],
[1.1[4-9]*|1.[2-9][0-9]*|1.1[0-9][0-9]*|[2-9].*|[1-9][0-9]*],
LD=: critic_missing="$critic_missing GNU gold")
-else
- AC_CHECK_PROG_VER(LD, $LD, --version,
+ ;;
+ "GNU ld"*)
+ AC_CHECK_PROG_VER(LD, $LD, --version,
[GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
[2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
LD=: critic_missing="$critic_missing GNU ld")
-fi
+ ;;
+esac
# These programs are version sensitive.
AC_CHECK_TOOL_PREFIX
--
2.29.2.729.g45daf8777d-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
@ 2020-12-28 19:48 ` Fangrui Song
2021-01-11 20:06 ` Fāng-ruì Sòng
2021-01-19 0:03 ` H.J. Lu
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
` (2 subsequent siblings)
4 siblings, 2 replies; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 19:48 UTC (permalink / raw)
To: libc-alpha; +Cc: Fangrui Song
The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
fetched. This trick is used to avoid multiple definition errors which
would happen as a chain result:
dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
free fetches libc_pic.a(malloc.os)
libc_pic.a(malloc.os) has an undefined __libc_message
__libc_message fetches libc_pic.a(libc_fatal.os)
libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>> defined at dl-fxstatat64.c
>>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>> defined at libc_fatal.c
>>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
lld processes --defsym after all input files, so this trick does not
suppress multiple definition errors with lld. Split the step into two
and use an object file to make the intention more obvious and make lld
work.
This is conceptually more appropriate because --defsym defines a SHN_ABS
symbol while a normal definition is relative to the image base.
See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
for discussions about the --defsym semantics.
---
elf/Makefile | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/elf/Makefile b/elf/Makefile
index 0b4d78c874..299bf24b49 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
malloc \
realloc \
-# The GCC arguments that implement $(rtld-stubbed-symbols).
-rtld-stubbed-symbols-args = \
- $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
-
ifeq ($(have-ssp),yes)
# rtld is not built with the stack protector, so these references will
# go away in the rebuilds.
@@ -536,9 +532,10 @@ endif
$(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
@-rm -f $@T
- $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
- '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
- rm -f $@.o
+ echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
+ $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
+ $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
+ rm -f %@T.o $@.o
mv -f $@T $@
# For lld, skip preceding addresses and values before matching the archive and the member.
--
2.29.2.729.g45daf8777d-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
@ 2020-12-28 19:48 ` Fangrui Song
2021-01-08 19:38 ` Adhemerval Zanella
2021-01-12 11:32 ` Andreas Schwab
2020-12-28 21:11 ` [PATCH 0/3] Make glibc build with LLD H.J. Lu
2021-01-08 5:04 ` Fāng-ruì Sòng
4 siblings, 2 replies; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 19:48 UTC (permalink / raw)
To: libc-alpha; +Cc: Fangrui Song
GNU ld and gold have supported --print-output-format since 2011. glibc
requires binutils>=2.25 (2015), so if LD is GNU ld or gold, we can
assume the option is supported.
lld is by default a cross linker supporting multiple targets. It auto
detects the file format and does not need OUTPUT_FORMAT. It does not
support --print-output-format.
By parsing objdump -f, we can support all the three linkers.
---
Makerules | 13 ++-----
.../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
config.make.in | 1 -
configure | 19 ----------
configure.ac | 11 ------
scripts/output-format.sed | 35 -------------------
6 files changed, 3 insertions(+), 77 deletions(-)
delete mode 100644 scripts/output-format.sed
diff --git a/Makerules b/Makerules
index ef0fe67d9a..146d1ab650 100644
--- a/Makerules
+++ b/Makerules
@@ -1065,20 +1065,13 @@ install: $(inst_slibdir)/libc.so$(libc.so-version)
# for the configuration we are building. We put this statement into
# the linker scripts we install for -lc et al so that they will not be
# used by a link for a different format on a multi-architecture system.
-$(common-objpfx)format.lds: $(..)scripts/output-format.sed \
- $(common-objpfx)config.make \
+$(common-objpfx)format.lds: $(common-objpfx)config.make \
$(common-objpfx)config.h $(..)Makerules
-ifneq (unknown,$(output-format))
- echo > $@.new 'OUTPUT_FORMAT($(output-format))'
-else
$(LINK.o) -shared $(sysdep-LDFLAGS) $(rtld-LDFLAGS) \
$(LDFLAGS.so) $(LDFLAGS-lib.so) \
- -x c /dev/null -o $@.so -Wl,--verbose -v 2>/dev/null \
- | sed -n -f $< > $@.new
- test -s $@.new
+ -x c /dev/null -o $@.so 2>/dev/null
+ $(OBJDUMP) -f $@.so | sed -n 's/.*file format \(.*\)/OUTPUT_FORMAT(\1)/;T;p' > $@
rm -f $@.so
-endif
- mv -f $@.new $@
common-generated += format.lds
ifndef subdir
diff --git a/benchtests/strcoll-inputs/filelist#en_US.UTF-8 b/benchtests/strcoll-inputs/filelist#en_US.UTF-8
index 2f4ef195bb..43eb9efb40 100644
--- a/benchtests/strcoll-inputs/filelist#en_US.UTF-8
+++ b/benchtests/strcoll-inputs/filelist#en_US.UTF-8
@@ -9450,7 +9450,6 @@ move-if-change
check-execstack.awk
pylint
pylintrc
-output-format.sed
merge-test-results.sh
update-copyrights
config-uname.sh
diff --git a/config.make.in b/config.make.in
index 7ae27564fd..7f47f0caa4 100644
--- a/config.make.in
+++ b/config.make.in
@@ -73,7 +73,6 @@ fno-unit-at-a-time = @fno_unit_at_a_time@
bind-now = @bindnow@
have-hash-style = @libc_cv_hashstyle@
use-default-link = @use_default_link@
-output-format = @libc_cv_output_format@
have-cxx-thread_local = @libc_cv_cxx_thread_local@
have-loop-to-function = @libc_cv_cc_loop_to_function@
have-textrel_ifunc = @libc_cv_textrel_ifunc@
diff --git a/configure b/configure
index 6dcd2270f8..4b0ab150cb 100755
--- a/configure
+++ b/configure
@@ -623,7 +623,6 @@ libc_cv_cc_submachine
libc_cv_cc_nofma
libc_cv_mtls_dialect_gnu2
fno_unit_at_a_time
-libc_cv_output_format
libc_cv_has_glob_dat
libc_cv_hashstyle
libc_cv_fpie
@@ -6077,24 +6076,6 @@ fi
$as_echo "$libc_cv_has_glob_dat" >&6; }
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker output format" >&5
-$as_echo_n "checking linker output format... " >&6; }
-if ${libc_cv_output_format+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- if libc_cv_output_format=`
-${CC-cc} -nostartfiles -nostdlib $no_ssp -Wl,--print-output-format 2>&5`
-then
- :
-else
- libc_cv_output_format=
-fi
-test -n "$libc_cv_output_format" || libc_cv_output_format=unknown
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_output_format" >&5
-$as_echo "$libc_cv_output_format" >&6; }
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -fno-toplevel-reorder -fno-section-anchors" >&5
$as_echo_n "checking for -fno-toplevel-reorder -fno-section-anchors... " >&6; }
if ${libc_cv_fno_toplevel_reorder+:} false; then :
diff --git a/configure.ac b/configure.ac
index 1a2054cd1a..baf3a05ae7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1432,17 +1432,6 @@ fi
rm -f conftest*])
AC_SUBST(libc_cv_has_glob_dat)
-AC_CACHE_CHECK(linker output format, libc_cv_output_format, [dnl
-if libc_cv_output_format=`
-${CC-cc} -nostartfiles -nostdlib $no_ssp -Wl,--print-output-format 2>&AS_MESSAGE_LOG_FD`
-then
- :
-else
- libc_cv_output_format=
-fi
-test -n "$libc_cv_output_format" || libc_cv_output_format=unknown])
-AC_SUBST(libc_cv_output_format)
-
AC_CACHE_CHECK(for -fno-toplevel-reorder -fno-section-anchors, libc_cv_fno_toplevel_reorder, [dnl
cat > conftest.c <<EOF
int foo;
diff --git a/scripts/output-format.sed b/scripts/output-format.sed
deleted file mode 100644
index 364f52059f..0000000000
--- a/scripts/output-format.sed
+++ /dev/null
@@ -1,35 +0,0 @@
-/ld.*[ ]-E[BL]/b f
-/collect.*[ ]-E[BL]/b f
-/OUTPUT_FORMAT[^)]*$/{N
-s/\n[ ]*/ /
-}
-t o
-: o
-s/^.*OUTPUT_FORMAT(\([^,]*\), \1, \1).*$/OUTPUT_FORMAT(\1)/
-t q
-s/^.*OUTPUT_FORMAT(\([^,]*\), \([^,]*\), \([^,]*\)).*$/\1,\2,\3/
-t s
-s/^.*OUTPUT_FORMAT(\([^,)]*\).*$)/OUTPUT_FORMAT(\1)/
-t q
-d
-: s
-s/"//g
-G
-s/\n//
-s/^\([^,]*\),\([^,]*\),\([^,]*\),B/OUTPUT_FORMAT(\2)/p
-s/^\([^,]*\),\([^,]*\),\([^,]*\),L/OUTPUT_FORMAT(\3)/p
-s/^\([^,]*\),\([^,]*\),\([^,]*\)/OUTPUT_FORMAT(\1)/p
-/,/s|^|*** BUG in libc/scripts/output-format.sed *** |p
-q
-: q
-s/"//g
-p
-q
-: f
-s/^.*[ ]-E\([BL]\)[ ].*$/,\1/
-t h
-s/^.*[ ]-E\([BL]\)$/,\1/
-t h
-d
-: h
-h
--
2.29.2.729.g45daf8777d-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
@ 2020-12-28 20:46 ` H.J. Lu
2020-12-28 21:15 ` [PATCH 1/3] configure: Allow LD to be LLD 9.0.0 or above " Fangrui Song
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2020-12-28 20:46 UTC (permalink / raw)
To: Fangrui Song; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> When using lld as the linker, configure prints a confusing message.
>
> *** These critical programs are missing or too old: GNU ld
>
> lld>=8 can build glibc with very few patches. lld may be built with a
> custom version information (e.g. git commit ID), so a version check is not
> useful at all.
But not all versions of lld can be used to build glibc. Please find a way
to check the working lld version.
> ---
> configure | 13 ++++++++-----
> configure.ac | 13 ++++++++-----
> 2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/configure b/configure
> index 6a35553805..6dcd2270f8 100755
> --- a/configure
> +++ b/configure
> @@ -4601,9 +4601,10 @@ if test $ac_verc_fail = yes; then
> fi
>
>
> -if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
> +case $($LD --version) in
> + "GNU gold"*)
> # Accept gold 1.14 or higher
> - for ac_prog in $LD
> + for ac_prog in $LD
> do
> # Extract the first word of "$ac_prog", so it can be a program name with args.
> set dummy $ac_prog; ac_word=$2
> @@ -4666,8 +4667,9 @@ if test $ac_verc_fail = yes; then
> LD=: critic_missing="$critic_missing GNU gold"
> fi
>
> -else
> - for ac_prog in $LD
> + ;;
> + "GNU ld"*)
> + for ac_prog in $LD
> do
> # Extract the first word of "$ac_prog", so it can be a program name with args.
> set dummy $ac_prog; ac_word=$2
> @@ -4730,7 +4732,8 @@ if test $ac_verc_fail = yes; then
> LD=: critic_missing="$critic_missing GNU ld"
> fi
>
> -fi
> + ;;
> +esac
>
> # These programs are version sensitive.
>
> diff --git a/configure.ac b/configure.ac
> index 43cfac9d48..1a2054cd1a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -979,18 +979,21 @@ AC_CHECK_PROG_VER(AS, $AS, --version,
> [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> AS=: critic_missing="$critic_missing as")
>
> -if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
> +case $($LD --version) in
> + "GNU gold"*)
> # Accept gold 1.14 or higher
> - AC_CHECK_PROG_VER(LD, $LD, --version,
> + AC_CHECK_PROG_VER(LD, $LD, --version,
> [GNU gold.* \([0-9][0-9]*\.[0-9.]*\)],
> [1.1[4-9]*|1.[2-9][0-9]*|1.1[0-9][0-9]*|[2-9].*|[1-9][0-9]*],
> LD=: critic_missing="$critic_missing GNU gold")
> -else
> - AC_CHECK_PROG_VER(LD, $LD, --version,
> + ;;
> + "GNU ld"*)
> + AC_CHECK_PROG_VER(LD, $LD, --version,
> [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
> [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> LD=: critic_missing="$critic_missing GNU ld")
> -fi
> + ;;
> +esac
>
> # These programs are version sensitive.
> AC_CHECK_TOOL_PREFIX
> --
> 2.29.2.729.g45daf8777d-goog
>
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
` (2 preceding siblings ...)
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
@ 2020-12-28 21:11 ` H.J. Lu
2020-12-28 21:45 ` Fangrui Song
2021-01-08 5:04 ` Fāng-ruì Sòng
4 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2020-12-28 21:11 UTC (permalink / raw)
To: Fangrui Song; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> I sent the first two in April. Resending in a patch series to be
> clearer.
>
> install: Replace scripts/output-format.sed with objdump -f
>
> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> by leveraging objdump -f.
>
> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> `make` with ld pointing to ld.lld (LLVM linker) works.
I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
Fedora 33/x86-64,
"make check" generated:
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
Error 1
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
Error 1
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
Error 1
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
Error 1
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
Error 1
make[4]: *** [../Makerules:767:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
Error 1
make[4]: *** [../Rules:226:
/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
Error 1
make[3]: *** [Makefile:479: elf/tests] Error 2
with error messages, like
ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
has an STT_TLS symbol but doesn't have an SHF_TLS section
ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
has an STT_TLS symbol but doesn't have an SHF_TLS section
When glibc is configured with --enable-static-pie, I got
[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
Segmentation fault (core dumped)
[hjl@gnu-skx-1 build-x86_64-linux]$
You need to fix lld first and give the working lld a proper version so that
configure can check it.
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 1/3] configure: Allow LD to be LLD 9.0.0 or above and gold
2020-12-28 20:46 ` H.J. Lu
@ 2020-12-28 21:15 ` Fangrui Song
0 siblings, 0 replies; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 21:15 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On 2020-12-28, H.J. Lu wrote:
>On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
><libc-alpha@sourceware.org> wrote:
>>
>> When using lld as the linker, configure prints a confusing message.
>>
>> *** These critical programs are missing or too old: GNU ld
>>
>> lld>=8 can build glibc with very few patches. lld may be built with a
>> custom version information (e.g. git commit ID), so a version check is not
>> useful at all.
>
>But not all versions of lld can be used to build glibc. Please find a way
>to check the working lld version.
Replaced this with "configure: Allow LD to be LLD 9.0.0 or above" in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld
8.0.0 needs an additional workaround. Since 9.0.0 is quite common in
distributions, I just set the baseline to 9.0.0 to reduce friction.
[-- Attachment #2: 0001-configure-Allow-LD-to-be-LLD-9.0.0-or-above.patch --]
[-- Type: text/x-diff, Size: 4848 bytes --]
From 49c46455e41f1e0e396b17425eb93c5e0e776e1b Mon Sep 17 00:00:00 2001
From: Fangrui Song <maskray@google.com>
Date: Fri, 13 Mar 2020 13:29:46 -0700
Subject: [PATCH 1/3] configure: Allow LD to be LLD 9.0.0 or above
When using LLD (LLVM linker) as the linker, configure prints a confusing
message.
*** These critical programs are missing or too old: GNU ld
LLD>=9.0.0 can build glibc with very few patches. (LLD 8.0.0 needs one
workaround for -Wl,-defsym=_begin=0). LLD>=9.0.0 is available on many
distributions, so just set the baseline version to 9.0.0.
---
configure | 77 +++++++++++++++++++++++++++++++++++++++++++++++++---
configure.ac | 20 ++++++++++----
2 files changed, 88 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index 6a35553805..f67eb287fc 100755
--- a/configure
+++ b/configure
@@ -4601,9 +4601,10 @@ if test $ac_verc_fail = yes; then
fi
-if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
+case $($LD --version) in
+ "GNU gold"*)
# Accept gold 1.14 or higher
- for ac_prog in $LD
+ for ac_prog in $LD
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
@@ -4666,8 +4667,75 @@ if test $ac_verc_fail = yes; then
LD=: critic_missing="$critic_missing GNU gold"
fi
+ ;;
+ "LLD"*)
+ # Accept LLD 9.0 or higher
+ for ac_prog in $LD
+do
+ # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_LD+:} false; then :
+ $as_echo_n "(cached) " >&6
else
- for ac_prog in $LD
+ if test -n "$LD"; then
+ ac_cv_prog_LD="$LD" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+ IFS=$as_save_IFS
+ test -z "$as_dir" && as_dir=.
+ for ac_exec_ext in '' $ac_executable_extensions; do
+ if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ ac_cv_prog_LD="$ac_prog"
+ $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
+ break 2
+ fi
+done
+ done
+IFS=$as_save_IFS
+
+fi
+fi
+LD=$ac_cv_prog_LD
+if test -n "$LD"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $LD" >&5
+$as_echo "$LD" >&6; }
+else
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+ test -n "$LD" && break
+done
+
+if test -z "$LD"; then
+ ac_verc_fail=yes
+else
+ # Found it, now check the version.
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking version of $LD" >&5
+$as_echo_n "checking version of $LD... " >&6; }
+ ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*LLD.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p'`
+ case $ac_prog_version in
+ '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
+ 9.*|[1-9][0-9].*)
+ ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
+ *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
+
+ esac
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_prog_version" >&5
+$as_echo "$ac_prog_version" >&6; }
+fi
+if test $ac_verc_fail = yes; then
+ LD=: critic_missing="$critic_missing LLD"
+fi
+
+ ;;
+ *)
+ for ac_prog in $LD
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
@@ -4730,7 +4798,8 @@ if test $ac_verc_fail = yes; then
LD=: critic_missing="$critic_missing GNU ld"
fi
-fi
+ ;;
+esac
# These programs are version sensitive.
diff --git a/configure.ac b/configure.ac
index 43cfac9d48..59dbf9bda8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -979,18 +979,28 @@ AC_CHECK_PROG_VER(AS, $AS, --version,
[2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
AS=: critic_missing="$critic_missing as")
-if test -n "`$LD --version | sed -n 's/^GNU \(gold\).*$/\1/p'`"; then
+case $($LD --version) in
+ "GNU gold"*)
# Accept gold 1.14 or higher
- AC_CHECK_PROG_VER(LD, $LD, --version,
+ AC_CHECK_PROG_VER(LD, $LD, --version,
[GNU gold.* \([0-9][0-9]*\.[0-9.]*\)],
[1.1[4-9]*|1.[2-9][0-9]*|1.1[0-9][0-9]*|[2-9].*|[1-9][0-9]*],
LD=: critic_missing="$critic_missing GNU gold")
-else
- AC_CHECK_PROG_VER(LD, $LD, --version,
+ ;;
+ "LLD"*)
+ # Accept LLD 9.0 or higher
+ AC_CHECK_PROG_VER(LD, $LD, --version,
+ [LLD.* \([0-9][0-9]*\.[0-9.]*\)],
+ [9.*|[1-9][0-9].*],
+ LD=: critic_missing="$critic_missing LLD")
+ ;;
+ *)
+ AC_CHECK_PROG_VER(LD, $LD, --version,
[GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
[2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
LD=: critic_missing="$critic_missing GNU ld")
-fi
+ ;;
+esac
# These programs are version sensitive.
AC_CHECK_TOOL_PREFIX
--
2.29.2.729.g45daf8777d-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 21:11 ` [PATCH 0/3] Make glibc build with LLD H.J. Lu
@ 2020-12-28 21:45 ` Fangrui Song
2020-12-28 21:49 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fangrui Song @ 2020-12-28 21:45 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On 2020-12-28, H.J. Lu wrote:
>On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
><libc-alpha@sourceware.org> wrote:
>>
>> I sent the first two in April. Resending in a patch series to be
>> clearer.
>>
>> install: Replace scripts/output-format.sed with objdump -f
>>
>> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
>> by leveraging objdump -f.
>>
>> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
>> `make` with ld pointing to ld.lld (LLVM linker) works.
>
>I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
>Fedora 33/x86-64,
>"make check" generated:
>
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
>Error 1
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
>Error 1
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
>Error 1
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
>Error 1
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
>Error 1
>make[4]: *** [../Makerules:767:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
>Error 1
>make[4]: *** [../Rules:226:
>/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
>Error 1
>make[3]: *** [Makefile:479: elf/tests] Error 2
>
>with error messages, like
>
>ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
>has an STT_TLS symbol but doesn't have an SHF_TLS section
>ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
>has an STT_TLS symbol but doesn't have an SHF_TLS section
tst-tls* tests appear to be similar to .tls_common which looks very
obsoleted and not supported by Clang. I don't think ifuncmain* or
tst-audit* matters for typical usage (most users) but I can take a look.
>When glibc is configured with --enable-static-pie, I got
>
>[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
>Segmentation fault (core dumped)
>[hjl@gnu-skx-1 build-x86_64-linux]$
>
>You need to fix lld first and give the working lld a proper version so that
>configure can check it.
I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
in google/grte/v5-2.27/master, which has fixed the issue.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 21:45 ` Fangrui Song
@ 2020-12-28 21:49 ` H.J. Lu
2020-12-28 22:54 ` H.J. Lu
2021-01-05 22:57 ` Fāng-ruì Sòng
0 siblings, 2 replies; 42+ messages in thread
From: H.J. Lu @ 2020-12-28 21:49 UTC (permalink / raw)
To: Fangrui Song; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
>
> On 2020-12-28, H.J. Lu wrote:
> >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> ><libc-alpha@sourceware.org> wrote:
> >>
> >> I sent the first two in April. Resending in a patch series to be
> >> clearer.
> >>
> >> install: Replace scripts/output-format.sed with objdump -f
> >>
> >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> >> by leveraging objdump -f.
> >>
> >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> >> `make` with ld pointing to ld.lld (LLVM linker) works.
> >
> >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> >Fedora 33/x86-64,
> >"make check" generated:
> >
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> >Error 1
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> >Error 1
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> >Error 1
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> >Error 1
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> >Error 1
> >make[4]: *** [../Makerules:767:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> >Error 1
> >make[4]: *** [../Rules:226:
> >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> >Error 1
> >make[3]: *** [Makefile:479: elf/tests] Error 2
> >
> >with error messages, like
> >
> >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> >has an STT_TLS symbol but doesn't have an SHF_TLS section
> >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> >has an STT_TLS symbol but doesn't have an SHF_TLS section
>
> tst-tls* tests appear to be similar to .tls_common which looks very
> obsoleted and not supported by Clang. I don't think ifuncmain* or
> tst-audit* matters for typical usage (most users) but I can take a look.
"make check" should be clean on Fedora 33/x86-64.
> >When glibc is configured with --enable-static-pie, I got
> >
> >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> >Segmentation fault (core dumped)
> >[hjl@gnu-skx-1 build-x86_64-linux]$
> >
> >You need to fix lld first and give the working lld a proper version so that
> >configure can check it.
>
> I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> in google/grte/v5-2.27/master, which has fixed the issue.
Why isn't it needed for ld?
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 21:49 ` H.J. Lu
@ 2020-12-28 22:54 ` H.J. Lu
2021-01-05 23:03 ` Fāng-ruì Sòng
2021-01-05 22:57 ` Fāng-ruì Sòng
1 sibling, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2020-12-28 22:54 UTC (permalink / raw)
To: Fangrui Song; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> >
> > On 2020-12-28, H.J. Lu wrote:
> > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > ><libc-alpha@sourceware.org> wrote:
> > >>
> > >> I sent the first two in April. Resending in a patch series to be
> > >> clearer.
> > >>
> > >> install: Replace scripts/output-format.sed with objdump -f
> > >>
> > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > >> by leveraging objdump -f.
> > >>
> > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > >
> > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > >Fedora 33/x86-64,
> > >"make check" generated:
> > >
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > >Error 1
> > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > >
> > >with error messages, like
> > >
> > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> >
> > tst-tls* tests appear to be similar to .tls_common which looks very
> > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > tst-audit* matters for typical usage (most users) but I can take a look.
>
> "make check" should be clean on Fedora 33/x86-64.
Because this lld error, "make check" didn't report test summary:
Summary of test results:
4322 PASS
8 UNSUPPORTED
13 XFAIL
6 XPASS
> > >When glibc is configured with --enable-static-pie, I got
> > >
> > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > >Segmentation fault (core dumped)
> > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > >
> > >You need to fix lld first and give the working lld a proper version so that
> > >configure can check it.
> >
> > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > in google/grte/v5-2.27/master, which has fixed the issue.
>
> Why isn't it needed for ld?
>
Also re-order your patches to place the enabling lld patch the last so that any
commits can build a working glibc.
Thanks.
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 21:49 ` H.J. Lu
2020-12-28 22:54 ` H.J. Lu
@ 2021-01-05 22:57 ` Fāng-ruì Sòng
1 sibling, 0 replies; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-05 22:57 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 1:50 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> >
> > On 2020-12-28, H.J. Lu wrote:
> > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > ><libc-alpha@sourceware.org> wrote:
> > >>
> > >> I sent the first two in April. Resending in a patch series to be
> > >> clearer.
> > >>
> > >> install: Replace scripts/output-format.sed with objdump -f
> > >>
> > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > >> by leveraging objdump -f.
> > >>
> > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > >
> > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > >Fedora 33/x86-64,
> > >"make check" generated:
> > >
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > >Error 1
> > >make[4]: *** [../Makerules:767:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > >Error 1
> > >make[4]: *** [../Rules:226:
> > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > >Error 1
> > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > >
> > >with error messages, like
> > >
> > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> >
> > tst-tls* tests appear to be similar to .tls_common which looks very
> > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > tst-audit* matters for typical usage (most users) but I can take a look.
>
> "make check" should be clean on Fedora 33/x86-64.
>
> > >When glibc is configured with --enable-static-pie, I got
> > >
> > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > >Segmentation fault (core dumped)
> > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > >
> > >You need to fix lld first and give the working lld a proper version so that
> > >configure can check it.
> >
> > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > in google/grte/v5-2.27/master, which has fixed the issue.
>
> Why isn't it needed for ld?
>
> --
> H.J.
"Make _dl_relocate_static_pie return an int indicating whether it
applied relocs." makes glibc build with both GNU ld and LLD.
Without the commit, elf/ldconfig segfaults with LLD but works with GNU
ld because the code relies on the undefined weak
__rela_iplt_start/__rela_iplt_end to be null.
% ld.bfd --verbose | grep rela_iplt_start
PROVIDE_HIDDEN (__rela_iplt_start = .);
% ld.bfd -pie --verbose | grep rela_iplt_start
% ld.bfd -shared --verbose | grep rela_iplt_start
I don't think this justifies a different behavior in ld.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 22:54 ` H.J. Lu
@ 2021-01-05 23:03 ` Fāng-ruì Sòng
2021-01-05 23:33 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-05 23:03 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > > On 2020-12-28, H.J. Lu wrote:
> > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > ><libc-alpha@sourceware.org> wrote:
> > > >>
> > > >> I sent the first two in April. Resending in a patch series to be
> > > >> clearer.
> > > >>
> > > >> install: Replace scripts/output-format.sed with objdump -f
> > > >>
> > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > >> by leveraging objdump -f.
> > > >>
> > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > >
> > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > >Fedora 33/x86-64,
> > > >"make check" generated:
> > > >
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > >Error 1
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > >Error 1
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > >Error 1
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > >Error 1
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > >Error 1
> > > >make[4]: *** [../Makerules:767:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > >Error 1
> > > >make[4]: *** [../Rules:226:
> > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > >Error 1
> > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > >
> > > >with error messages, like
> > > >
> > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > >
> > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > tst-audit* matters for typical usage (most users) but I can take a look.
> >
> > "make check" should be clean on Fedora 33/x86-64.
>
> Because this lld error, "make check" didn't report test summary:
>
> Summary of test results:
> 4322 PASS
> 8 UNSUPPORTED
> 13 XFAIL
> 6 XPASS
>
> > > >When glibc is configured with --enable-static-pie, I got
> > > >
> > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > >Segmentation fault (core dumped)
> > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > >
> > > >You need to fix lld first and give the working lld a proper version so that
> > > >configure can check it.
> > >
> > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > in google/grte/v5-2.27/master, which has fixed the issue.
> >
> > Why isn't it needed for ld?
> >
>
> Also re-order your patches to place the enabling lld patch the last so that any
> commits can build a working glibc.
>
> Thanks.
>
> --
> H.J.
Without "configure: Allow LD to be LLD 9.0.0 or above", configure
rejects LLD at configure time and the other commits cannot be tested
at all...
The other commits are general improvement and useful on their own, and
they are independent and can be merged separately.
As I mentioned in the other reply, LLD does not want to special case
the definition of __rela_iplt_start depending on -no-pie (available in
gold and LLD, not available in GNU ld yet) ; -pie/-shared...
The TLS common issues are obsoleted features that do not make sense nowadays.
Any case, the LLD produced executables are functional.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-05 23:03 ` Fāng-ruì Sòng
@ 2021-01-05 23:33 ` H.J. Lu
2021-01-05 23:41 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-05 23:33 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > >
> > > > On 2020-12-28, H.J. Lu wrote:
> > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > ><libc-alpha@sourceware.org> wrote:
> > > > >>
> > > > >> I sent the first two in April. Resending in a patch series to be
> > > > >> clearer.
> > > > >>
> > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > >>
> > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > >> by leveraging objdump -f.
> > > > >>
> > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > >
> > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > >Fedora 33/x86-64,
> > > > >"make check" generated:
> > > > >
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > >Error 1
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > >Error 1
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > >Error 1
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > >Error 1
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > >Error 1
> > > > >make[4]: *** [../Makerules:767:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > >Error 1
> > > > >make[4]: *** [../Rules:226:
> > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > >Error 1
> > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > >
> > > > >with error messages, like
> > > > >
> > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > >
> > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > >
> > > "make check" should be clean on Fedora 33/x86-64.
> >
> > Because this lld error, "make check" didn't report test summary:
> >
> > Summary of test results:
> > 4322 PASS
> > 8 UNSUPPORTED
> > 13 XFAIL
> > 6 XPASS
> >
> > > > >When glibc is configured with --enable-static-pie, I got
> > > > >
> > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > >Segmentation fault (core dumped)
> > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > >
> > > > >You need to fix lld first and give the working lld a proper version so that
> > > > >configure can check it.
> > > >
> > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > >
> > > Why isn't it needed for ld?
> > >
> >
> > Also re-order your patches to place the enabling lld patch the last so that any
> > commits can build a working glibc.
> >
> > Thanks.
> >
> > --
> > H.J.
>
> Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> rejects LLD at configure time and the other commits cannot be tested
> at all...
>
> The other commits are general improvement and useful on their own, and
> they are independent and can be merged separately.
>
> As I mentioned in the other reply, LLD does not want to special case
> the definition of __rela_iplt_start depending on -no-pie (available in
> gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> The TLS common issues are obsoleted features that do not make sense nowadays.
> Any case, the LLD produced executables are functional.
The code in question is
static void
apply_irel (void)
{
# ifdef IREL
/* We use weak references for these so that we'll still work with a linker
that doesn't define them. Such a linker doesn't support IFUNC at all
and so uses won't work, but a statically-linked program that doesn't
use any IFUNC symbols won't have a problem. */
extern const IREL_T IPLT_START[] __attribute__ ((weak));
extern const IREL_T IPLT_END[] __attribute__ ((weak));
for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
IREL (ipltent);
# endif
}
Since IPLT_START and IPLT_END are undefined, linker should set
them to zero and the loop should be skipped. Why doesn't LLD do
that?
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-05 23:33 ` H.J. Lu
@ 2021-01-05 23:41 ` Fāng-ruì Sòng
2021-01-05 23:51 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-05 23:41 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > >
> > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > >>
> > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > >> clearer.
> > > > > >>
> > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > >>
> > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > >> by leveraging objdump -f.
> > > > > >>
> > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > >
> > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > >Fedora 33/x86-64,
> > > > > >"make check" generated:
> > > > > >
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Makerules:767:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > >Error 1
> > > > > >make[4]: *** [../Rules:226:
> > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > >Error 1
> > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > >
> > > > > >with error messages, like
> > > > > >
> > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > >
> > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > >
> > > > "make check" should be clean on Fedora 33/x86-64.
> > >
> > > Because this lld error, "make check" didn't report test summary:
> > >
> > > Summary of test results:
> > > 4322 PASS
> > > 8 UNSUPPORTED
> > > 13 XFAIL
> > > 6 XPASS
> > >
> > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > >
> > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > >Segmentation fault (core dumped)
> > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > >
> > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > >configure can check it.
> > > > >
> > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > >
> > > > Why isn't it needed for ld?
> > > >
> > >
> > > Also re-order your patches to place the enabling lld patch the last so that any
> > > commits can build a working glibc.
> > >
> > > Thanks.
> > >
> > > --
> > > H.J.
> >
> > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > rejects LLD at configure time and the other commits cannot be tested
> > at all...
> >
> > The other commits are general improvement and useful on their own, and
> > they are independent and can be merged separately.
> >
> > As I mentioned in the other reply, LLD does not want to special case
> > the definition of __rela_iplt_start depending on -no-pie (available in
> > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > The TLS common issues are obsoleted features that do not make sense nowadays.
> > Any case, the LLD produced executables are functional.
>
> The code in question is
>
> static void
> apply_irel (void)
> {
> # ifdef IREL
> /* We use weak references for these so that we'll still work with a linker
> that doesn't define them. Such a linker doesn't support IFUNC at all
> and so uses won't work, but a statically-linked program that doesn't
> use any IFUNC symbols won't have a problem. */
> extern const IREL_T IPLT_START[] __attribute__ ((weak));
> extern const IREL_T IPLT_END[] __attribute__ ((weak));
> for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> IREL (ipltent);
> # endif
> }
>
> Since IPLT_START and IPLT_END are undefined, linker should set
> them to zero and the loop should be skipped. Why doesn't LLD do
> that?
>
>
> --
> H.J.
LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
exists and is not defined (2) not -r (3) no .interp
LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
behavior makes sense to me.
GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-05 23:41 ` Fāng-ruì Sòng
@ 2021-01-05 23:51 ` H.J. Lu
2021-01-06 0:50 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-05 23:51 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > > >
> > > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > > >>
> > > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > > >> clearer.
> > > > > > >>
> > > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > > >>
> > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > > >> by leveraging objdump -f.
> > > > > > >>
> > > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > > >
> > > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > > >Fedora 33/x86-64,
> > > > > > >"make check" generated:
> > > > > > >
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Makerules:767:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > > >Error 1
> > > > > > >make[4]: *** [../Rules:226:
> > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > > >Error 1
> > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > > >
> > > > > > >with error messages, like
> > > > > > >
> > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > >
> > > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > > >
> > > > > "make check" should be clean on Fedora 33/x86-64.
> > > >
> > > > Because this lld error, "make check" didn't report test summary:
> > > >
> > > > Summary of test results:
> > > > 4322 PASS
> > > > 8 UNSUPPORTED
> > > > 13 XFAIL
> > > > 6 XPASS
> > > >
> > > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > > >
> > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > > >Segmentation fault (core dumped)
> > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > > >
> > > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > > >configure can check it.
> > > > > >
> > > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > > >
> > > > > Why isn't it needed for ld?
> > > > >
> > > >
> > > > Also re-order your patches to place the enabling lld patch the last so that any
> > > > commits can build a working glibc.
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > H.J.
> > >
> > > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > > rejects LLD at configure time and the other commits cannot be tested
> > > at all...
> > >
> > > The other commits are general improvement and useful on their own, and
> > > they are independent and can be merged separately.
> > >
> > > As I mentioned in the other reply, LLD does not want to special case
> > > the definition of __rela_iplt_start depending on -no-pie (available in
> > > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > > The TLS common issues are obsoleted features that do not make sense nowadays.
> > > Any case, the LLD produced executables are functional.
> >
> > The code in question is
> >
> > static void
> > apply_irel (void)
> > {
> > # ifdef IREL
> > /* We use weak references for these so that we'll still work with a linker
> > that doesn't define them. Such a linker doesn't support IFUNC at all
> > and so uses won't work, but a statically-linked program that doesn't
> > use any IFUNC symbols won't have a problem. */
> > extern const IREL_T IPLT_START[] __attribute__ ((weak));
> > extern const IREL_T IPLT_END[] __attribute__ ((weak));
> > for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> > IREL (ipltent);
> > # endif
> > }
> >
> > Since IPLT_START and IPLT_END are undefined, linker should set
> > them to zero and the loop should be skipped. Why doesn't LLD do
> > that?
> >
> >
> > --
> > H.J.
>
> LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
> exists and is not defined (2) not -r (3) no .interp
>
> LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
> behavior makes sense to me.
> GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
It is an lld bug:
https://bugs.llvm.org/show_bug.cgi?id=48674
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-05 23:51 ` H.J. Lu
@ 2021-01-06 0:50 ` Fāng-ruì Sòng
2021-01-06 1:43 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-06 0:50 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >
> > > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > > > >
> > > > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > > > >>
> > > > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > > > >> clearer.
> > > > > > > >>
> > > > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > > > >>
> > > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > > > >> by leveraging objdump -f.
> > > > > > > >>
> > > > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > > > >
> > > > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > > > >Fedora 33/x86-64,
> > > > > > > >"make check" generated:
> > > > > > > >
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > > > >Error 1
> > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > > > >Error 1
> > > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > > > >
> > > > > > > >with error messages, like
> > > > > > > >
> > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > >
> > > > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > > > >
> > > > > > "make check" should be clean on Fedora 33/x86-64.
> > > > >
> > > > > Because this lld error, "make check" didn't report test summary:
> > > > >
> > > > > Summary of test results:
> > > > > 4322 PASS
> > > > > 8 UNSUPPORTED
> > > > > 13 XFAIL
> > > > > 6 XPASS
> > > > >
> > > > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > > > >
> > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > > > >Segmentation fault (core dumped)
> > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > > > >
> > > > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > > > >configure can check it.
> > > > > > >
> > > > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > > > >
> > > > > > Why isn't it needed for ld?
> > > > > >
> > > > >
> > > > > Also re-order your patches to place the enabling lld patch the last so that any
> > > > > commits can build a working glibc.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > --
> > > > > H.J.
> > > >
> > > > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > > > rejects LLD at configure time and the other commits cannot be tested
> > > > at all...
> > > >
> > > > The other commits are general improvement and useful on their own, and
> > > > they are independent and can be merged separately.
> > > >
> > > > As I mentioned in the other reply, LLD does not want to special case
> > > > the definition of __rela_iplt_start depending on -no-pie (available in
> > > > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > > > The TLS common issues are obsoleted features that do not make sense nowadays.
> > > > Any case, the LLD produced executables are functional.
> > >
> > > The code in question is
> > >
> > > static void
> > > apply_irel (void)
> > > {
> > > # ifdef IREL
> > > /* We use weak references for these so that we'll still work with a linker
> > > that doesn't define them. Such a linker doesn't support IFUNC at all
> > > and so uses won't work, but a statically-linked program that doesn't
> > > use any IFUNC symbols won't have a problem. */
> > > extern const IREL_T IPLT_START[] __attribute__ ((weak));
> > > extern const IREL_T IPLT_END[] __attribute__ ((weak));
> > > for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> > > IREL (ipltent);
> > > # endif
> > > }
> > >
> > > Since IPLT_START and IPLT_END are undefined, linker should set
> > > them to zero and the loop should be skipped. Why doesn't LLD do
> > > that?
> > >
> > >
> > > --
> > > H.J.
> >
> > LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
> > exists and is not defined (2) not -r (3) no .interp
> >
> > LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
> > behavior makes sense to me.
> > GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
>
> It is an lld bug:
>
> https://bugs.llvm.org/show_bug.cgi?id=48674
>
> --
> H.J.
I don't consider https://bugs.llvm.org/show_bug.cgi?id=48674 an LLD
bug, so we have disagreement.
__rela_iplt_start/__rela_iplt_end is a contract between the link
editor and the dynamic loader/libc. For the perspective of a good
design, I don't think it is necessary making
"whether to define __rela_iplt_start" different for ld -no-pie (GNU ld
does not have -no-pie currently, but gold and LLD do) and ld -pie.
rtld/libc can just figure out whether it is -static-pie (since a
different crt1 rcrt1.o is used) and don't reference __rela_iplt_start
in that case.
If this difference is dropped (by taking the glibc patch "Make
_dl_relocate_static_pie return an int indicating whether it applied
relocs."),
diff -u =(ld.bfd --verbose) =(ld.bfd -pie --verbose) can have no
difference other than the start address: __executable_start.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-06 0:50 ` Fāng-ruì Sòng
@ 2021-01-06 1:43 ` H.J. Lu
2021-01-06 2:00 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-06 1:43 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 4:51 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > >
> > > > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > > > > >
> > > > > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > > > > >>
> > > > > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > > > > >> clearer.
> > > > > > > > >>
> > > > > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > > > > >>
> > > > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > > > > >> by leveraging objdump -f.
> > > > > > > > >>
> > > > > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > > > > >
> > > > > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > > > > >Fedora 33/x86-64,
> > > > > > > > >"make check" generated:
> > > > > > > > >
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > > > > >Error 1
> > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > > > > >Error 1
> > > > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > > > > >
> > > > > > > > >with error messages, like
> > > > > > > > >
> > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > >
> > > > > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > > > > >
> > > > > > > "make check" should be clean on Fedora 33/x86-64.
> > > > > >
> > > > > > Because this lld error, "make check" didn't report test summary:
> > > > > >
> > > > > > Summary of test results:
> > > > > > 4322 PASS
> > > > > > 8 UNSUPPORTED
> > > > > > 13 XFAIL
> > > > > > 6 XPASS
> > > > > >
> > > > > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > > > > >
> > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > > > > >Segmentation fault (core dumped)
> > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > > > > >
> > > > > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > > > > >configure can check it.
> > > > > > > >
> > > > > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > > > > >
> > > > > > > Why isn't it needed for ld?
> > > > > > >
> > > > > >
> > > > > > Also re-order your patches to place the enabling lld patch the last so that any
> > > > > > commits can build a working glibc.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > --
> > > > > > H.J.
> > > > >
> > > > > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > > > > rejects LLD at configure time and the other commits cannot be tested
> > > > > at all...
> > > > >
> > > > > The other commits are general improvement and useful on their own, and
> > > > > they are independent and can be merged separately.
> > > > >
> > > > > As I mentioned in the other reply, LLD does not want to special case
> > > > > the definition of __rela_iplt_start depending on -no-pie (available in
> > > > > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > > > > The TLS common issues are obsoleted features that do not make sense nowadays.
> > > > > Any case, the LLD produced executables are functional.
> > > >
> > > > The code in question is
> > > >
> > > > static void
> > > > apply_irel (void)
> > > > {
> > > > # ifdef IREL
> > > > /* We use weak references for these so that we'll still work with a linker
> > > > that doesn't define them. Such a linker doesn't support IFUNC at all
> > > > and so uses won't work, but a statically-linked program that doesn't
> > > > use any IFUNC symbols won't have a problem. */
> > > > extern const IREL_T IPLT_START[] __attribute__ ((weak));
> > > > extern const IREL_T IPLT_END[] __attribute__ ((weak));
> > > > for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> > > > IREL (ipltent);
> > > > # endif
> > > > }
> > > >
> > > > Since IPLT_START and IPLT_END are undefined, linker should set
> > > > them to zero and the loop should be skipped. Why doesn't LLD do
> > > > that?
> > > >
> > > >
> > > > --
> > > > H.J.
> > >
> > > LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
> > > exists and is not defined (2) not -r (3) no .interp
> > >
> > > LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
> > > behavior makes sense to me.
> > > GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
> >
> > It is an lld bug:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=48674
> >
> > --
> > H.J.
>
> I don't consider https://bugs.llvm.org/show_bug.cgi?id=48674 an LLD
> bug, so we have disagreement.
>
> __rela_iplt_start/__rela_iplt_end is a contract between the link
> editor and the dynamic loader/libc. For the perspective of a good
> design, I don't think it is necessary making
> "whether to define __rela_iplt_start" different for ld -no-pie (GNU ld
> does not have -no-pie currently, but gold and LLD do) and ld -pie.
>
> rtld/libc can just figure out whether it is -static-pie (since a
> different crt1 rcrt1.o is used) and don't reference __rela_iplt_start
> in that case.
>
> If this difference is dropped (by taking the glibc patch "Make
> _dl_relocate_static_pie return an int indicating whether it applied
> relocs."),
> diff -u =(ld.bfd --verbose) =(ld.bfd -pie --verbose) can have no
> difference other than the start address: __executable_start.
I designed and implemented the whole thing in ld and glibc
many years ago. I don't think they should be changed. lld
should follow my design.
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-06 1:43 ` H.J. Lu
@ 2021-01-06 2:00 ` Fāng-ruì Sòng
2021-01-06 2:14 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-06 2:00 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 5:44 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 5, 2021 at 4:51 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >
> > > > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > > >
> > > > > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > > > > > >
> > > > > > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > > > > > >>
> > > > > > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > > > > > >> clearer.
> > > > > > > > > >>
> > > > > > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > > > > > >>
> > > > > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > > > > > >> by leveraging objdump -f.
> > > > > > > > > >>
> > > > > > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > > > > > >
> > > > > > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > > > > > >Fedora 33/x86-64,
> > > > > > > > > >"make check" generated:
> > > > > > > > > >
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > > > > > >Error 1
> > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > > > > > >Error 1
> > > > > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > > > > > >
> > > > > > > > > >with error messages, like
> > > > > > > > > >
> > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > > >
> > > > > > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > > > > > >
> > > > > > > > "make check" should be clean on Fedora 33/x86-64.
> > > > > > >
> > > > > > > Because this lld error, "make check" didn't report test summary:
> > > > > > >
> > > > > > > Summary of test results:
> > > > > > > 4322 PASS
> > > > > > > 8 UNSUPPORTED
> > > > > > > 13 XFAIL
> > > > > > > 6 XPASS
> > > > > > >
> > > > > > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > > > > > >
> > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > > > > > >Segmentation fault (core dumped)
> > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > > > > > >
> > > > > > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > > > > > >configure can check it.
> > > > > > > > >
> > > > > > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > > > > > >
> > > > > > > > Why isn't it needed for ld?
> > > > > > > >
> > > > > > >
> > > > > > > Also re-order your patches to place the enabling lld patch the last so that any
> > > > > > > commits can build a working glibc.
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > --
> > > > > > > H.J.
> > > > > >
> > > > > > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > > > > > rejects LLD at configure time and the other commits cannot be tested
> > > > > > at all...
> > > > > >
> > > > > > The other commits are general improvement and useful on their own, and
> > > > > > they are independent and can be merged separately.
> > > > > >
> > > > > > As I mentioned in the other reply, LLD does not want to special case
> > > > > > the definition of __rela_iplt_start depending on -no-pie (available in
> > > > > > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > > > > > The TLS common issues are obsoleted features that do not make sense nowadays.
> > > > > > Any case, the LLD produced executables are functional.
> > > > >
> > > > > The code in question is
> > > > >
> > > > > static void
> > > > > apply_irel (void)
> > > > > {
> > > > > # ifdef IREL
> > > > > /* We use weak references for these so that we'll still work with a linker
> > > > > that doesn't define them. Such a linker doesn't support IFUNC at all
> > > > > and so uses won't work, but a statically-linked program that doesn't
> > > > > use any IFUNC symbols won't have a problem. */
> > > > > extern const IREL_T IPLT_START[] __attribute__ ((weak));
> > > > > extern const IREL_T IPLT_END[] __attribute__ ((weak));
> > > > > for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> > > > > IREL (ipltent);
> > > > > # endif
> > > > > }
> > > > >
> > > > > Since IPLT_START and IPLT_END are undefined, linker should set
> > > > > them to zero and the loop should be skipped. Why doesn't LLD do
> > > > > that?
> > > > >
> > > > >
> > > > > --
> > > > > H.J.
> > > >
> > > > LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
> > > > exists and is not defined (2) not -r (3) no .interp
> > > >
> > > > LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
> > > > behavior makes sense to me.
> > > > GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
> > >
> > > It is an lld bug:
> > >
> > > https://bugs.llvm.org/show_bug.cgi?id=48674
> > >
> > > --
> > > H.J.
> >
> > I don't consider https://bugs.llvm.org/show_bug.cgi?id=48674 an LLD
> > bug, so we have disagreement.
> >
> > __rela_iplt_start/__rela_iplt_end is a contract between the link
> > editor and the dynamic loader/libc. For the perspective of a good
> > design, I don't think it is necessary making
> > "whether to define __rela_iplt_start" different for ld -no-pie (GNU ld
> > does not have -no-pie currently, but gold and LLD do) and ld -pie.
> >
> > rtld/libc can just figure out whether it is -static-pie (since a
> > different crt1 rcrt1.o is used) and don't reference __rela_iplt_start
> > in that case.
> >
> > If this difference is dropped (by taking the glibc patch "Make
> > _dl_relocate_static_pie return an int indicating whether it applied
> > relocs."),
> > diff -u =(ld.bfd --verbose) =(ld.bfd -pie --verbose) can have no
> > difference other than the start address: __executable_start.
>
> I designed and implemented the whole thing in ld and glibc
> many years ago.
I see, binutils commit 3aa14d16c669ca75f9fa4e995a2e2d13069dff3f
(2009-06-01) added __rela_iplt_start.
> I don't think they should be changed. lld should follow my design.
However, that was before glibc gained static pie support (2017;
http://sourceware.org/PR19574). With static pie, I think
__rela_iplt_start should be revised.
I have made many compatibility changes to LLD, but this one seems
unreasonable, so I am not inclined to folllow.
I'll personally add this to my list of incompatibilities
https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-06 2:00 ` Fāng-ruì Sòng
@ 2021-01-06 2:14 ` H.J. Lu
0 siblings, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2021-01-06 2:14 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: GNU C Library
On Tue, Jan 5, 2021 at 6:00 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Jan 5, 2021 at 5:44 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 5, 2021 at 4:51 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On Tue, Jan 5, 2021 at 3:52 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Tue, Jan 5, 2021 at 3:41 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > >
> > > > > On Tue, Jan 5, 2021 at 3:34 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, Jan 5, 2021 at 3:03 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > > > > >
> > > > > > > On Mon, Dec 28, 2020 at 2:54 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Dec 28, 2020 at 1:49 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Dec 28, 2020 at 1:45 PM Fangrui Song <maskray@google.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On 2020-12-28, H.J. Lu wrote:
> > > > > > > > > > >On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song via Libc-alpha
> > > > > > > > > > ><libc-alpha@sourceware.org> wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> I sent the first two in April. Resending in a patch series to be
> > > > > > > > > > >> clearer.
> > > > > > > > > > >>
> > > > > > > > > > >> install: Replace scripts/output-format.sed with objdump -f
> > > > > > > > > > >>
> > > > > > > > > > >> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > > > > > > > > >> by leveraging objdump -f.
> > > > > > > > > > >>
> > > > > > > > > > >> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > > > > > > > > >> `make` with ld pointing to ld.lld (LLVM linker) works.
> > > > > > > > > > >
> > > > > > > > > > >I tried your branch with "LLD 11.0.0 (compatible with GNU linkers)" on
> > > > > > > > > > >Fedora 33/x86-64,
> > > > > > > > > > >"make check" generated:
> > > > > > > > > > >
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Makerules:767:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[4]: *** [../Rules:226:
> > > > > > > > > > >/export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1]
> > > > > > > > > > >Error 1
> > > > > > > > > > >make[3]: *** [Makefile:479: elf/tests] Error 2
> > > > > > > > > > >
> > > > > > > > > > >with error messages, like
> > > > > > > > > > >
> > > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.os
> > > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > > > > >ld: error: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.os
> > > > > > > > > > >has an STT_TLS symbol but doesn't have an SHF_TLS section
> > > > > > > > > >
> > > > > > > > > > tst-tls* tests appear to be similar to .tls_common which looks very
> > > > > > > > > > obsoleted and not supported by Clang. I don't think ifuncmain* or
> > > > > > > > > > tst-audit* matters for typical usage (most users) but I can take a look.
> > > > > > > > >
> > > > > > > > > "make check" should be clean on Fedora 33/x86-64.
> > > > > > > >
> > > > > > > > Because this lld error, "make check" didn't report test summary:
> > > > > > > >
> > > > > > > > Summary of test results:
> > > > > > > > 4322 PASS
> > > > > > > > 8 UNSUPPORTED
> > > > > > > > 13 XFAIL
> > > > > > > > 6 XPASS
> > > > > > > >
> > > > > > > > > > >When glibc is configured with --enable-static-pie, I got
> > > > > > > > > > >
> > > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig
> > > > > > > > > > >Segmentation fault (core dumped)
> > > > > > > > > > >[hjl@gnu-skx-1 build-x86_64-linux]$
> > > > > > > > > > >
> > > > > > > > > > >You need to fix lld first and give the working lld a proper version so that
> > > > > > > > > > >configure can check it.
> > > > > > > > > >
> > > > > > > > > > I cherry picked "Make _dl_relocate_static_pie return an int indicating whether it applied relocs."
> > > > > > > > > > in google/grte/v5-2.27/master, which has fixed the issue.
> > > > > > > > >
> > > > > > > > > Why isn't it needed for ld?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Also re-order your patches to place the enabling lld patch the last so that any
> > > > > > > > commits can build a working glibc.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > --
> > > > > > > > H.J.
> > > > > > >
> > > > > > > Without "configure: Allow LD to be LLD 9.0.0 or above", configure
> > > > > > > rejects LLD at configure time and the other commits cannot be tested
> > > > > > > at all...
> > > > > > >
> > > > > > > The other commits are general improvement and useful on their own, and
> > > > > > > they are independent and can be merged separately.
> > > > > > >
> > > > > > > As I mentioned in the other reply, LLD does not want to special case
> > > > > > > the definition of __rela_iplt_start depending on -no-pie (available in
> > > > > > > gold and LLD, not available in GNU ld yet) ; -pie/-shared...
> > > > > > > The TLS common issues are obsoleted features that do not make sense nowadays.
> > > > > > > Any case, the LLD produced executables are functional.
> > > > > >
> > > > > > The code in question is
> > > > > >
> > > > > > static void
> > > > > > apply_irel (void)
> > > > > > {
> > > > > > # ifdef IREL
> > > > > > /* We use weak references for these so that we'll still work with a linker
> > > > > > that doesn't define them. Such a linker doesn't support IFUNC at all
> > > > > > and so uses won't work, but a statically-linked program that doesn't
> > > > > > use any IFUNC symbols won't have a problem. */
> > > > > > extern const IREL_T IPLT_START[] __attribute__ ((weak));
> > > > > > extern const IREL_T IPLT_END[] __attribute__ ((weak));
> > > > > > for (const IREL_T *ipltent = IPLT_START; ipltent < IPLT_END; ++ipltent)
> > > > > > IREL (ipltent);
> > > > > > # endif
> > > > > > }
> > > > > >
> > > > > > Since IPLT_START and IPLT_END are undefined, linker should set
> > > > > > them to zero and the loop should be skipped. Why doesn't LLD do
> > > > > > that?
> > > > > >
> > > > > >
> > > > > > --
> > > > > > H.J.
> > > > >
> > > > > LLD defines __rela_iplt_start/__rela_iplt_end if (1) __rela_iplt_start
> > > > > exists and is not defined (2) not -r (3) no .interp
> > > > >
> > > > > LLD defines __rela_iplt_start regardless of -no-pie/-pie. This
> > > > > behavior makes sense to me.
> > > > > GNU ld and gold seem to only define __rela_iplt_start in -no-pie mode.
> > > >
> > > > It is an lld bug:
> > > >
> > > > https://bugs.llvm.org/show_bug.cgi?id=48674
> > > >
> > > > --
> > > > H.J.
> > >
> > > I don't consider https://bugs.llvm.org/show_bug.cgi?id=48674 an LLD
> > > bug, so we have disagreement.
> > >
> > > __rela_iplt_start/__rela_iplt_end is a contract between the link
> > > editor and the dynamic loader/libc. For the perspective of a good
> > > design, I don't think it is necessary making
> > > "whether to define __rela_iplt_start" different for ld -no-pie (GNU ld
> > > does not have -no-pie currently, but gold and LLD do) and ld -pie.
> > >
> > > rtld/libc can just figure out whether it is -static-pie (since a
> > > different crt1 rcrt1.o is used) and don't reference __rela_iplt_start
> > > in that case.
> > >
> > > If this difference is dropped (by taking the glibc patch "Make
> > > _dl_relocate_static_pie return an int indicating whether it applied
> > > relocs."),
> > > diff -u =(ld.bfd --verbose) =(ld.bfd -pie --verbose) can have no
> > > difference other than the start address: __executable_start.
> >
> > I designed and implemented the whole thing in ld and glibc
> > many years ago.
>
> I see, binutils commit 3aa14d16c669ca75f9fa4e995a2e2d13069dff3f
> (2009-06-01) added __rela_iplt_start.
>
> > I don't think they should be changed. lld should follow my design.
>
> However, that was before glibc gained static pie support (2017;
> http://sourceware.org/PR19574). With static pie, I think
> __rela_iplt_start should be revised.
> I have made many compatibility changes to LLD, but this one seems
> unreasonable, so I am not inclined to folllow.
> I'll personally add this to my list of incompatibilities
> https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities
Please move the IFUNC discussion to
https://bugs.llvm.org/show_bug.cgi?id=48674
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
` (3 preceding siblings ...)
2020-12-28 21:11 ` [PATCH 0/3] Make glibc build with LLD H.J. Lu
@ 2021-01-08 5:04 ` Fāng-ruì Sòng
2021-01-08 17:09 ` H.J. Lu
4 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-08 5:04 UTC (permalink / raw)
To: GNU C Library
On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> wrote:
>
> I sent the first two in April. Resending in a patch series to be
> clearer.
>
> install: Replace scripts/output-format.sed with objdump -f
>
> replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> by leveraging objdump -f.
>
> With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> `make` with ld pointing to ld.lld (LLVM linker) works.
>
> Fangrui Song (3):
> configure: Allow LD to be a linker other than GNU ld and gold
> elf: Replace a --defsym trick with an object file to be compatible
> with lld
> install: Replace scripts/output-format.sed with objdump -f
>
> Makerules | 13 ++-----
> .../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
> config.make.in | 1 -
> configure | 32 +++++------------
> configure.ac | 24 +++++--------
> elf/Makefile | 11 +++---
> scripts/output-format.sed | 35 -------------------
> 7 files changed, 23 insertions(+), 94 deletions(-)
> delete mode 100644 scripts/output-format.sed
>
> --
> 2.29.2.729.g45daf8777d-goog
>
Hope "elf:" and "install:" can be reviewed (they are nice
simplification on their own), even if you don't want to take
"configure:" for now.
For __rela_iplt_start, I gave a fair assessment on
https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an
improvable binutils issue caused the block of a static-pie relocation
improvement
"Make _dl_relocate_static_pie return an int indicating whether it
applied relocs." The other few failures (e.g. not supporting ld.lld
--audit / tls common) are not really usability affecting issues.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-08 5:04 ` Fāng-ruì Sòng
@ 2021-01-08 17:09 ` H.J. Lu
2021-01-08 18:04 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-08 17:09 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: GNU C Library
On Thu, Jan 7, 2021 at 9:05 PM Fāng-ruì Sòng via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> wrote:
> >
> > I sent the first two in April. Resending in a patch series to be
> > clearer.
> >
> > install: Replace scripts/output-format.sed with objdump -f
> >
> > replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > by leveraging objdump -f.
> >
> > With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > `make` with ld pointing to ld.lld (LLVM linker) works.
> >
> > Fangrui Song (3):
> > configure: Allow LD to be a linker other than GNU ld and gold
> > elf: Replace a --defsym trick with an object file to be compatible
> > with lld
> > install: Replace scripts/output-format.sed with objdump -f
> >
> > Makerules | 13 ++-----
> > .../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
> > config.make.in | 1 -
> > configure | 32 +++++------------
> > configure.ac | 24 +++++--------
> > elf/Makefile | 11 +++---
> > scripts/output-format.sed | 35 -------------------
> > 7 files changed, 23 insertions(+), 94 deletions(-)
> > delete mode 100644 scripts/output-format.sed
> >
> > --
> > 2.29.2.729.g45daf8777d-goog
> >
>
> Hope "elf:" and "install:" can be reviewed (they are nice
> simplification on their own), even if you don't want to take
> "configure:" for now.
>
> For __rela_iplt_start, I gave a fair assessment on
> https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an
> improvable binutils issue caused the block of a static-pie relocation
> improvement
No. There is no need to work around the lld bug which can be fixed.
> "Make _dl_relocate_static_pie return an int indicating whether it
> applied relocs." The other few failures (e.g. not supporting ld.lld
> --audit / tls common) are not really usability affecting issues.
"make check" should be clean. Otherwise, we have no way to
know if glibc is built properly on x86.
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 0/3] Make glibc build with LLD
2021-01-08 17:09 ` H.J. Lu
@ 2021-01-08 18:04 ` Fāng-ruì Sòng
0 siblings, 0 replies; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-08 18:04 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
On Fri, Jan 8, 2021 at 9:10 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jan 7, 2021 at 9:05 PM Fāng-ruì Sòng via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > On Mon, Dec 28, 2020 at 11:48 AM Fangrui Song <maskray@google.com> wrote:
> > >
> > > I sent the first two in April. Resending in a patch series to be
> > > clearer.
> > >
> > > install: Replace scripts/output-format.sed with objdump -f
> > >
> > > replaced https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html
> > > by leveraging objdump -f.
> > >
> > > With this patch series (available in https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld),
> > > `make` with ld pointing to ld.lld (LLVM linker) works.
> > >
> > > Fangrui Song (3):
> > > configure: Allow LD to be a linker other than GNU ld and gold
> > > elf: Replace a --defsym trick with an object file to be compatible
> > > with lld
> > > install: Replace scripts/output-format.sed with objdump -f
> > >
> > > Makerules | 13 ++-----
> > > .../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
> > > config.make.in | 1 -
> > > configure | 32 +++++------------
> > > configure.ac | 24 +++++--------
> > > elf/Makefile | 11 +++---
> > > scripts/output-format.sed | 35 -------------------
> > > 7 files changed, 23 insertions(+), 94 deletions(-)
> > > delete mode 100644 scripts/output-format.sed
> > >
> > > --
> > > 2.29.2.729.g45daf8777d-goog
> > >
> >
> > Hope "elf:" and "install:" can be reviewed (they are nice
> > simplification on their own), even if you don't want to take
> > "configure:" for now.
> >
> > For __rela_iplt_start, I gave a fair assessment on
> > https://bugs.llvm.org/show_bug.cgi?id=48674#c4 . I feel bad that an
> > improvable binutils issue caused the block of a static-pie relocation
> > improvement
>
> No. There is no need to work around the lld bug which can be fixed.
I wish the glibc change does not make people feel "oh, we change glibc
just to adapt LLD".
I have provided my reasoning
(https://sourceware.org/bugzilla/show_bug.cgi?id=27164) why this is
not an LLD bug and I believe the reasoning is pretty solid (drop a
gratuitous difference between ld and ld -pie; clarify glibc code).
This is both a (future) cleanup opportunity for GNU ld and a
clarification for glibc csu/libc-start.c
> > "Make _dl_relocate_static_pie return an int indicating whether it
> > applied relocs." The other few failures (e.g. not supporting ld.lld
> > --audit / tls common) are not really usability affecting issues.
>
> "make check" should be clean. Otherwise, we have no way to
> know if glibc is built properly on x86.
>
> --
> H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
@ 2021-01-08 19:38 ` Adhemerval Zanella
2021-01-12 11:20 ` Florian Weimer
2021-01-12 11:32 ` Andreas Schwab
1 sibling, 1 reply; 42+ messages in thread
From: Adhemerval Zanella @ 2021-01-08 19:38 UTC (permalink / raw)
To: Fangrui Song, libc-alpha
On 28/12/2020 16:48, Fangrui Song via Libc-alpha wrote:
> GNU ld and gold have supported --print-output-format since 2011. glibc
> requires binutils>=2.25 (2015), so if LD is GNU ld or gold, we can
> assume the option is supported.
>
> lld is by default a cross linker supporting multiple targets. It auto
> detects the file format and does not need OUTPUT_FORMAT. It does not
> support --print-output-format.
>
> By parsing objdump -f, we can support all the three linkers.
LGTM and this change seems orthogonal to the other lld adjustments.
I have checked that at least with a build for a handful of supported
ABIs I see no difference with ld.bfd (with multiple versions).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> ---
> Makerules | 13 ++-----
> .../strcoll-inputs/filelist#en_US.UTF-8 | 1 -
> config.make.in | 1 -
> configure | 19 ----------
> configure.ac | 11 ------
> scripts/output-format.sed | 35 -------------------
> 6 files changed, 3 insertions(+), 77 deletions(-)
> delete mode 100644 scripts/output-format.sed
>
> diff --git a/Makerules b/Makerules
> index ef0fe67d9a..146d1ab650 100644
> --- a/Makerules
> +++ b/Makerules
> @@ -1065,20 +1065,13 @@ install: $(inst_slibdir)/libc.so$(libc.so-version)
> # for the configuration we are building. We put this statement into
> # the linker scripts we install for -lc et al so that they will not be
> # used by a link for a different format on a multi-architecture system.
> -$(common-objpfx)format.lds: $(..)scripts/output-format.sed \
> - $(common-objpfx)config.make \
> +$(common-objpfx)format.lds: $(common-objpfx)config.make \
> $(common-objpfx)config.h $(..)Makerules
> -ifneq (unknown,$(output-format))
> - echo > $@.new 'OUTPUT_FORMAT($(output-format))'
> -else
> $(LINK.o) -shared $(sysdep-LDFLAGS) $(rtld-LDFLAGS) \
> $(LDFLAGS.so) $(LDFLAGS-lib.so) \
> - -x c /dev/null -o $@.so -Wl,--verbose -v 2>/dev/null \
> - | sed -n -f $< > $@.new
> - test -s $@.new
> + -x c /dev/null -o $@.so 2>/dev/null
> + $(OBJDUMP) -f $@.so | sed -n 's/.*file format \(.*\)/OUTPUT_FORMAT(\1)/;T;p' > $@
> rm -f $@.so
> -endif
> - mv -f $@.new $@
> common-generated += format.lds
>
> ifndef subdir
Ok.
> diff --git a/benchtests/strcoll-inputs/filelist#en_US.UTF-8 b/benchtests/strcoll-inputs/filelist#en_US.UTF-8
> index 2f4ef195bb..43eb9efb40 100644
> --- a/benchtests/strcoll-inputs/filelist#en_US.UTF-8
> +++ b/benchtests/strcoll-inputs/filelist#en_US.UTF-8
> @@ -9450,7 +9450,6 @@ move-if-change
> check-execstack.awk
> pylint
> pylintrc
> -output-format.sed
> merge-test-results.sh
> update-copyrights
> config-uname.sh
Ok.
> diff --git a/config.make.in b/config.make.in
> index 7ae27564fd..7f47f0caa4 100644
> --- a/config.make.in
> +++ b/config.make.in
> @@ -73,7 +73,6 @@ fno-unit-at-a-time = @fno_unit_at_a_time@
> bind-now = @bindnow@
> have-hash-style = @libc_cv_hashstyle@
> use-default-link = @use_default_link@
> -output-format = @libc_cv_output_format@
> have-cxx-thread_local = @libc_cv_cxx_thread_local@
> have-loop-to-function = @libc_cv_cc_loop_to_function@
> have-textrel_ifunc = @libc_cv_textrel_ifunc@
Ok.
> diff --git a/configure b/configure
> index 6dcd2270f8..4b0ab150cb 100755
> --- a/configure
> +++ b/configure
> @@ -623,7 +623,6 @@ libc_cv_cc_submachine
> libc_cv_cc_nofma
> libc_cv_mtls_dialect_gnu2
> fno_unit_at_a_time
> -libc_cv_output_format
> libc_cv_has_glob_dat
> libc_cv_hashstyle
> libc_cv_fpie
> @@ -6077,24 +6076,6 @@ fi
> $as_echo "$libc_cv_has_glob_dat" >&6; }
>
>
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker output format" >&5
> -$as_echo_n "checking linker output format... " >&6; }
> -if ${libc_cv_output_format+:} false; then :
> - $as_echo_n "(cached) " >&6
> -else
> - if libc_cv_output_format=`
> -${CC-cc} -nostartfiles -nostdlib $no_ssp -Wl,--print-output-format 2>&5`
> -then
> - :
> -else
> - libc_cv_output_format=
> -fi
> -test -n "$libc_cv_output_format" || libc_cv_output_format=unknown
> -fi
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_output_format" >&5
> -$as_echo "$libc_cv_output_format" >&6; }
> -
> -
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -fno-toplevel-reorder -fno-section-anchors" >&5
> $as_echo_n "checking for -fno-toplevel-reorder -fno-section-anchors... " >&6; }
> if ${libc_cv_fno_toplevel_reorder+:} false; then :
> diff --git a/configure.ac b/configure.ac
> index 1a2054cd1a..baf3a05ae7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1432,17 +1432,6 @@ fi
> rm -f conftest*])
> AC_SUBST(libc_cv_has_glob_dat)
>
> -AC_CACHE_CHECK(linker output format, libc_cv_output_format, [dnl
> -if libc_cv_output_format=`
> -${CC-cc} -nostartfiles -nostdlib $no_ssp -Wl,--print-output-format 2>&AS_MESSAGE_LOG_FD`
> -then
> - :
> -else
> - libc_cv_output_format=
> -fi
> -test -n "$libc_cv_output_format" || libc_cv_output_format=unknown])
> -AC_SUBST(libc_cv_output_format)
> -
> AC_CACHE_CHECK(for -fno-toplevel-reorder -fno-section-anchors, libc_cv_fno_toplevel_reorder, [dnl
> cat > conftest.c <<EOF
> int foo;
Ok.
> diff --git a/scripts/output-format.sed b/scripts/output-format.sed
> deleted file mode 100644
> index 364f52059f..0000000000
> --- a/scripts/output-format.sed
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/ld.*[ ]-E[BL]/b f
> -/collect.*[ ]-E[BL]/b f
> -/OUTPUT_FORMAT[^)]*$/{N
> -s/\n[ ]*/ /
> -}
> -t o
> -: o
> -s/^.*OUTPUT_FORMAT(\([^,]*\), \1, \1).*$/OUTPUT_FORMAT(\1)/
> -t q
> -s/^.*OUTPUT_FORMAT(\([^,]*\), \([^,]*\), \([^,]*\)).*$/\1,\2,\3/
> -t s
> -s/^.*OUTPUT_FORMAT(\([^,)]*\).*$)/OUTPUT_FORMAT(\1)/
> -t q
> -d
> -: s
> -s/"//g
> -G
> -s/\n//
> -s/^\([^,]*\),\([^,]*\),\([^,]*\),B/OUTPUT_FORMAT(\2)/p
> -s/^\([^,]*\),\([^,]*\),\([^,]*\),L/OUTPUT_FORMAT(\3)/p
> -s/^\([^,]*\),\([^,]*\),\([^,]*\)/OUTPUT_FORMAT(\1)/p
> -/,/s|^|*** BUG in libc/scripts/output-format.sed *** |p
> -q
> -: q
> -s/"//g
> -p
> -q
> -: f
> -s/^.*[ ]-E\([BL]\)[ ].*$/,\1/
> -t h
> -s/^.*[ ]-E\([BL]\)$/,\1/
> -t h
> -d
> -: h
> -h
>
Ok.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
@ 2021-01-11 20:06 ` Fāng-ruì Sòng
2021-01-18 22:08 ` Fāng-ruì Sòng
2021-01-19 0:03 ` H.J. Lu
1 sibling, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-11 20:06 UTC (permalink / raw)
To: GNU C Library
On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song <maskray@google.com> wrote:
>
> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> fetched. This trick is used to avoid multiple definition errors which
> would happen as a chain result:
>
> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> free fetches libc_pic.a(malloc.os)
> libc_pic.a(malloc.os) has an undefined __libc_message
> __libc_message fetches libc_pic.a(libc_fatal.os)
>
> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >>> defined at dl-fxstatat64.c
> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >>> defined at libc_fatal.c
> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>
> lld processes --defsym after all input files, so this trick does not
> suppress multiple definition errors with lld. Split the step into two
> and use an object file to make the intention more obvious and make lld
> work.
>
> This is conceptually more appropriate because --defsym defines a SHN_ABS
> symbol while a normal definition is relative to the image base.
>
> See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
> for discussions about the --defsym semantics.
> ---
> elf/Makefile | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
Ping on this
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2021-01-08 19:38 ` Adhemerval Zanella
@ 2021-01-12 11:20 ` Florian Weimer
2021-01-12 12:00 ` Adhemerval Zanella
0 siblings, 1 reply; 42+ messages in thread
From: Florian Weimer @ 2021-01-12 11:20 UTC (permalink / raw)
To: Adhemerval Zanella via Libc-alpha; +Cc: Fangrui Song, Adhemerval Zanella
* Adhemerval Zanella via Libc-alpha:
> On 28/12/2020 16:48, Fangrui Song via Libc-alpha wrote:
>> GNU ld and gold have supported --print-output-format since 2011. glibc
>> requires binutils>=2.25 (2015), so if LD is GNU ld or gold, we can
>> assume the option is supported.
>>
>> lld is by default a cross linker supporting multiple targets. It auto
>> detects the file format and does not need OUTPUT_FORMAT. It does not
>> support --print-output-format.
>>
>> By parsing objdump -f, we can support all the three linkers.
>
> LGTM and this change seems orthogonal to the other lld adjustments.
> I have checked that at least with a build for a handful of supported
> ABIs I see no difference with ld.bfd (with multiple versions).
I see a cross-build failure during the initial static link bootstrap on
aarch64-linux-gnu during “make install”:
make[2]: Entering directory '/home/bmg/src/glibc'
aarch64-glibc-linux-gnu-gcc -shared -Wl,-dynamic-linker=/lib/ld-linux-aarch64.so.1 \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both \
-x c /dev/null -o /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds.so
/home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
make[2]: *** [Makerules:1070: /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds] Error 1
This affects other targets as well.
I guess using
$(CC) -nostdlib -nostartfiles -shared -x assembler /dev/null
should work on most targets here.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
2021-01-08 19:38 ` Adhemerval Zanella
@ 2021-01-12 11:32 ` Andreas Schwab
2021-01-12 11:58 ` Florian Weimer
1 sibling, 1 reply; 42+ messages in thread
From: Andreas Schwab @ 2021-01-12 11:32 UTC (permalink / raw)
To: Fangrui Song via Libc-alpha; +Cc: Fangrui Song
gcc -shared -Wl,-z,force-bti -Wl,-dynamic-linker=/lib/ld-linux-aarch64.so.1 \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,now -Wl,--fatal-warnings \
-x c /dev/null -o /home/abuild/rpmbuild/BUILD/glibc-2.32.9000.527.g87d583c6e8/cc-base/format.lds.so 2>/dev/null
make[1]: *** [Makerules:1070: /home/abuild/rpmbuild/BUILD/glibc-2.32.9000.527.g87d583c6e8/cc-base/format.lds] Error 1
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2021-01-12 11:32 ` Andreas Schwab
@ 2021-01-12 11:58 ` Florian Weimer
0 siblings, 0 replies; 42+ messages in thread
From: Florian Weimer @ 2021-01-12 11:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Fangrui Song via Libc-alpha, Fangrui Song
* Andreas Schwab:
> gcc -shared -Wl,-z,force-bti -Wl,-dynamic-linker=/lib/ld-linux-aarch64.so.1 \
> -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,now -Wl,--fatal-warnings \
> -x c /dev/null -o /home/abuild/rpmbuild/BUILD/glibc-2.32.9000.527.g87d583c6e8/cc-base/format.lds.so 2>/dev/null
> make[1]: *** [Makerules:1070: /home/abuild/rpmbuild/BUILD/glibc-2.32.9000.527.g87d583c6e8/cc-base/format.lds] Error 1
<https://sourceware.org/pipermail/libc-alpha/2021-January/121535.html>
I'm testing the proposed fix. So far it's looking good.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2021-01-12 11:20 ` Florian Weimer
@ 2021-01-12 12:00 ` Adhemerval Zanella
2021-01-12 17:46 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: Adhemerval Zanella @ 2021-01-12 12:00 UTC (permalink / raw)
To: Florian Weimer, Adhemerval Zanella via Libc-alpha; +Cc: Fangrui Song
On 12/01/2021 08:20, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
>
>> On 28/12/2020 16:48, Fangrui Song via Libc-alpha wrote:
>>> GNU ld and gold have supported --print-output-format since 2011. glibc
>>> requires binutils>=2.25 (2015), so if LD is GNU ld or gold, we can
>>> assume the option is supported.
>>>
>>> lld is by default a cross linker supporting multiple targets. It auto
>>> detects the file format and does not need OUTPUT_FORMAT. It does not
>>> support --print-output-format.
>>>
>>> By parsing objdump -f, we can support all the three linkers.
>>
>> LGTM and this change seems orthogonal to the other lld adjustments.
>> I have checked that at least with a build for a handful of supported
>> ABIs I see no difference with ld.bfd (with multiple versions).
>
> I see a cross-build failure during the initial static link bootstrap on
> aarch64-linux-gnu during “make install”:
>
> make[2]: Entering directory '/home/bmg/src/glibc'
> aarch64-glibc-linux-gnu-gcc -shared -Wl,-dynamic-linker=/lib/ld-linux-aarch64.so.1 \
> -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both \
> -x c /dev/null -o /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds.so
> /home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
> /home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makerules:1070: /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds] Error 1
>
> This affects other targets as well.
>
> I guess using
>
> $(CC) -nostdlib -nostartfiles -shared -x assembler /dev/null
>
> should work on most targets here.
I haven't see it when a stage2 gcc, make install works as intended. However I
did see it now with a stage1 gcc with build-many-glibcs.py.
The -nostdlib -nostartfiles seems to fix it indeed, I am checking with a
bootstrap using build-many-glibcs.py.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559]
2021-01-12 12:00 ` Adhemerval Zanella
@ 2021-01-12 17:46 ` Fāng-ruì Sòng
0 siblings, 0 replies; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-12 17:46 UTC (permalink / raw)
To: Florian Weimer; +Cc: Adhemerval Zanella via Libc-alpha, Adhemerval Zanella
On Tue, Jan 12, 2021 at 4:00 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 12/01/2021 08:20, Florian Weimer wrote:
> > * Adhemerval Zanella via Libc-alpha:
> >
> >> On 28/12/2020 16:48, Fangrui Song via Libc-alpha wrote:
> >>> GNU ld and gold have supported --print-output-format since 2011. glibc
> >>> requires binutils>=2.25 (2015), so if LD is GNU ld or gold, we can
> >>> assume the option is supported.
> >>>
> >>> lld is by default a cross linker supporting multiple targets. It auto
> >>> detects the file format and does not need OUTPUT_FORMAT. It does not
> >>> support --print-output-format.
> >>>
> >>> By parsing objdump -f, we can support all the three linkers.
> >>
> >> LGTM and this change seems orthogonal to the other lld adjustments.
> >> I have checked that at least with a build for a handful of supported
> >> ABIs I see no difference with ld.bfd (with multiple versions).
> >
> > I see a cross-build failure during the initial static link bootstrap on
> > aarch64-linux-gnu during “make install”:
> >
> > make[2]: Entering directory '/home/bmg/src/glibc'
> > aarch64-glibc-linux-gnu-gcc -shared -Wl,-dynamic-linker=/lib/ld-linux-aarch64.so.1 \
> > -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both \
> > -x c /dev/null -o /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds.so
> > /home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
> > /home/bmg/install/compilers/aarch64-linux-gnu/lib/gcc/aarch64-glibc-linux-gnu/10.2.1/../../../../aarch64-glibc-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [Makerules:1070: /home/bmg/build/compilers/aarch64-linux-gnu/glibc/aarch64-linux-gnu/format.lds] Error 1
> >
> > This affects other targets as well.
> >
> > I guess using
> >
> > $(CC) -nostdlib -nostartfiles -shared -x assembler /dev/null
> >
> > should work on most targets here.
>
> I haven't see it when a stage2 gcc, make install works as intended. However I
> did see it now with a stage1 gcc with build-many-glibcs.py.
>
> The -nostdlib -nostartfiles seems to fix it indeed, I am checking with a
> bootstrap using build-many-glibcs.py.
Thanks for the fix 0400f928335a5e04c788e1c831d8825d42612c49!
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-11 20:06 ` Fāng-ruì Sòng
@ 2021-01-18 22:08 ` Fāng-ruì Sòng
0 siblings, 0 replies; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-18 22:08 UTC (permalink / raw)
To: GNU C Library
On Mon, Jan 11, 2021 at 12:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Mon, Dec 28, 2020 at 11:49 AM Fangrui Song <maskray@google.com> wrote:
> >
> > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > fetched. This trick is used to avoid multiple definition errors which
> > would happen as a chain result:
> >
> > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > free fetches libc_pic.a(malloc.os)
> > libc_pic.a(malloc.os) has an undefined __libc_message
> > __libc_message fetches libc_pic.a(libc_fatal.os)
> >
> > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > >>> defined at dl-fxstatat64.c
> > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > >>> defined at libc_fatal.c
> > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >
> > lld processes --defsym after all input files, so this trick does not
> > suppress multiple definition errors with lld. Split the step into two
> > and use an object file to make the intention more obvious and make lld
> > work.
> >
> > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > symbol while a normal definition is relative to the image base.
> >
> > See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
> > for discussions about the --defsym semantics.
> > ---
> > elf/Makefile | 11 ++++-------
> > 1 file changed, 4 insertions(+), 7 deletions(-)
>
> Ping on this
PING^2
https://sourceware.org/pipermail/libc-alpha/2020-December/121144.html
You can also find the commit in
https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
2021-01-11 20:06 ` Fāng-ruì Sòng
@ 2021-01-19 0:03 ` H.J. Lu
2021-01-19 8:50 ` Fāng-ruì Sòng
1 sibling, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-19 0:03 UTC (permalink / raw)
To: Fangrui Song; +Cc: GNU C Library
On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> fetched. This trick is used to avoid multiple definition errors which
> would happen as a chain result:
>
> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> free fetches libc_pic.a(malloc.os)
> libc_pic.a(malloc.os) has an undefined __libc_message
> __libc_message fetches libc_pic.a(libc_fatal.os)
>
> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >>> defined at dl-fxstatat64.c
> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >>> defined at libc_fatal.c
> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>
> lld processes --defsym after all input files, so this trick does not
> suppress multiple definition errors with lld. Split the step into two
> and use an object file to make the intention more obvious and make lld
> work.
>
> This is conceptually more appropriate because --defsym defines a SHN_ABS
> symbol while a normal definition is relative to the image base.
>
This is irrelevant since --defsym was used to create a temporary file which was
removed immediately after it was created:
/usr/bin/gcc -nostdlib -nostartfiles -r -o
/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
-Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
-Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
-Wl,--defsym=__stack_chk_fail_local=0 \
'-Wl,-('
/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
-lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
> ---
> elf/Makefile | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/elf/Makefile b/elf/Makefile
> index 0b4d78c874..299bf24b49 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> malloc \
> realloc \
>
> -# The GCC arguments that implement $(rtld-stubbed-symbols).
> -rtld-stubbed-symbols-args = \
> - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> -
> ifeq ($(have-ssp),yes)
> # rtld is not built with the stack protector, so these references will
> # go away in the rebuilds.
> @@ -536,9 +532,10 @@ endif
>
> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> @-rm -f $@T
> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> - rm -f $@.o
> + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
Please generate
.globl symbol;
symbol = 0;
to make it closer to -Wl,--defsym=symbol=0.
> + $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> + rm -f %@T.o $@.o
> mv -f $@T $@
>
> # For lld, skip preceding addresses and values before matching the archive and the member.
> --
> 2.29.2.729.g45daf8777d-goog
>
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-19 0:03 ` H.J. Lu
@ 2021-01-19 8:50 ` Fāng-ruì Sòng
2021-01-19 12:30 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-19 8:50 UTC (permalink / raw)
To: H.J. Lu, Florian Weimer; +Cc: GNU C Library
On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > fetched. This trick is used to avoid multiple definition errors which
> > would happen as a chain result:
> >
> > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > free fetches libc_pic.a(malloc.os)
> > libc_pic.a(malloc.os) has an undefined __libc_message
> > __libc_message fetches libc_pic.a(libc_fatal.os)
> >
> > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > >>> defined at dl-fxstatat64.c
> > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > >>> defined at libc_fatal.c
> > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >
> > lld processes --defsym after all input files, so this trick does not
> > suppress multiple definition errors with lld. Split the step into two
> > and use an object file to make the intention more obvious and make lld
> > work.
> >
> > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > symbol while a normal definition is relative to the image base.
> >
>
> This is irrelevant since --defsym was used to create a temporary file which was
> removed immediately after it was created:
>
> /usr/bin/gcc -nostdlib -nostartfiles -r -o
> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> -Wl,--defsym=__stack_chk_fail_local=0 \
> '-Wl,-('
> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
> -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
>
> > ---
> > elf/Makefile | 11 ++++-------
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/elf/Makefile b/elf/Makefile
> > index 0b4d78c874..299bf24b49 100644
> > --- a/elf/Makefile
> > +++ b/elf/Makefile
> > @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> > malloc \
> > realloc \
> >
> > -# The GCC arguments that implement $(rtld-stubbed-symbols).
> > -rtld-stubbed-symbols-args = \
> > - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> > -
> > ifeq ($(have-ssp),yes)
> > # rtld is not built with the stack protector, so these references will
> > # go away in the rebuilds.
> > @@ -536,9 +532,10 @@ endif
> >
> > $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> > @-rm -f $@T
> > - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> > - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > - rm -f $@.o
> > + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> > + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
>
> Please generate
>
> .globl symbol;
> symbol = 0;
>
> to make it closer to -Wl,--defsym=symbol=0.
If symbol: and symbol = 0; work, isn't symbol: slightly better because
it looks more normal?
Or is the intention here using SHN_ABS to make it clear these symbols
are special?
> > + $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > + rm -f %@T.o $@.o
> > mv -f $@T $@
> >
> > # For lld, skip preceding addresses and values before matching the archive and the member.
> > --
> > 2.29.2.729.g45daf8777d-goog
> >
>
>
> --
> H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-19 8:50 ` Fāng-ruì Sòng
@ 2021-01-19 12:30 ` H.J. Lu
2021-01-20 18:51 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-19 12:30 UTC (permalink / raw)
To: Fāng-ruì Sòng; +Cc: Florian Weimer, GNU C Library
On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> > >
> > > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > > fetched. This trick is used to avoid multiple definition errors which
> > > would happen as a chain result:
> > >
> > > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > > free fetches libc_pic.a(malloc.os)
> > > libc_pic.a(malloc.os) has an undefined __libc_message
> > > __libc_message fetches libc_pic.a(libc_fatal.os)
> > >
> > > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > > >>> defined at dl-fxstatat64.c
> > > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > > >>> defined at libc_fatal.c
> > > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> > >
> > > lld processes --defsym after all input files, so this trick does not
> > > suppress multiple definition errors with lld. Split the step into two
> > > and use an object file to make the intention more obvious and make lld
> > > work.
> > >
> > > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > > symbol while a normal definition is relative to the image base.
> > >
> >
> > This is irrelevant since --defsym was used to create a temporary file which was
> > removed immediately after it was created:
> >
> > /usr/bin/gcc -nostdlib -nostartfiles -r -o
> > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> > -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> > -Wl,--defsym=__stack_chk_fail_local=0 \
> > '-Wl,-('
> > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
> > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
> > -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
> >
> > > ---
> > > elf/Makefile | 11 ++++-------
> > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/elf/Makefile b/elf/Makefile
> > > index 0b4d78c874..299bf24b49 100644
> > > --- a/elf/Makefile
> > > +++ b/elf/Makefile
> > > @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> > > malloc \
> > > realloc \
> > >
> > > -# The GCC arguments that implement $(rtld-stubbed-symbols).
> > > -rtld-stubbed-symbols-args = \
> > > - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> > > -
> > > ifeq ($(have-ssp),yes)
> > > # rtld is not built with the stack protector, so these references will
> > > # go away in the rebuilds.
> > > @@ -536,9 +532,10 @@ endif
> > >
> > > $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> > > @-rm -f $@T
> > > - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> > > - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > > - rm -f $@.o
> > > + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> > > + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> >
> > Please generate
> >
> > .globl symbol;
> > symbol = 0;
> >
> > to make it closer to -Wl,--defsym=symbol=0.
>
> If symbol: and symbol = 0; work, isn't symbol: slightly better because
> it looks more normal?
> Or is the intention here using SHN_ABS to make it clear these symbols
> are special?
Generate machine independent assembly codes is tricky. We should
make before and after the change as close as possible to avoid ANY
surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
to decide using ".set" vs "=".
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-19 12:30 ` H.J. Lu
@ 2021-01-20 18:51 ` Fāng-ruì Sòng
2021-01-28 1:03 ` Fāng-ruì Sòng
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-20 18:51 UTC (permalink / raw)
To: H.J. Lu; +Cc: Florian Weimer, GNU C Library
On Tue, Jan 19, 2021 at 4:31 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
> > > <libc-alpha@sourceware.org> wrote:
> > > >
> > > > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > > > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > > > fetched. This trick is used to avoid multiple definition errors which
> > > > would happen as a chain result:
> > > >
> > > > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > > > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > > > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > > > free fetches libc_pic.a(malloc.os)
> > > > libc_pic.a(malloc.os) has an undefined __libc_message
> > > > __libc_message fetches libc_pic.a(libc_fatal.os)
> > > >
> > > > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > > > >>> defined at dl-fxstatat64.c
> > > > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > > > >>> defined at libc_fatal.c
> > > > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> > > >
> > > > lld processes --defsym after all input files, so this trick does not
> > > > suppress multiple definition errors with lld. Split the step into two
> > > > and use an object file to make the intention more obvious and make lld
> > > > work.
> > > >
> > > > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > > > symbol while a normal definition is relative to the image base.
> > > >
> > >
> > > This is irrelevant since --defsym was used to create a temporary file which was
> > > removed immediately after it was created:
> > >
> > > /usr/bin/gcc -nostdlib -nostartfiles -r -o
> > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > > -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> > > -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> > > -Wl,--defsym=__stack_chk_fail_local=0 \
> > > '-Wl,-('
> > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
> > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
> > > -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > > rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > > mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
> > >
> > > > ---
> > > > elf/Makefile | 11 ++++-------
> > > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/elf/Makefile b/elf/Makefile
> > > > index 0b4d78c874..299bf24b49 100644
> > > > --- a/elf/Makefile
> > > > +++ b/elf/Makefile
> > > > @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> > > > malloc \
> > > > realloc \
> > > >
> > > > -# The GCC arguments that implement $(rtld-stubbed-symbols).
> > > > -rtld-stubbed-symbols-args = \
> > > > - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> > > > -
> > > > ifeq ($(have-ssp),yes)
> > > > # rtld is not built with the stack protector, so these references will
> > > > # go away in the rebuilds.
> > > > @@ -536,9 +532,10 @@ endif
> > > >
> > > > $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> > > > @-rm -f $@T
> > > > - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> > > > - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > > > - rm -f $@.o
> > > > + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> > > > + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> > >
> > > Please generate
> > >
> > > .globl symbol;
> > > symbol = 0;
> > >
> > > to make it closer to -Wl,--defsym=symbol=0.
> >
> > If symbol: and symbol = 0; work, isn't symbol: slightly better because
> > it looks more normal?
> > Or is the intention here using SHN_ABS to make it clear these symbols
> > are special?
>
> Generate machine independent assembly codes is tricky. We should
> make before and after the change as close as possible to avoid ANY
> surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
> to decide using ".set" vs "=".
>
> --
> H.J.
Thanks for the tip. In this case I think the patch as is (sticking
with `foo:`, don't use `foo = 0` or set) is better.
foo: works everywhere.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-20 18:51 ` Fāng-ruì Sòng
@ 2021-01-28 1:03 ` Fāng-ruì Sòng
2021-01-29 14:38 ` Adhemerval Zanella
0 siblings, 1 reply; 42+ messages in thread
From: Fāng-ruì Sòng @ 2021-01-28 1:03 UTC (permalink / raw)
To: Florian Weimer; +Cc: H.J. Lu, GNU C Library
On Wed, Jan 20, 2021 at 10:51 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Jan 19, 2021 at 4:31 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
> > > > <libc-alpha@sourceware.org> wrote:
> > > > >
> > > > > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > > > > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > > > > fetched. This trick is used to avoid multiple definition errors which
> > > > > would happen as a chain result:
> > > > >
> > > > > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > > > > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > > > > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > > > > free fetches libc_pic.a(malloc.os)
> > > > > libc_pic.a(malloc.os) has an undefined __libc_message
> > > > > __libc_message fetches libc_pic.a(libc_fatal.os)
> > > > >
> > > > > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > > > > >>> defined at dl-fxstatat64.c
> > > > > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > > > > >>> defined at libc_fatal.c
> > > > > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> > > > >
> > > > > lld processes --defsym after all input files, so this trick does not
> > > > > suppress multiple definition errors with lld. Split the step into two
> > > > > and use an object file to make the intention more obvious and make lld
> > > > > work.
> > > > >
> > > > > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > > > > symbol while a normal definition is relative to the image base.
> > > > >
> > > >
> > > > This is irrelevant since --defsym was used to create a temporary file which was
> > > > removed immediately after it was created:
> > > >
> > > > /usr/bin/gcc -nostdlib -nostartfiles -r -o
> > > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > > > -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> > > > -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> > > > -Wl,--defsym=__stack_chk_fail_local=0 \
> > > > '-Wl,-('
> > > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
> > > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
> > > > -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > > > rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> > > > mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> > > > /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
> > > >
> > > > > ---
> > > > > elf/Makefile | 11 ++++-------
> > > > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/elf/Makefile b/elf/Makefile
> > > > > index 0b4d78c874..299bf24b49 100644
> > > > > --- a/elf/Makefile
> > > > > +++ b/elf/Makefile
> > > > > @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> > > > > malloc \
> > > > > realloc \
> > > > >
> > > > > -# The GCC arguments that implement $(rtld-stubbed-symbols).
> > > > > -rtld-stubbed-symbols-args = \
> > > > > - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> > > > > -
> > > > > ifeq ($(have-ssp),yes)
> > > > > # rtld is not built with the stack protector, so these references will
> > > > > # go away in the rebuilds.
> > > > > @@ -536,9 +532,10 @@ endif
> > > > >
> > > > > $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> > > > > @-rm -f $@T
> > > > > - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> > > > > - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > > > > - rm -f $@.o
> > > > > + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> > > > > + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> > > >
> > > > Please generate
> > > >
> > > > .globl symbol;
> > > > symbol = 0;
> > > >
> > > > to make it closer to -Wl,--defsym=symbol=0.
> > >
> > > If symbol: and symbol = 0; work, isn't symbol: slightly better because
> > > it looks more normal?
> > > Or is the intention here using SHN_ABS to make it clear these symbols
> > > are special?
> >
> > Generate machine independent assembly codes is tricky. We should
> > make before and after the change as close as possible to avoid ANY
> > surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
> > to decide using ".set" vs "=".
> >
> > --
> > H.J.
>
> Thanks for the tip. In this case I think the patch as is (sticking
> with `foo:`, don't use `foo = 0` or set) is better.
> foo: works everywhere.
Ping. I think the patch as-is is better than the alternative approach
using either `=` or `.set`.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-28 1:03 ` Fāng-ruì Sòng
@ 2021-01-29 14:38 ` Adhemerval Zanella
2021-01-29 15:29 ` H.J. Lu
0 siblings, 1 reply; 42+ messages in thread
From: Adhemerval Zanella @ 2021-01-29 14:38 UTC (permalink / raw)
To: Fāng-ruì Sòng, Florian Weimer; +Cc: GNU C Library
On 27/01/2021 22:03, Fāng-ruì Sòng via Libc-alpha wrote:
> On Wed, Jan 20, 2021 at 10:51 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>>
>> On Tue, Jan 19, 2021 at 4:31 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>>>>
>>>> On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>
>>>>> On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
>>>>> <libc-alpha@sourceware.org> wrote:
>>>>>>
>>>>>> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
>>>>>> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
>>>>>> fetched. This trick is used to avoid multiple definition errors which
>>>>>> would happen as a chain result:
>>>>>>
>>>>>> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
>>>>>> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
>>>>>> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
>>>>>> free fetches libc_pic.a(malloc.os)
>>>>>> libc_pic.a(malloc.os) has an undefined __libc_message
>>>>>> __libc_message fetches libc_pic.a(libc_fatal.os)
>>>>>>
>>>>>> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>>>>> >>> defined at dl-fxstatat64.c
>>>>>> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>>>>> >>> defined at libc_fatal.c
>>>>>> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>>>>>>
>>>>>> lld processes --defsym after all input files, so this trick does not
>>>>>> suppress multiple definition errors with lld. Split the step into two
>>>>>> and use an object file to make the intention more obvious and make lld
>>>>>> work.
>>>>>>
>>>>>> This is conceptually more appropriate because --defsym defines a SHN_ABS
>>>>>> symbol while a normal definition is relative to the image base.
>>>>>>
>>>>>
>>>>> This is irrelevant since --defsym was used to create a temporary file which was
>>>>> removed immediately after it was created:
>>>>>
>>>>> /usr/bin/gcc -nostdlib -nostartfiles -r -o
>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
>>>>> -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
>>>>> -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
>>>>> -Wl,--defsym=__stack_chk_fail_local=0 \
>>>>> '-Wl,-('
>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
>>>>> -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
>>>>> rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
>>>>> mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
>>>>>
>>>>>> ---
>>>>>> elf/Makefile | 11 ++++-------
>>>>>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>>>>>
>>>>>> diff --git a/elf/Makefile b/elf/Makefile
>>>>>> index 0b4d78c874..299bf24b49 100644
>>>>>> --- a/elf/Makefile
>>>>>> +++ b/elf/Makefile
>>>>>> @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
>>>>>> malloc \
>>>>>> realloc \
>>>>>>
>>>>>> -# The GCC arguments that implement $(rtld-stubbed-symbols).
>>>>>> -rtld-stubbed-symbols-args = \
>>>>>> - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
>>>>>> -
>>>>>> ifeq ($(have-ssp),yes)
>>>>>> # rtld is not built with the stack protector, so these references will
>>>>>> # go away in the rebuilds.
>>>>>> @@ -536,9 +532,10 @@ endif
>>>>>>
>>>>>> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
>>>>>> @-rm -f $@T
>>>>>> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
>>>>>> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
>>>>>> - rm -f $@.o
>>>>>> + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
>>>>>> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
>>>>>
>>>>> Please generate
>>>>>
>>>>> .globl symbol;
>>>>> symbol = 0;
>>>>>
>>>>> to make it closer to -Wl,--defsym=symbol=0.
>>>>
>>>> If symbol: and symbol = 0; work, isn't symbol: slightly better because
>>>> it looks more normal?
>>>> Or is the intention here using SHN_ABS to make it clear these symbols
>>>> are special?
>>>
>>> Generate machine independent assembly codes is tricky. We should
>>> make before and after the change as close as possible to avoid ANY
>>> surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
>>> to decide using ".set" vs "=".
>>>
>>> --
>>> H.J.
>>
>> Thanks for the tip. In this case I think the patch as is (sticking
>> with `foo:`, don't use `foo = 0` or set) is better.
>> foo: works everywhere.
>
> Ping. I think the patch as-is is better than the alternative approach
> using either `=` or `.set`.
The patch breaks both arc-linux-gnuhf and hppa-linux-gnu with recent
ld.bfd 2.26, as below.
We will need to sort these out.
arc-linux-gnuhf:
make[2]: Entering directory '/home/azanella/glibc/glibc-git/elf'
echo '.globl calloc; .globl free; .globl malloc; .globl realloc; .globl __stack_chk_fail; .globl __stack_chk_fail_local; calloc: free: malloc: realloc: __stack_chk_fail: __stack_chk_fail_local:' | \
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/bin/arc-glibc-linux-gnuhf-gcc -o /home/azanella/glibc/build/arc-linux-gnuhf/elf/librtld.mapT.o -g -Werror=undef -Wa,--noexecstack -c -x assembler -
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/bin/arc-glibc-linux-gnuhf-gcc -nostdlib -nostartfiles -r -o /home/azanella/glibc/build/arc-linux-gnuhf/elf/librtld.map.o /home/azanella/glibc/build/arc-linux-gnuhf/elf/librtld.mapT.o '-Wl,-(' /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/home/azanella/glibc/build/arc-linux-gnuhf/elf/librtld.mapT
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(sbrk.os): in function `__GI___sbrk':
/home/azanella/glibc/glibc-git/misc/sbrk.c:37: multiple definition of `__sbrk'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/../misc/sbrk.c:37: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
/home/azanella/glibc/glibc-git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:267: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
/home/azanella/glibc/glibc-git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:267: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(_itoa.os): in function `_itoa':
/home/azanella/glibc/glibc-git/stdio-common/_itoa.c:196: multiple definition of `_itoa'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:323: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(getcwd.os): in function `__GI___getcwd':
/home/azanella/glibc/glibc-git/io/../sysdeps/unix/sysv/linux/getcwd.c:50: multiple definition of `__getcwd'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/../sysdeps/unix/sysv/linux/getcwd.c:50: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(dl-error.os): in function `__GI__dl_signal_exception':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:91: multiple definition of `_dl_signal_exception'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:91: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(dl-error.os): in function `__GI__dl_signal_error':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:109: multiple definition of `_dl_signal_error'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:109: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(dl-error.os): in function `__GI__dl_catch_exception':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:175: multiple definition of `_dl_catch_exception'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:175: first defined here
/home/azanella/toolchain/install/compilers/arc-linux-gnuhf/lib/gcc/arc-glibc-linux-gnuhf/10.2.1/../../../../arc-glibc-linux-gnuhf/bin/ld: /home/azanella/glibc/build/arc-linux-gnuhf/libc_pic.a(dl-error.os): in function `__GI__dl_catch_error':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:225: multiple definition of `_dl_catch_error'; /home/azanella/glibc/build/arc-linux-gnuhf/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:225: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:538: /home/azanella/glibc/build/arc-linux-gnuhf/elf/librtld.map] Error 1
hppa-linux-gnu:
echo '.globl calloc; .globl free; .globl malloc; .globl realloc; calloc: free: malloc: realloc:' | \
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/bin/hppa-glibc-linux-gnu-gcc -o /home/azanella/glibc/build/hppa-linux-gnu/elf/librtld.mapT.o -g -Werror=undef -c -x assembler -
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/bin/hppa-glibc-linux-gnu-gcc -nostdlib -nostartfiles -r -o /home/azanella/glibc/build/hppa-linux-gnu/elf/librtld.map.o /home/azanella/glibc/build/hppa-linux-gnu/elf/librtld.mapT.o '-Wl,-(' /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/home/azanella/glibc/build/hppa-linux-gnu/elf/librtld.mapT
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(sbrk.os): in function `__GI___sbrk':
/home/azanella/glibc/glibc-git/misc/sbrk.c:37: multiple definition of `__sbrk'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/../misc/sbrk.c:37: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
/home/azanella/glibc/glibc-git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:268: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
/home/azanella/glibc/glibc-git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:268: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(_itoa.os): in function `_itoa':
/home/azanella/glibc/glibc-git/stdio-common/_itoa.c:196: multiple definition of `_itoa'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-minimal.c:323: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(getcwd.os): in function `__GI___getcwd':
/home/azanella/glibc/glibc-git/io/../sysdeps/unix/sysv/linux/getcwd.c:50: multiple definition of `__getcwd'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/../sysdeps/unix/sysv/linux/getcwd.c:50: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(dl-error.os): in function `__GI__dl_signal_exception':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:91: multiple definition of `_dl_signal_exception'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:91: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(dl-error.os): in function `__GI__dl_signal_error':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:109: multiple definition of `_dl_signal_error'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:109: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(dl-error.os): in function `__GI__dl_catch_exception':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:175: multiple definition of `_dl_catch_exception'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:175: first defined here
/home/azanella/toolchain/install/compilers/hppa-linux-gnu/lib/gcc/hppa-glibc-linux-gnu/10.2.1/../../../../hppa-glibc-linux-gnu/bin/ld: /home/azanella/glibc/build/hppa-linux-gnu/libc_pic.a(dl-error.os): in function `__GI__dl_catch_error':
/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:225: multiple definition of `_dl_catch_error'; /home/azanella/glibc/build/hppa-linux-gnu/elf/dl-allobjs.os:/home/azanella/glibc/glibc-git/elf/dl-error-skeleton.c:225: first defined here
collect2: error: ld returned 1 exit status
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-29 14:38 ` Adhemerval Zanella
@ 2021-01-29 15:29 ` H.J. Lu
2021-01-29 18:04 ` Adhemerval Zanella
0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2021-01-29 15:29 UTC (permalink / raw)
To: Adhemerval Zanella
Cc: Fāng-ruì Sòng, Florian Weimer, GNU C Library
On Fri, Jan 29, 2021 at 7:26 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> On 27/01/2021 22:03, Fāng-ruì Sòng via Libc-alpha wrote:
> > On Wed, Jan 20, 2021 at 10:51 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> >>
> >> On Tue, Jan 19, 2021 at 4:31 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>>
> >>> On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
> >>>>
> >>>> On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>>>>
> >>>>> On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
> >>>>> <libc-alpha@sourceware.org> wrote:
> >>>>>>
> >>>>>> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> >>>>>> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> >>>>>> fetched. This trick is used to avoid multiple definition errors which
> >>>>>> would happen as a chain result:
> >>>>>>
> >>>>>> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> >>>>>> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> >>>>>> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> >>>>>> free fetches libc_pic.a(malloc.os)
> >>>>>> libc_pic.a(malloc.os) has an undefined __libc_message
> >>>>>> __libc_message fetches libc_pic.a(libc_fatal.os)
> >>>>>>
> >>>>>> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >>>>>> >>> defined at dl-fxstatat64.c
> >>>>>> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >>>>>> >>> defined at libc_fatal.c
> >>>>>> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >>>>>>
> >>>>>> lld processes --defsym after all input files, so this trick does not
> >>>>>> suppress multiple definition errors with lld. Split the step into two
> >>>>>> and use an object file to make the intention more obvious and make lld
> >>>>>> work.
> >>>>>>
> >>>>>> This is conceptually more appropriate because --defsym defines a SHN_ABS
> >>>>>> symbol while a normal definition is relative to the image base.
> >>>>>>
> >>>>>
> >>>>> This is irrelevant since --defsym was used to create a temporary file which was
> >>>>> removed immediately after it was created:
> >>>>>
> >>>>> /usr/bin/gcc -nostdlib -nostartfiles -r -o
> >>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> >>>>> -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
> >>>>> -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
> >>>>> -Wl,--defsym=__stack_chk_fail_local=0 \
> >>>>> '-Wl,-('
> >>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
> >>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
> >>>>> -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> >>>>> rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
> >>>>> mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
> >>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
> >>>>>
> >>>>>> ---
> >>>>>> elf/Makefile | 11 ++++-------
> >>>>>> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>>>>>
> >>>>>> diff --git a/elf/Makefile b/elf/Makefile
> >>>>>> index 0b4d78c874..299bf24b49 100644
> >>>>>> --- a/elf/Makefile
> >>>>>> +++ b/elf/Makefile
> >>>>>> @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
> >>>>>> malloc \
> >>>>>> realloc \
> >>>>>>
> >>>>>> -# The GCC arguments that implement $(rtld-stubbed-symbols).
> >>>>>> -rtld-stubbed-symbols-args = \
> >>>>>> - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> >>>>>> -
> >>>>>> ifeq ($(have-ssp),yes)
> >>>>>> # rtld is not built with the stack protector, so these references will
> >>>>>> # go away in the rebuilds.
> >>>>>> @@ -536,9 +532,10 @@ endif
> >>>>>>
> >>>>>> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> >>>>>> @-rm -f $@T
> >>>>>> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> >>>>>> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> >>>>>> - rm -f $@.o
> >>>>>> + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
> >>>>>> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> >>>>>
> >>>>> Please generate
> >>>>>
> >>>>> .globl symbol;
> >>>>> symbol = 0;
> >>>>>
> >>>>> to make it closer to -Wl,--defsym=symbol=0.
> >>>>
> >>>> If symbol: and symbol = 0; work, isn't symbol: slightly better because
> >>>> it looks more normal?
> >>>> Or is the intention here using SHN_ABS to make it clear these symbols
> >>>> are special?
> >>>
> >>> Generate machine independent assembly codes is tricky. We should
> >>> make before and after the change as close as possible to avoid ANY
> >>> surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
> >>> to decide using ".set" vs "=".
> >>>
> >>> --
> >>> H.J.
> >>
> >> Thanks for the tip. In this case I think the patch as is (sticking
> >> with `foo:`, don't use `foo = 0` or set) is better.
> >> foo: works everywhere.
> >
> > Ping. I think the patch as-is is better than the alternative approach
> > using either `=` or `.set`.
>
> The patch breaks both arc-linux-gnuhf and hppa-linux-gnu with recent
> ld.bfd 2.26, as below.
>
> We will need to sort these out.
>
Does my suggestion work?
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld
2021-01-29 15:29 ` H.J. Lu
@ 2021-01-29 18:04 ` Adhemerval Zanella
2021-01-29 19:28 ` [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD Fangrui Song
0 siblings, 1 reply; 42+ messages in thread
From: Adhemerval Zanella @ 2021-01-29 18:04 UTC (permalink / raw)
To: H.J. Lu; +Cc: Fāng-ruì Sòng, Florian Weimer, GNU C Library
On 29/01/2021 12:29, H.J. Lu wrote:
> On Fri, Jan 29, 2021 at 7:26 AM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>
>>
>> On 27/01/2021 22:03, Fāng-ruì Sòng via Libc-alpha wrote:
>>> On Wed, Jan 20, 2021 at 10:51 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>>>>
>>>> On Tue, Jan 19, 2021 at 4:31 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>
>>>>> On Tue, Jan 19, 2021 at 12:50 AM Fāng-ruì Sòng <maskray@google.com> wrote:
>>>>>>
>>>>>> On Mon, Jan 18, 2021 at 4:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>
>>>>>>> On Mon, Dec 28, 2020 at 11:50 AM Fangrui Song via Libc-alpha
>>>>>>> <libc-alpha@sourceware.org> wrote:
>>>>>>>>
>>>>>>>> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
>>>>>>>> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
>>>>>>>> fetched. This trick is used to avoid multiple definition errors which
>>>>>>>> would happen as a chain result:
>>>>>>>>
>>>>>>>> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
>>>>>>>> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
>>>>>>>> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
>>>>>>>> free fetches libc_pic.a(malloc.os)
>>>>>>>> libc_pic.a(malloc.os) has an undefined __libc_message
>>>>>>>> __libc_message fetches libc_pic.a(libc_fatal.os)
>>>>>>>>
>>>>>>>> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>>>>>>> >>> defined at dl-fxstatat64.c
>>>>>>>> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>>>>>>> >>> defined at libc_fatal.c
>>>>>>>> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>>>>>>>>
>>>>>>>> lld processes --defsym after all input files, so this trick does not
>>>>>>>> suppress multiple definition errors with lld. Split the step into two
>>>>>>>> and use an object file to make the intention more obvious and make lld
>>>>>>>> work.
>>>>>>>>
>>>>>>>> This is conceptually more appropriate because --defsym defines a SHN_ABS
>>>>>>>> symbol while a normal definition is relative to the image base.
>>>>>>>>
>>>>>>>
>>>>>>> This is irrelevant since --defsym was used to create a temporary file which was
>>>>>>> removed immediately after it was created:
>>>>>>>
>>>>>>> /usr/bin/gcc -nostdlib -nostartfiles -r -o
>>>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
>>>>>>> -Wl,--defsym=calloc=0 -Wl,--defsym=free=0 -Wl,--defsym=malloc=0
>>>>>>> -Wl,--defsym=realloc=0 -Wl,--defsym=__stack_chk_fail=0
>>>>>>> -Wl,--defsym=__stack_chk_fail_local=0 \
>>>>>>> '-Wl,-('
>>>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/dl-allobjs.os
>>>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/libc_pic.a
>>>>>>> -lgcc '-Wl,-)' -Wl,-Map,/export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
>>>>>>> rm -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map.o
>>>>>>> mv -f /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.mapT
>>>>>>> /export/users/hjl/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/librtld.map
>>>>>>>
>>>>>>>> ---
>>>>>>>> elf/Makefile | 11 ++++-------
>>>>>>>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/elf/Makefile b/elf/Makefile
>>>>>>>> index 0b4d78c874..299bf24b49 100644
>>>>>>>> --- a/elf/Makefile
>>>>>>>> +++ b/elf/Makefile
>>>>>>>> @@ -524,10 +524,6 @@ rtld-stubbed-symbols = \
>>>>>>>> malloc \
>>>>>>>> realloc \
>>>>>>>>
>>>>>>>> -# The GCC arguments that implement $(rtld-stubbed-symbols).
>>>>>>>> -rtld-stubbed-symbols-args = \
>>>>>>>> - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
>>>>>>>> -
>>>>>>>> ifeq ($(have-ssp),yes)
>>>>>>>> # rtld is not built with the stack protector, so these references will
>>>>>>>> # go away in the rebuilds.
>>>>>>>> @@ -536,9 +532,10 @@ endif
>>>>>>>>
>>>>>>>> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
>>>>>>>> @-rm -f $@T
>>>>>>>> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
>>>>>>>> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
>>>>>>>> - rm -f $@.o
>>>>>>>> + echo '$(patsubst %,.globl %;,$(rtld-stubbed-symbols)) $(patsubst %,%:,$(rtld-stubbed-symbols))' | \
>>>>>>>> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
>>>>>>>
>>>>>>> Please generate
>>>>>>>
>>>>>>> .globl symbol;
>>>>>>> symbol = 0;
>>>>>>>
>>>>>>> to make it closer to -Wl,--defsym=symbol=0.
>>>>>>
>>>>>> If symbol: and symbol = 0; work, isn't symbol: slightly better because
>>>>>> it looks more normal?
>>>>>> Or is the intention here using SHN_ABS to make it clear these symbols
>>>>>> are special?
>>>>>
>>>>> Generate machine independent assembly codes is tricky. We should
>>>>> make before and after the change as close as possible to avoid ANY
>>>>> surprises. BTW, you need to check HAVE_ASM_SET_DIRECTIVE
>>>>> to decide using ".set" vs "=".
>>>>>
>>>>> --
>>>>> H.J.
>>>>
>>>> Thanks for the tip. In this case I think the patch as is (sticking
>>>> with `foo:`, don't use `foo = 0` or set) is better.
>>>> foo: works everywhere.
>>>
>>> Ping. I think the patch as-is is better than the alternative approach
>>> using either `=` or `.set`.
>>
>> The patch breaks both arc-linux-gnuhf and hppa-linux-gnu with recent
>> ld.bfd 2.26, as below.
>>
>> We will need to sort these out.
The issue was in fact that hppa and arc uses no default asm line separators
(represented by ASM_LINE_SEP within code): hppa uses '!' while arc '`'.
By replacing echo with printf and issuing a new line explicit I see that
all targets build:
---
diff --git a/elf/Makefile b/elf/Makefile
index 5d666b1b0c..e5c04f682c 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -526,10 +526,6 @@ rtld-stubbed-symbols = \
malloc \
realloc \
-# The GCC arguments that implement $(rtld-stubbed-symbols).
-rtld-stubbed-symbols-args = \
- $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
-
ifeq ($(have-ssp),yes)
# rtld is not built with the stack protector, so these references will
# go away in the rebuilds.
@@ -538,9 +534,10 @@ endif
$(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
@-rm -f $@T
- $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
- '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
- rm -f $@.o
+ printf '$(patsubst %,.globl %;\n,$(rtld-stubbed-symbols)) $(patsubst %,% = 0;\n,$(rtld-stubbed-symbols))' | \
+ $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
+ $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
+ rm -f %@T.o $@.o
mv -f $@T $@
# For lld, skip preceding addresses and values before matching the archive and the member.
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD
2021-01-29 18:04 ` Adhemerval Zanella
@ 2021-01-29 19:28 ` Fangrui Song
2021-02-01 13:19 ` Adhemerval Zanella
2021-02-01 13:43 ` Florian Weimer
0 siblings, 2 replies; 42+ messages in thread
From: Fangrui Song @ 2021-01-29 19:28 UTC (permalink / raw)
To: libc-alpha, Adhemerval Zanella; +Cc: H.J. Lu, Fangrui Song
The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
fetched. This trick is used to avoid multiple definition errors which
would happen as a chain result:
dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
__libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
free fetches libc_pic.a(malloc.os)
libc_pic.a(malloc.os) has an undefined __libc_message
__libc_message fetches libc_pic.a(libc_fatal.os)
libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
>>> defined at dl-fxstatat64.c
>>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
>>> defined at libc_fatal.c
>>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
LLD processes --defsym after all input files, so this trick does not
suppress multiple definition errors with LLD. Split the step into two
and use an object file to make the intention more obvious and make LLD
work.
This is conceptually more appropriate because --defsym defines a SHN_ABS
symbol while a normal definition is relative to the image base.
See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
for discussions about the --defsym semantics.
This commit is available on https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld
---
elf/Makefile | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/elf/Makefile b/elf/Makefile
index 5d666b1b0c..03e4034cc7 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -526,10 +526,6 @@ rtld-stubbed-symbols = \
malloc \
realloc \
-# The GCC arguments that implement $(rtld-stubbed-symbols).
-rtld-stubbed-symbols-args = \
- $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
-
ifeq ($(have-ssp),yes)
# rtld is not built with the stack protector, so these references will
# go away in the rebuilds.
@@ -538,9 +534,10 @@ endif
$(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
@-rm -f $@T
- $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
- '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
- rm -f $@.o
+ printf '$(patsubst %,.globl %\n,$(rtld-stubbed-symbols)) $(patsubst %,%:\n,$(rtld-stubbed-symbols))' | \
+ $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
+ $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
+ rm -f %@T.o $@.o
mv -f $@T $@
# For lld, skip preceding addresses and values before matching the archive and the member.
--
2.30.0.365.g02bc693789-goog
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD
2021-01-29 19:28 ` [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD Fangrui Song
@ 2021-02-01 13:19 ` Adhemerval Zanella
2021-02-01 13:45 ` H.J. Lu
2021-02-01 13:43 ` Florian Weimer
1 sibling, 1 reply; 42+ messages in thread
From: Adhemerval Zanella @ 2021-02-01 13:19 UTC (permalink / raw)
To: Fangrui Song, libc-alpha
On 29/01/2021 16:28, Fangrui Song wrote:
> The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> fetched. This trick is used to avoid multiple definition errors which
> would happen as a chain result:
>
> dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> free fetches libc_pic.a(malloc.os)
> libc_pic.a(malloc.os) has an undefined __libc_message
> __libc_message fetches libc_pic.a(libc_fatal.os)
>
> libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> >>> defined at dl-fxstatat64.c
> >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> >>> defined at libc_fatal.c
> >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
>
> LLD processes --defsym after all input files, so this trick does not
> suppress multiple definition errors with LLD. Split the step into two
> and use an object file to make the intention more obvious and make LLD
> work.
>
> This is conceptually more appropriate because --defsym defines a SHN_ABS
> symbol while a normal definition is relative to the image base.
>
> See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
> for discussions about the --defsym semantics.
>
> This commit is available on https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld
> ---
> elf/Makefile | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/elf/Makefile b/elf/Makefile
> index 5d666b1b0c..03e4034cc7 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -526,10 +526,6 @@ rtld-stubbed-symbols = \
> malloc \
> realloc \
>
> -# The GCC arguments that implement $(rtld-stubbed-symbols).
> -rtld-stubbed-symbols-args = \
> - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> -
> ifeq ($(have-ssp),yes)
> # rtld is not built with the stack protector, so these references will
> # go away in the rebuilds.
> @@ -538,9 +534,10 @@ endif
>
> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> @-rm -f $@T
> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> - rm -f $@.o
> + printf '$(patsubst %,.globl %\n,$(rtld-stubbed-symbols)) $(patsubst %,%:\n,$(rtld-stubbed-symbols))' | \
> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> + $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> + rm -f %@T.o $@.o
> mv -f $@T $@
>
> # For lld, skip preceding addresses and values before matching the archive and the member.
Looks ok, I haven't see any build issue. The '=' seems unrequired, although '='
seems to work on all supported architectures (HAVE_ASM_SET_DIRECTIVE does not
seem to be necessary to handle here).
It is ok for 2.34 from my side. H.J, do you see any issues of not setting the
symbol to '0'?
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD
2021-01-29 19:28 ` [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD Fangrui Song
2021-02-01 13:19 ` Adhemerval Zanella
@ 2021-02-01 13:43 ` Florian Weimer
1 sibling, 0 replies; 42+ messages in thread
From: Florian Weimer @ 2021-02-01 13:43 UTC (permalink / raw)
To: Fangrui Song via Libc-alpha; +Cc: Adhemerval Zanella, Fangrui Song
* Fangrui Song via Libc-alpha:
> $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> @-rm -f $@T
> - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> - rm -f $@.o
> + printf '$(patsubst %,.globl %\n,$(rtld-stubbed-symbols)) $(patsubst %,%:\n,$(rtld-stubbed-symbols))' | \
> + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> + $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> + rm -f %@T.o $@.o
> mv -f $@T $@
It may be a little bit cleaner to replace the shell/make mix with just
shell, like (untested):
for symbol in $(rtld-stubbed-symbols) ; do \
echo ".globl $$symbol" ; \
echo "$$symbol:" ; \
done | $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD
2021-02-01 13:19 ` Adhemerval Zanella
@ 2021-02-01 13:45 ` H.J. Lu
0 siblings, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2021-02-01 13:45 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: Fangrui Song, GNU C Library
On Mon, Feb 1, 2021 at 5:19 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 29/01/2021 16:28, Fangrui Song wrote:
> > The existing code specifies -Wl,--defsym=malloc=0 and other malloc.os
> > definitions before libc_pic.a so that libc_pic.a(malloc.os) is not
> > fetched. This trick is used to avoid multiple definition errors which
> > would happen as a chain result:
> >
> > dl-allobjs.os has an undefined __libc_scratch_buffer_set_array_size
> > __libc_scratch_buffer_set_array_size fetches libc_pic.a(scratch_buffer_set_array_size.os)
> > libc_pic.a(scratch_buffer_set_array_size.os) has an undefined free
> > free fetches libc_pic.a(malloc.os)
> > libc_pic.a(malloc.os) has an undefined __libc_message
> > __libc_message fetches libc_pic.a(libc_fatal.os)
> >
> > libc_fatal.os will cause a multiple definition error (__GI___libc_fatal)
> > >>> defined at dl-fxstatat64.c
> > >>> /tmp/p/glibc/Release/elf/dl-allobjs.os:(__GI___libc_fatal)
> > >>> defined at libc_fatal.c
> > >>> libc_fatal.os:(.text+0x240) in archive /tmp/p/glibc/Release/libc_pic.a
> >
> > LLD processes --defsym after all input files, so this trick does not
> > suppress multiple definition errors with LLD. Split the step into two
> > and use an object file to make the intention more obvious and make LLD
> > work.
> >
> > This is conceptually more appropriate because --defsym defines a SHN_ABS
> > symbol while a normal definition is relative to the image base.
> >
> > See https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html
> > for discussions about the --defsym semantics.
> >
> > This commit is available on https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/maskray/lld
> > ---
> > elf/Makefile | 11 ++++-------
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/elf/Makefile b/elf/Makefile
> > index 5d666b1b0c..03e4034cc7 100644
> > --- a/elf/Makefile
> > +++ b/elf/Makefile
> > @@ -526,10 +526,6 @@ rtld-stubbed-symbols = \
> > malloc \
> > realloc \
> >
> > -# The GCC arguments that implement $(rtld-stubbed-symbols).
> > -rtld-stubbed-symbols-args = \
> > - $(patsubst %,-Wl$(comma)--defsym=%=0, $(rtld-stubbed-symbols))
> > -
> > ifeq ($(have-ssp),yes)
> > # rtld is not built with the stack protector, so these references will
> > # go away in the rebuilds.
> > @@ -538,9 +534,10 @@ endif
> >
> > $(objpfx)librtld.map: $(objpfx)dl-allobjs.os $(common-objpfx)libc_pic.a
> > @-rm -f $@T
> > - $(reloc-link) -o $@.o $(rtld-stubbed-symbols-args) \
> > - '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > - rm -f $@.o
> > + printf '$(patsubst %,.globl %\n,$(rtld-stubbed-symbols)) $(patsubst %,%:\n,$(rtld-stubbed-symbols))' | \
> > + $(CC) -o $@T.o $(ASFLAGS) -c -x assembler -
> > + $(reloc-link) -o $@.o $@T.o '-Wl,-(' $^ -lgcc '-Wl,-)' -Wl,-Map,$@T
> > + rm -f %@T.o $@.o
> > mv -f $@T $@
> >
> > # For lld, skip preceding addresses and values before matching the archive and the member.
>
> Looks ok, I haven't see any build issue. The '=' seems unrequired, although '='
> seems to work on all supported architectures (HAVE_ASM_SET_DIRECTIVE does not
> seem to be necessary to handle here).
>
> It is ok for 2.34 from my side. H.J, do you see any issues of not setting the
> symbol to '0'?
LGTM.
Thanks.
--
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2021-02-01 13:46 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-28 19:48 [PATCH 0/3] Make glibc build with LLD Fangrui Song
2020-12-28 19:48 ` [PATCH 1/3] configure: Allow LD to be a linker other than GNU ld and gold Fangrui Song
2020-12-28 20:46 ` H.J. Lu
2020-12-28 21:15 ` [PATCH 1/3] configure: Allow LD to be LLD 9.0.0 or above " Fangrui Song
2020-12-28 19:48 ` [PATCH 2/3] elf: Replace a --defsym trick with an object file to be compatible with lld Fangrui Song
2021-01-11 20:06 ` Fāng-ruì Sòng
2021-01-18 22:08 ` Fāng-ruì Sòng
2021-01-19 0:03 ` H.J. Lu
2021-01-19 8:50 ` Fāng-ruì Sòng
2021-01-19 12:30 ` H.J. Lu
2021-01-20 18:51 ` Fāng-ruì Sòng
2021-01-28 1:03 ` Fāng-ruì Sòng
2021-01-29 14:38 ` Adhemerval Zanella
2021-01-29 15:29 ` H.J. Lu
2021-01-29 18:04 ` Adhemerval Zanella
2021-01-29 19:28 ` [PATCH v2] elf: Replace a --defsym trick with an object file to be compatible with LLD Fangrui Song
2021-02-01 13:19 ` Adhemerval Zanella
2021-02-01 13:45 ` H.J. Lu
2021-02-01 13:43 ` Florian Weimer
2020-12-28 19:48 ` [PATCH 3/3] install: Replace scripts/output-format.sed with objdump -f [BZ #26559] Fangrui Song
2021-01-08 19:38 ` Adhemerval Zanella
2021-01-12 11:20 ` Florian Weimer
2021-01-12 12:00 ` Adhemerval Zanella
2021-01-12 17:46 ` Fāng-ruì Sòng
2021-01-12 11:32 ` Andreas Schwab
2021-01-12 11:58 ` Florian Weimer
2020-12-28 21:11 ` [PATCH 0/3] Make glibc build with LLD H.J. Lu
2020-12-28 21:45 ` Fangrui Song
2020-12-28 21:49 ` H.J. Lu
2020-12-28 22:54 ` H.J. Lu
2021-01-05 23:03 ` Fāng-ruì Sòng
2021-01-05 23:33 ` H.J. Lu
2021-01-05 23:41 ` Fāng-ruì Sòng
2021-01-05 23:51 ` H.J. Lu
2021-01-06 0:50 ` Fāng-ruì Sòng
2021-01-06 1:43 ` H.J. Lu
2021-01-06 2:00 ` Fāng-ruì Sòng
2021-01-06 2:14 ` H.J. Lu
2021-01-05 22:57 ` Fāng-ruì Sòng
2021-01-08 5:04 ` Fāng-ruì Sòng
2021-01-08 17:09 ` H.J. Lu
2021-01-08 18:04 ` Fāng-ruì Sòng
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).