2

As mentioned using -fsanitize=address during compilation or .so file creation will automatically link libasan.so library right ?

I am facing issue :-

==13640==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
xrun: *E,ELBERR: Error during elaboration (status 1), exiting.

I found the same issue and fix for the same here :- https://github.com/google/sanitizers/issues/796

Firstly i try to use -fsanitize=address -static-libasan flags to my gcc compiler and linker to created .so files. The created library file 'libsynsv.so' itself don't show the 'asan' library as its dependency with ldd libsynsv.so output.

/folder/san/client/src/main/cvip/asan/Release/verilog/../lib/libviputil.so: undefined symbol: __asan_option_detect_stack_use_after_return.

Is there any issue with my GCC command? Why my library was not linked to asan though i ran with -fsanitize-address.

yugr
  • 19,769
  • 3
  • 51
  • 96
santosh
  • 421
  • 1
  • 6
  • 14
  • Does this answer your question? [Asan : Issue with asan library loading](https://stackoverflow.com/questions/59853730/asan-issue-with-asan-library-loading) – yugr Jan 24 '20 at 10:32
  • I would like to know why libasan library is not linked though we provide the flag fsanitize-address – santosh Jan 24 '20 at 10:44
  • How do you know it's not linked? You explicitly asked for static linking of libasan, so it will not be a dependency for dynamic linker (showed by `ldd`), rather its code will be explicitly placed in the binary. – raspy Jan 24 '20 at 12:28

1 Answers1

-1

Is there any issue with my GCC command?

Yes: to properly work, address sanitizer must intercept every call to malloc. Thus you can not instrument a shared library with -fsanitize=address and load that library into main executable that is itself not instrumented.

The created library file 'libsynsv.so' itself don't show the 'asan' library as its dependency with ldd libsynsv.so output.

As @yugr said in comments, -static-libasan is ignored when linking a shared library.

Why my library was not linked to asan though i ran with -fsanitize-address.

Because linking asan runtime into a shared library is not sufficient to make address sanitizer work.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • So only providing '-fsanitize=address' during compilation (.c files) is enough.. No need to give it while creating .so files ? – santosh Jan 27 '20 at 06:00
  • "Thus you can not instrument a shared library with -fsanitize=address and load that library into main executable that is itself not instrumented" - you _can_ (and this is very important use-case). Howto and caveats are described on [wiki](https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso). Of course the OP should not be using `-static-libasan` in this case but I got lost trying to explain this to him. – yugr Jan 27 '20 at 13:29
  • "since you specified -static-libasan when linking it, a copy of parts of asan runtime (the used parts) is included in libsynsv.so" - this is incorrect, `-static-libasan` links libasan.a to main executable only (and exports them, the idea being that sanitized shared libraries will pick it from there). At least that's how it works on Clang (and GCC's support for `-static-libasan` is a joke). – yugr Jan 27 '20 at 13:34
  • 1
    @yugr I believe that both of your comments are wrong, but this isn't the place to discuss them. – Employed Russian Jan 27 '20 at 15:47
  • Thank you for your opinion, I've worked on this area of Asan for a year (e.g. fixing bugs in `-static-libasan` in GCC and implementing `-shared-libasan` in Clang) so I'm quite confident about my claims. And that's exactly the place to discuss them because you provide incorrect and misleading information about important and error-prone aspects of Asan. – yugr Jan 27 '20 at 19:49
  • @yugr 1. The wiki page you linked to talks about using address sanitizer runtime as a DSO. That is *not* what this question is about. 2. You say "-static-libasan links libasan.a to main executable only", but the OP links a DSO, *not* the main executable. – Employed Russian Jan 27 '20 at 19:55
  • 1. In GCC `-fsanitize=address` uses DSO by default (non-DSO case i.e. `-static-libasan` is not supported much there) so your comment ("you can not instrument a shared library with -fsanitize=address and load that library into main executable that is itself not instrumented") is very wrong there. If you explicitly specify that it relates to `-static-libasan` case _only_ I'll happily +1 the answer. – yugr Jan 27 '20 at 19:58
  • 2. I'm picking at words "since you specified -static-libasan when linking it, a copy of parts of asan runtime (the used parts) is included in libsynsv.so" and I insist that they are wrong - under `-static-libasan` Asan runtime is not linked when DSO is sanitized (it only gets linked when one links an executable). So in OPs case (linking `libsynsv.so`) parts of Asan runtime it will _not_ be included into .so and symbols will _not_ be defined. – yugr Jan 27 '20 at 20:01
  • @yugr So what you are saying is that `-static-libasan` is a no-op when `-shared` is in effect. I can believe that. I double-checked that this is the case, and will correct the answer shortly. – Employed Russian Jan 27 '20 at 22:42
  • The "you can not instrument a shared library with -fsanitize=address and load that library into main executable that is itself not instrumented" comment is still wrong (as explained in previous comment). – yugr Feb 11 '20 at 14:43