On Tue, Nov 26, 2013 at 03:00:27PM +0400, Evgeniy Stepanov wrote:
> [plain text version]
>
> Tool-specific actions in the interceptors are disabled when we enter
> the symbolizer.
>
> What happens if user app links libbacktrace? An instrumented
> libbacktrace? Memory that is allocated internally in sanitizer runtime
Well, libbacktrace isn't an installed library, so it is unlikely they do.
Plus, we use shared libraries by default, and libbacktrace is then linked
directly into libasan.so.1 etc. Ideally we should use symbol versioning
to only export symbols we want to export and not others.
Given that libbacktrace is right now just a convenience library, supposedly
it might be worthwhile to build it with all symbols hidden, so that e.g.
libgo.so doesn't export the backtrace_* symbols.
Or, of course, if libsanitizer chooses not to use the convenience libraries
as is, but instead have in Makefile.am rules to compile (a subset of)
libbacktrace source files directly in libsanitizer/sanitizer_common, then
the symbols could be __sanitizer_backtrace_* rather than backtrace_*, thus no
chance of anybody overloading it, plus we could then just write another
implementation of libbacktrace/{alloc,mmap}.c using sanitizer_common's
allocator instead of the mmap using allocator libbacktrace has.
Then there would be no possibility (otherwise just low) somebody would
override it mistakenly with instrumented version thereof.
Jakub
