Collect info about all dynamic libraries in the process (name, base, size).
Determine to what dyn lib the address relates, route request to addr2line instance for the lib.
llvm-svn: 156759
Races on stack of main thread are problematic for COMPAT mapping, because it's not 1-to-1 and race addr is not properly mapped from shadow back to application memory.
Update output tests to race heap memory.
llvm-svn: 156758
In the current implementation AsanThread::GetFrameNameByAddr scans the
stack for a magic guard value to locate base address of the stack
frame. This is not reliable, especially on ARM, where the code that
stores this magic value has to construct it in a register from two
small intermediates; this register can then end up stored in a random
stack location in the prologue of another function.
With this change, GetFrameNameByAddr scans the shadow memory for the
signature of a left stack redzone instead. It is now possible to
remove the magic from the instrumentation pass for additional
performance gain. We keep it there for now just to make sure the new
algorithm does not fail in some corner case.
llvm-svn: 156710
Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm
Status:
The tool is known to work on large real-life applications, but still has quite a few rough edges.
Nothing is guaranteed yet.
The tool works on x86_64 Linux.
Support for 64-bit MacOS 10.7+ is planned for late 2012.
Support for 32-bit OSes is doable, but problematic and not yet planed.
Further commits coming:
- tests
- makefiles
- documentation
- clang driver patch
The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/
by Dmitry Vyukov and Kostya Serebryany with contributions from
Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov.
llvm-svn: 156542
Until we work out the solution for http://code.google.com/p/address-sanitizer/issues/detail?id=65 we'd better not allow
the clients to override AddressSanitizer's signal handler.
The second part of r154390 (removing the sighandler-related tests) is not reverted, because those tests were broken
and didn't test anything.
llvm-svn: 154803
From now on we allow the clients to override signal handlers set by ASan, but print a warning in such a case.
Remove the tests for signal() and sigaction(), because they made little sense even without this change.
llvm-svn: 154390
Some high-level notes:
1) An explicit goal is to support building compiler-rt as a subproject
build, checked out into the projects/compiler-rt directory. There are
many other possible ways of building the code here, but this is
optimized for development on LLVM/Clang/compiler-rt, and incremental
trial and testing of the toolchain.
2) The current support is targeted at Linux. I would love to see this
generalized to other platforms, but for the sake of simplicity in
testing, I'm focusing here first.
Much of this patch was paired with Manuel, and I credit him with the
majority of the work here.
Some important caveats that I'll be working on in subsequent patches:
1) This uses the host compiler rather than using the just-built-clang.
2) Currently only x86 is supported.
3) Currently, none of the tests are built or run.
4) Uses CMake's builtin globbing which doesn't update correctly.
5) This is still turned off from LLVM's CMake build until these issues
are addressed
llvm-svn: 154060
I cannot build any part of this successfully on either Linux or Darwin,
and the replacement is worlds simpler by requiring that this be built as
a subproject of LLVM. If this breaks you for any reason, please let me
know, and let me know what your use case is.
llvm-svn: 154059
Kostya Serebryany