check_memcpy test added in r254959 fails on some configurations due to
memcpy() calls inserted by Clang. Try harder to avoid them by using
internal_memcpy() where applicable.
llvm-svn: 255287
On OS X, for weak function (that user can override by providing their own implementation in the main binary), we need extern `"C" SANITIZER_INTERFACE_ATTRIBUTE SANITIZER_WEAK_ATTRIBUTE NOINLINE`.
Fixes a broken test case on OS X, java_symbolization.cc, which uses a weak function __tsan_symbolize_external.
Differential Revision: http://reviews.llvm.org/D14907
llvm-svn: 254298
Return a linked list of AddressInfo objects, instead of using an array of
these objects as an output parameter. This simplifies the code in callers
of this function (especially TSan).
Fix a few memory leaks from internal allocator, when the returned
AddressInfo objects were not properly cleared.
llvm-svn: 223145
# Make DataInfo (describing a global) a member of ReportLocation
to avoid unnecessary copies and allocations.
# Introduce a constructor and a factory method, so that
all structure users don't have to go to internal allocator directly.
# Remove unused fields (file/line).
No functionality change.
llvm-svn: 221302
AddressInfo contains the results of symbolization. Store this object
directly in the symbolized stack, instead of copying data around and
making unnecessary memory allocations.
No functionality change.
llvm-svn: 221294
This commit changes the place where TSan runtime turns full path
to binary or shared library into its basename
(/usr/foo/mybinary -> mybinary). Instead of doing it as early as possible
(when we obtained the full path from the symbolizer), we now do it as
late as possible (right before printing the error report).
This seems like a right thing to do - stripping to basename is a detail
of report formatting implementation, and should belong there. Also, we
might need the full path at some point - for example, to match the
suppressions.
llvm-svn: 221225
We may as well just use Symbolizer::GetOrInit() in all the cases.
Don't call Symbolizer::Get() early in tools initialization: these days
it doesn't do any important setup work, and we may as well create the
symbolizer the first time it's actually needed.
llvm-svn: 217558
I still don't know what is causing our bootstrapped LTO buildbots to fail,
but llvm r194701 seems to be OK and I can't imagine that these changes could
cause the problem.
llvm-svn: 194790
Apple's bootstrapped LTO builds have been failing, and these changes (along
with llvm 194701) are the only things on the blamelist. I will either reapply
these changes or help debug the problem, depending on whether this fixes the
buildbots.
llvm-svn: 194779
Summary:
TSan and MSan need to know if interceptor was called by the
user code or by the symbolizer and use pre- and post-symbolization hooks
for that. Make Symbolizer class responsible for calling these hooks instead.
This would ensure the hooks are only called when necessary (during
in-process symbolization, they are not needed for out-of-process) and
save specific sanitizers from tracing all places in the code where symbolization
will be performed.
Reviewers: eugenis, dvyukov
Reviewed By: eugenis
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2067
llvm-svn: 193807
This moves away from creating the symbolizer object and initializing the
external symbolizer as separate steps. Those steps now always take place
together.
Sanitizers with a legacy requirement to specify their own symbolizer path
should use InitSymbolizer to initialize the symbolizer with the desired
path, and GetSymbolizer to access the symbolizer. Sanitizers with no
such requirement (e.g. UBSan) can use GetOrInitSymbolizer with no need for
initialization.
The symbolizer interface has been made thread-safe (as far as I can
tell) by protecting its member functions with mutexes.
Finally, the symbolizer interface no longer relies on weak externals, the
introduction of which was probably a mistake on my part.
Differential Revision: http://llvm-reviews.chandlerc.com/D1985
llvm-svn: 193448