Closed GoogleCodeExporter closed 9 years ago
I am not sure if the driver should parse the linker flags. I'd prefer it not to
do that.
Original comment by konstant...@gmail.com
on 22 Sep 2014 at 5:33
How do you propose to resolve this?
The idea is that a user needs to add -fsanitize=foo to all driver invocations
and that will magically do the right thing. It does not work in this case.
Original comment by dvyu...@google.com
on 22 Sep 2014 at 5:46
Isn't it easier to just not pass -fsanitize=address when you invoke ld with
"-relocatable" option? We may state that "-fsanitize=address" should be passed
if:
1) you're compiling the source code into object file
2) you're linking an executable.
Original comment by samso...@google.com
on 22 Sep 2014 at 6:12
This level of control is generally impossible in an arbitrary C/C++ project out
there. One better pray that the build system at least properly supports
CC/CFLAGS/LDFLAGS and pass it to all invocations of a compiler.
We don't link asan runtime into dynamic libraries for this reason. But you can
easily say -- just don't pass -fsanitize=foo when linking dynamic libraries.
It's easy to say but usually near impossible to do...
Original comment by dvyu...@google.com
on 22 Sep 2014 at 6:25
I haven't seen lots of C++ projects, but I suspect that they don't usually
build objects with "-Wl,-r". On the contrary (correct me if I'm wrong), I guess
that Go build system somehow does it explicitly.
Original comment by samso...@google.com
on 22 Sep 2014 at 6:55
All compiler/linker flags are added explicitly by build systems.
If you feel adventurous, you can check out gcc and try to modify its build
system to not pass -fsanitize=address with it links dynamic libraries.
FWIW I've mailed https://codereview.appspot.com/142470043 to do this in Go, but
that fixes only the concrete case.
Original comment by dvyu...@google.com
on 23 Sep 2014 at 4:09
We probably should not link asan runtime with -nostdlib, regardless of -Wl,-r.
Original comment by euge...@google.com
on 23 Sep 2014 at 9:39
-nostdlib is a driver flag and it is a great idea to look at it.
Looking at -Wl,* is bad
Original comment by konstant...@gmail.com
on 23 Sep 2014 at 4:28
BTW at the moment if user passes -nostdlib we link in static ASan runtime, but
don't add -lpthread, -lrt etc. We can change this to just ignore
-fsanitize=address in this case.
Original comment by samso...@google.com
on 23 Sep 2014 at 7:17
Yes, this is exactly what we should do. ASan runtime here is exactly an
"stdlib" the same as pthread, rt, c, gcc.
Without -nostdlib (and without asan) the build in #1 will still break in the
same way due to symbols from other standard libraries.
Original comment by euge...@google.com
on 24 Sep 2014 at 9:08
Well, ASan build with -nostdlib work, if user provides his own versions of
libpthread/librt/libc etc. in the command line. But probably dropping ASan
runtime from linker invocation is still the right thing to do. I will implement
this.
Original comment by samso...@google.com
on 25 Sep 2014 at 2:57
> This level of control is generally impossible in an arbitrary C/C++ project
out
> there. One better pray that the build system at least properly supports
> CC/CFLAGS/LDFLAGS and pass it to all invocations of a compiler.
FYI we worked around this by replacing gcc/g++ with shell scripts that would
force-enable sanitizer flags. This is super-ugly but was proved to be very
efficient.
Original comment by tetra2...@gmail.com
on 25 Sep 2014 at 8:54
We did wrappers a lot as well. It's probably the most practical solution.
But it does not look like something that end user must be doing.
Original comment by dvyu...@google.com
on 25 Sep 2014 at 3:56
FWIW, I've submitted r218541, so that now sanitizer runtimes won't be passed to
the linker if user provides -nostdlib flag. Please reopen if you think we need
to smth. else here.
Original comment by samso...@google.com
on 26 Sep 2014 at 9:33
FTR, r218541 was reverted in r220455 - there are legitimate use cases when user
want to pass -nostdlib and still link with ASan runtime (e.g. if one links in
its own implementation of standard libraries). See review threads for more
discussion on that.
Original comment by samso...@google.com
on 13 Mar 2015 at 10:11
gcc still has the old behavior (i.e. -nostdlib negates -fsanitize=address).
This is causing a bit of trouble when compiling ASan-instrumented glibc.
Alexey, could you please fix this in gcc as well?
Original comment by earth...@chromium.org
on 30 Mar 2015 at 2:47
Can you open a GCC bug and describe glibc use case there? Maybe someone (e.g.
Roland) would want to help us with that change there.
Original comment by samso...@google.com
on 30 Mar 2015 at 8:31
Adding Project:AddressSanitizer as part of GitHub migration.
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:14
Original issue reported on code.google.com by
dvyu...@google.com
on 22 Sep 2014 at 6:11