[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of -fsanitize=address still leads to unresolved symbols on gcc
From: |
Alex Ameen |
Subject: |
Re: Use of -fsanitize=address still leads to unresolved symbols on gcc |
Date: |
Sat, 30 Apr 2022 12:58:13 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
Thanks for reporting this. I haven't recreated the issue yet; but for
the purposes of this message I'll assume that this is an issue that
isn't caused by quirks in your environment.
Let me check my understanding, but I think I understand the issue.
Conventionally `-fsanitize=address' "just works" with GCC because
`libgcc_s.so', `libasan.so', and similar libraries can be automatically
added using "flag specs".
Because `libtool' uses `-nostdlib' and tries to explicitly handle any
"flag specs" ( such as `-fsanitize=address' ) that are encountered, it
needs to stay updated in lock-step with changes to GCC's specs, or
`libtool' needs to be able to parse and replicate the behavior of
`{gcc,g++} -dumpspec' definitions as if `-nostdlib' had not been indicated.
In short `libtool' fails to replicate the spec for `-fsanitize=address',
because of conflicts with the added `-nostdlib' flag.
Two possible solutions may be:
1. If `libtool' is going to silently add `-nostlib', it needs to be sure
it accounts for flag specs such as `-fsanitize=address'.
2. `libtool' should trust the underlying compiler/link-editor to select
the correct standard libraries, and only use `-nostdlib' when the user
explicitly requests it.
If my understanding is correct, and the potential solutions would work;
I personally lean towards (2), since I don't immediately see a good
rationale for why `libtool' should disable the compiler/link-editor's
preferred libraries.
Just for clarity, I do understand the purpose of `-nostlib' and I know
that it's incredibly useful; but using it silently by default foists a
huge responsibility onto `libtool' to avoid common use cases like the
one you've got here.
On 4/28/22 05:35, Jan Engelhardt wrote:
libtool (2.4.7, and earlier versions) pass -nostdlib to the linker
command. This would seem to cause ASAN/UBSAN libraries not to be
linked, and a situation of unresolved symbols arises.
Commit a5c6466528c060cc4660ad0319c00740db0e42ba certainly feels right
(hence the "earlier versions"), but apparently didn't do anything
with regards to gcc.
gcc-11.2.1/binutils 2.38.20220411-4 is in use.
$ echo 'int blah() { return 42; }' >foo.cpp
$ ./libtool --tag=CXX --mode=compile g++ -fsanitize=address -c foo.cpp
libtool: compile: g++ -fsanitize=address -c foo.cpp -fPIC -DPIC -o .libs/foo.o
$ ./libtool --tag=CXX --mode=link g++ -fsanitize=address -rpath /usr/lib64 -o
libfoo.la foo.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-suse-linux/11/crtbeginS.o .libs/foo.o
-L/usr/lib64/gcc/x86_64-suse-linux/11
-L/usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/11/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/11/crtendS.o
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../lib64/crtn.o
-fsanitize=address -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
$ ldd -r .libs/libfoo.so.0
linux-vdso.so.1 (0x00007ffeb1dc1000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f6b0719d000)
libm.so.6 => /lib64/libm.so.6 (0x00007f6b070b5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6b06e86000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6b06e63000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6b073e5000)
undefined symbol: __asan_init (.libs/libfoo.so.0)
undefined symbol: __asan_version_mismatch_check_v8 (.libs/libfoo.so.0)