This is the first in a sequence of changes designed to eliminate the
libc dependency in sanitizer_common. The main motivation for these
changes is to be able to provide an alternative for the current
interceptor-based technique for instrumenting functions in libc.
In this new technique, we compile libc with instrumentation. This has
the potential advantages of being more accurate than interception and
reducing the amount of custom code required for each libc function.
As a side effect of this, we cannot depend on libc in the sanitizer
runtime due to mutual dependency issues.
This change disables the GCC stack protector, which introduces a libc
dependency and is enabled by default in Ubuntu.
Differential Revision: http://llvm-reviews.chandlerc.com/D755
llvm-svn: 181422
Move this function to sanitizer_common because LSan uses it too. Also, fix a bug
where the TLS range reported for main thread was off by the size of the thread
descriptor from libc (TSan doesn't care much, but for LSan it's critical).
llvm-svn: 181322
With this change, __internal_*stat always expect a "struct stat *" argument.
This avoids stat/stat64 caller-side confusion (sanitizer_common tests already
made this mistake), and allows the use of __internal_fstat() as a drop-in
replacement for libc's fstat().
llvm-svn: 181311
When building compiler-rt on Linux, the "which sw_vers" check fails and
writes an error message into the build log. Apparently on Solaris "which"
writes the error message to stdout, so that the current test won't even
work properly. As far as I know sw_vers always lives in /usr/bin, so just
check for it there instead of using "which".
llvm-svn: 180792
We now rely on the -mios-simulator-version-min option to identify the iOS
simulator target. I'm not sure if there's anything in compiler-rt where that
matters, but it's the right thing to do regardless.
llvm-svn: 180163
The fread / fwrite calls were happening for each timer. However, that could be
pretty expensive for a large number of timers. Instead, read and write the
timers in one call.
This gives ~10% speedup in compilation time.
llvm-svn: 179990
This change adds ASan runtime option "strict-init-order" (off by default)
that makes init-order checker bark if global initializer accesses any global from different
translation unit (even if the latter is already initialized). strict init-order checking
doesn't play well with, e.g. LLVM registration machineries, and causes issue
https://code.google.com/p/address-sanitizer/issues/detail?id=178.
llvm-svn: 179843
Sergey Matveev