I have clang and lld 10.0, ld.bfd 2.34.50.20200506, ld.gold 1.16 / 2.34.50.20200506 and i.c: #include <stdio.h> #include <stdbool.h> int main() { bool b = 99; printf("a %i\n", b); } The question is, why only the last call emits a warning: $ clang -fsanitize=address -fuse-ld=bfd -o i i.c $ clang -fsanitize=address -fuse-ld=lld -o i i.c $ clang -fsanitize=address -fuse-ld=gold -o i i.c /usr/local/bin/ld.gold: warning: Cannot export local symbol '__asan_extra_spill_ area' See also https://sourceware.org/bugzilla/show_bug.cgi?id=25940.
(In reply to dilyan.palauzov@aegee.org from comment #0) > I have clang and lld 10.0, ld.bfd 2.34.50.20200506, ld.gold 1.16 / > 2.34.50.20200506 and i.c: > > #include <stdio.h> > #include <stdbool.h> > > int main() { > bool b = 99; > printf("a %i\n", b); > } > > The question is, why only the last call emits a warning: > $ clang -fsanitize=address -fuse-ld=bfd -o i i.c > $ clang -fsanitize=address -fuse-ld=lld -o i i.c > $ clang -fsanitize=address -fuse-ld=gold -o i i.c > /usr/local/bin/ld.gold: warning: Cannot export local symbol > '__asan_extra_spill_ > area' > > See also https://sourceware.org/bugzilla/show_bug.cgi?id=25940. Do you have compiler-rt installed?
I think I have it, at least there are some libclang_rt files.
It works with my gold on users/hjl/gold/x86 branch at https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/gold/x86
Created attachment 12529 [details] Output of `clang -fsanitize=address -c -o i.o i.c`
Created attachment 12530 [details] Output of `clang -v -fuse-ld=bfd -fsanitize=address i.o`
Created attachment 12531 [details] Output of `clang -v -fuse-ld=lld -fsanitize=address i.o`
Created attachment 12532 [details] Output of `clang -v -fsanitize=address -fuse-ld=gold -Wl,-debug,all i.o`
Switching to the alternative gold (411ae86dfcf9da4) has not helped. The outputs of clang -fsanitize=address -c -o i.o i.c clang -v -fuse-ld=bfd -fsanitize=address i.o &> bfd.txt clang -v -fuse-ld=lld -fsanitize=address i.o &> lld.txt clang -v -Wl,--debug,all -fuse-ld=gold -fsanitize=address i.o &> gold.txt are attached.
"/usr/bin/ld.gold" --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crt1.o /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-redhat-linux/10 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64 -L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib --whole-archive /usr/lib64/clang/10.0.0/lib/linux/libclang_rt.asan-x86_64.a --no-whole-archive --export-dynamic /tmp/x-ef8058.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-redhat-linux/10/crtend.o /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crtn.o works for me on Fedora/32.
Does it also work with the attached i.o as input?
(In reply to dilyan.palauzov@aegee.org from comment #10) > Does it also work with the attached i.o as input? [hjl@gnu-cfl-2 tmp]$ clang -fsanitize=address -fuse-ld=gold i.o [hjl@gnu-cfl-2 tmp]$ ./a.out a 1 [hjl@gnu-cfl-2 tmp]$ clang -fsanitize=address -fuse-ld=lld i.o [hjl@gnu-cfl-2 tmp]$ ./a.out a 1 [hjl@gnu-cfl-2 tmp]$ clang -fsanitize=address -fuse-ld=bfd i.o [hjl@gnu-cfl-2 tmp]$ ./a.out a 1 [hjl@gnu-cfl-2 tmp]$
Calling ./chroot-gold-asan from https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz (39MB), which is the same as calling chroot . ./ld.gold -Llib64 --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o ./crtn.o prints: ./ld.gold: warning: Cannot export local symbol '__asan_extra_spill_area' ld.gold is from binutils-gdb.master, commit 607b483327fdfc75fb193870b3c4e7445ce3f64d.
Is this now reproducible?
(In reply to dilyan.palauzov@aegee.org from comment #13) > Is this now reproducible? I have [hjl@gnu-4 linux]$ readelf -sW libclang_rt.asan-x86_64.a | grep __asan_extra_spill_area 185: 0000000000001dc4 0 NOTYPE LOCAL HIDDEN 6 .annobin___asan_extra_spill_area.start 186: 0000000000001e0d 0 NOTYPE LOCAL HIDDEN 6 .annobin___asan_extra_spill_area.end 385: 0000000000001dd0 61 FUNC GLOBAL HIDDEN 6 __asan_extra_spill_area 7: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __asan_extra_spill_area [hjl@gnu-4 tmp]$ clang -fsanitize=address -fuse-ld=gold i.o [hjl@gnu-4 tmp]$ readelf -sW a.out| grep __asan_extra_spill_area 4269: 00000000004c73c4 0 NOTYPE LOCAL HIDDEN 13 .annobin___asan_extra_spill_area.start 4270: 00000000004c740d 0 NOTYPE LOCAL HIDDEN 13 .annobin___asan_extra_spill_area.end 7505: 00000000004c73d0 61 FUNC LOCAL HIDDEN 13 __asan_extra_spill_area [hjl@gnu-4 tmp]$ What do you get on __asan_extra_spill_area?
My libclang_rt.asan-x86_64.a is included in https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz. $ readelf -sW libclang_rt.asan-x86_64.a |grep _asan_extra_spill_area 281: 0000000000000000 61 FUNC GLOBAL HIDDEN 172 __asan_extra_spill_area 12: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __asan_extra_spill_area $ clang -fsanitize=address -fuse-ld=gold i.o $ readelf -sW a.out |grep _asan_extra_spill_area 1357: 00000000004c5b20 61 FUNC LOCAL HIDDEN 12 __asan_extra_spill_area
(In reply to dilyan.palauzov@aegee.org from comment #12) > Calling ./chroot-gold-asan from > https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz (39MB), which is the > same as calling > > chroot . ./ld.gold -Llib64 --hash-style=both --eh-frame-hdr -m elf_x86_64 > -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out ./crt1.o ./crti.o > ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a --no-whole-archive > --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o --no-as-needed -lpthread > -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed > -lgcc_s --no-as-needed ./crtend.o ./crtn.o > > prints: > ./ld.gold: warning: Cannot export local symbol '__asan_extra_spill_area' > > ld.gold is from binutils-gdb.master, commit > 607b483327fdfc75fb193870b3c4e7445ce3f64d. Do you have __asan_extra_spill_area in ./libclang_rt.asan-x86_64.a.syms?
libclang_rt.asan-x86_64.a.syms, included in https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz, does not contain “spill".
(In reply to dilyan.palauzov@aegee.org from comment #17) > libclang_rt.asan-x86_64.a.syms, included in > https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz, does not contain > “spill". I got [hjl@gnu-cfl-2 pr-gold-25975]$ ld.bfd -Llib64 --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o ./crtn.o [hjl@gnu-cfl-2 pr-gold-25975]$ ld.gold -Llib64 --hash-style=both --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o ./crtn.o ld.gold: warning: Cannot export local symbol '__asan_extra_spill_area' [hjl@gnu-cfl-2 pr-gold-25975]$ It looks like a gold --dynamic-list bug.
(In reply to H.J. Lu from comment #18) > (In reply to dilyan.palauzov@aegee.org from comment #17) > > libclang_rt.asan-x86_64.a.syms, included in > > https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz, does not contain > > “spill". > > I got > > > [hjl@gnu-cfl-2 pr-gold-25975]$ ld.bfd -Llib64 --hash-style=both > --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out > ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a > --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o > --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s > --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o > ./crtn.o > [hjl@gnu-cfl-2 pr-gold-25975]$ ld.gold -Llib64 --hash-style=both > --eh-frame-hdr -m elf_x86_64 -dynamic-linker ./ld-linux-x86-64.so.2 -o a.out > ./crt1.o ./crti.o ./crtbegin.o --whole-archive ./libclang_rt.asan-x86_64.a > --no-whole-archive --dynamic-list=./libclang_rt.asan-x86_64.a.syms i.o > --no-as-needed -lpthread -lrt -lm -ldl -lgcc --as-needed -lgcc_s > --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o > ./crtn.o > ld.gold: warning: Cannot export local symbol '__asan_extra_spill_area' > [hjl@gnu-cfl-2 pr-gold-25975]$ > > It looks like a gold --dynamic-list bug. The problem is _Unwind_RaiseException; __asan_*; ^^^^^^^^^^^^^ This matches __asan_extra_spill_area.
// If the symbol was forced dynamic in a --dynamic-list file // or an --export-dynamic-symbol option, add it. if (!this->is_from_dynobj() && (parameters->options().in_dynamic_list(this->name()) || parameters->options().is_export_dynamic_symbol(this->name()))) { if (!this->is_forced_local()) return true; gold_warning(_("Cannot export local symbol '%s'"), this->demangled_name().c_str()); return false; } I don't think the warning is necessary when it is a wild card match.
> Do you have __asan_extra_spill_area in ./libclang_rt.asan-x86_64.a.syms? If I do not have __asan_extra_spill_area in ./libclang_rt.asan-x86_64.a.syms does this mean, that clang/rt was self-compiled anyhow wrong?
(In reply to H.J. Lu from comment #20) > // If the symbol was forced dynamic in a --dynamic-list file > // or an --export-dynamic-symbol option, add it. > if (!this->is_from_dynobj() > && (parameters->options().in_dynamic_list(this->name()) > || parameters->options().is_export_dynamic_symbol(this->name()))) > { > if (!this->is_forced_local()) > return true; > gold_warning(_("Cannot export local symbol '%s'"), > this->demangled_name().c_str()); > return false; > } > > I don't think the warning is necessary when it is a wild card match. Agreed. clang -fsanitize=address uses --dynamic-list when libclang_rt.asan-x86_64.a.syms exists. This behavior has been there for a long time, since 3.3 (https://github.com/llvm/llvm-project/commit/f3e624ca73b007552554b31358f4abde9eb2d3b7 ). So the gold warning may be there for a long time as well. % readelf -Ws lib/clang/11.0.0/lib/linux/libclang_rt.asan-x86_64.a | grep __asan_extra_spill_area 251: 0000000000000000 48 FUNC GLOBAL HIDDEN 162 __asan_extra_spill_area 6: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __asan_extra_spill_area The spurious warning should just be deleted, along with msgid "Cannot export local symbol '%s'" in various .po files.
Can I delete https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz ?
(In reply to dilyan.palauzov@aegee.org from comment #23) > Can I delete https://mail.aegee.org/dpa/pr25975/pr-gold-25975.tar.xz ? Yes.
Guys, could you please summarize the thread? Is this warning safe to ignore? Is it going to be fixed?