| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generalize StackDepot and create a new specialized instance of it to
efficiently (i.e. without duplicating stack trace data) store the
origin history tree.
This reduces memory usage for chained origins roughly by an order of
magnitude.
Most importantly, this new design allows us to put two limits on
stored history data (exposed in MSAN_OPTIONS) that help avoid
exponential growth in used memory on certain workloads.
See comments in lib/msan/msan_origin.h for more details.
llvm-svn: 209284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tests.
This change lets MSan rely on libcxx's own build system instead of manually
compiling its sources and setting up all the necessary compile flags. It would
also simplify compiling libcxx with another sanitizers (in particular, TSan).
The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or
MSan runtime library is changed. "clobber" step used in this patch works well
for me, but it's possible it would break for other configurations - will
watch the buildbots.
llvm-svn: 208451
|
|
|
|
| |
llvm-svn: 208303
|
|
|
|
|
|
|
|
|
| |
Format string parsing is disabled by default.
This is not expected to meaningfully change the tool behavior.
With this change, check_printf flag could be used to evaluate printf format
string parsing in MSan.
llvm-svn: 208295
|
|
|
|
|
|
| |
signals may be raised while thread is being destroyed
llvm-svn: 208250
|
|
|
|
| |
llvm-svn: 208207
|
|
|
|
| |
llvm-svn: 208195
|
|
|
|
|
|
| |
Makes __msan_print_shadow output much more readable, adds origin info.
llvm-svn: 207622
|
|
|
|
|
|
| |
StackDepot is not async-signal-safe; storing a new origin to it can deadlock.
llvm-svn: 206983
|
|
|
|
| |
llvm-svn: 206589
|
|
|
|
| |
llvm-svn: 206587
|
|
|
|
| |
llvm-svn: 206586
|
|
|
|
| |
llvm-svn: 206584
|
|
|
|
| |
llvm-svn: 206179
|
|
|
|
| |
llvm-svn: 206028
|
|
|
|
|
|
| |
This reduces .tbss from 109K down to almost nothing.
llvm-svn: 205618
|
|
|
|
|
|
|
| |
It does not do what it's name says, and what it actually does is hard to
describe, and is not useful at all.
llvm-svn: 205415
|
|
|
|
|
|
| |
An assert()-like function that checks that a memory range is fully initialized.
llvm-svn: 205413
|
|
|
|
| |
llvm-svn: 205412
|
|
|
|
| |
llvm-svn: 205410
|
|
|
|
| |
llvm-svn: 205192
|
|
|
|
|
|
|
|
| |
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
|
|
|
|
|
|
|
|
| |
These interceptors require deep unpoisoning of return values.
While at it, we do the same for all other pw/gr interceptors to
reduce dependency on libc implementation details.
llvm-svn: 205004
|
|
|
|
| |
llvm-svn: 205000
|
|
|
|
| |
llvm-svn: 204926
|
|
|
|
| |
llvm-svn: 204923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interceptors had code that after macro expansion ended up looking like
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("memalign")));
That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign
Both gcc and clang produce assembly that look like
__interceptor_memalign:
...
.weak memalign
memalign = __interceptor_memalign
.globl __interceptor___libc_memalign
__interceptor___libc_memalign = memalign
What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:
8: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor_memalign
9: 0000000000000000 1 FUNC WEAK DEFAULT 1 memalign
10: 0000000000000000 1 FUNC GLOBAL DEFAULT 1
__interceptor___libc_memalign
In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as
extern "C" void memalign()
__attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
__attribute__((alias("__interceptor_memalign")));
If nothing else, this patch makes it more obvious what is going on.
llvm-svn: 204823
|
|
|
|
|
|
| |
Fixed in r204716.
llvm-svn: 204717
|
|
|
|
| |
llvm-svn: 204708
|
|
|
|
| |
llvm-svn: 204707
|
|
|
|
| |
llvm-svn: 204602
|
|
|
|
| |
llvm-svn: 204593
|
|
|
|
| |
llvm-svn: 204592
|
|
|
|
|
|
|
|
| |
Using __msan_unpoison() on null-terminated strings is awkward because
strlen() can't be called on a poisoned string. This case warrants a special
interface function.
llvm-svn: 204448
|
|
|
|
|
|
|
|
|
| |
Extend ParseFlag to accept the |description| parameter, add dummy values for all existing flags.
As the flags are parsed their descriptions are stored in a global linked list.
The tool can later call __sanitizer::PrintFlagDescriptions() to dump all the flag names and their descriptions.
Add the 'help' flag and make ASan, TSan and MSan print the flags if 'help' is set to 1.
llvm-svn: 204339
|
|
|
|
| |
llvm-svn: 204234
|
|
|
|
|
|
|
|
| |
Compiler-rt part of MSan implementation of advanced origin tracking,
when we record not only creation point, but all locations where
an uninitialized value was stored to memory, too.
llvm-svn: 204152
|
|
|
|
| |
llvm-svn: 203795
|
|
|
|
| |
llvm-svn: 203773
|
|
|
|
|
|
|
| |
Get rid of the context argument in UNPOISON_PARAM and INITIALIZE_RANGE.
Get rid of all the thread-local contexts in interceptors.
llvm-svn: 203119
|
|
|
|
| |
llvm-svn: 202972
|
|
|
|
| |
llvm-svn: 202847
|
|
|
|
| |
llvm-svn: 202713
|
|
|
|
|
|
| |
can't build anything here.
llvm-svn: 202297
|
|
|
|
|
|
|
|
|
| |
code so it seems it should have more generic name and moved to a common scope.
Renamed to AdjustStackSize.
Patch by Viktor Kutuzov.
llvm-svn: 202011
|
|
|
|
|
|
|
|
|
|
|
|
| |
C99/C++11."
This reverts commit r201910.
While __func__ may be standard in C++11, it was only recently added to
MSVC in 2013 CTP, and LLVM supports MSVC 2012. __FUNCTION__ may not be
standard, but it's *very* portable.
llvm-svn: 201916
|
|
|
|
| |
llvm-svn: 201910
|
|
|
|
| |
llvm-svn: 201778
|
|
|
|
| |
llvm-svn: 201666
|
|
|
|
|
|
| |
'compiler-rt' target encompassing them all.
llvm-svn: 201556
|