This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use libbacktrace as libsanitizer's symbolizer

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 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. doesn't export the backtrace_* symbols.

Or, of course, if libsanitizer chooses not to use the convenience libraries
as is, but instead have in 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]