| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 304504
|
|
|
|
| |
llvm-svn: 304503
|
|
|
|
| |
llvm-svn: 304500
|
|
|
|
| |
llvm-svn: 304318
|
|
|
|
|
|
| |
remove a TODO printf
llvm-svn: 301889
|
|
|
|
| |
llvm-svn: 301845
|
|
|
|
|
|
| |
few weeks
llvm-svn: 301826
|
|
|
|
| |
llvm-svn: 300780
|
|
|
|
|
|
| |
-fsanitize-coverage=indirect-calls
llvm-svn: 300775
|
|
|
|
| |
llvm-svn: 300766
|
|
|
|
|
|
| |
-fsanitize-coverage=8bit-counters
llvm-svn: 300745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Coverage is using large arrays which requires large allocations.
These allocations are flaky and often failing on win64.
We are using the 32-bits size until this gets a better fix.
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D29945
llvm-svn: 295086
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
|
|
|
|
|
|
| |
this fix the code relied on the fact that the other function (__sanitizer_cov) is inlined. This was true with clang builds on x86, but not true with gcc builds on x86 and on PPC. This caused bot redness after r292862
llvm-svn: 292998
|
|
|
|
|
|
|
|
|
|
| |
pc_array_size and kPcArrayMaxSize appear to be measured in elements, not
bytes, so we shouldn't multiply idx by sizeof(uptr) in this bounds
check. 32-bit Chrome was tripping this assertion because it has 64
million coverage points. I don't think it's worth adding a test that has
that many coverage points.
llvm-svn: 292955
|
|
|
|
|
|
|
| |
Somehow this causes lots of test failures on Windows. These appear to
have been accidentally added back in r291736.
llvm-svn: 291947
|
|
|
|
|
|
|
|
| |
This reverts commit https://reviews.llvm.org/rL291734
Reason: mac breakage
http://lab.llvm.org:8080/green//job/clang-stage1-configure-RA_build/28798/consoleFull#1657087648e9a0fee5-ebcc-4238-a641-c5aa112c323e
llvm-svn: 291736
|
|
|
|
| |
llvm-svn: 291735
|
|
|
|
|
|
|
|
| |
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D28541
llvm-svn: 291734
|
|
|
|
|
|
|
|
| |
Subscribers: kubabrecka, mgorny
Differential Revision: https://reviews.llvm.org/D26758
llvm-svn: 289498
|
|
|
|
| |
llvm-svn: 283185
|
|
|
|
|
|
| |
This reverts commit r282994.
llvm-svn: 283183
|
|
|
|
| |
llvm-svn: 282994
|
|
|
|
| |
llvm-svn: 281679
|
|
|
|
| |
llvm-svn: 281677
|
|
|
|
|
|
|
|
|
|
|
|
| |
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
|
|
|
|
|
|
| |
trace-gep, mostly usaful for value-profile-based fuzzing; run-time part
llvm-svn: 280045
|
|
|
|
|
|
| |
sanitizer-coverage interface
llvm-svn: 279026
|
|
|
|
|
|
|
|
| |
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D23186
llvm-svn: 277858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r235779, Timur bumped the buffer size up to 1<<27, or about 134
million coverage points, presumably to handle Chrome. We allocate two
arrays of uptrs with this size, and this reliably exhausts all available
address space on 32-bit Windows (2 allocations of 512MB) when ASan is
also enabled.
Let's reduce the buffer size for now to stabilize the test suite. We can
re-evaluate the approach later when we've brought the Chrome ASan
builders back to life.
Kostya said that Mike reduced the number of instrumented coverage points
that LLVM emits by half since Timur made this change, so reducing this
array size should also be safe.
With this change, the 32-bit ASan tests reliably pass for me on Windows
10.
llvm-svn: 277558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetListOfModules().
Summary:
This removes the hard limit on the number of loaded modules (used to be
16K), and makes it easier to use LoadedModules w/o causing a memory
leak: ListOfModules owns the modules, and makes sure to properly clean
them in destructor.
Remove filtering functionality that is only needed in one place (LSan).
Reviewers: aizatsky
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D17470
llvm-svn: 261554
|
|
|
|
| |
llvm-svn: 261376
|
|
|
|
|
|
|
|
|
|
| |
Updating sancov invocation on html_cov_dump.
sancov change: http://reviews.llvm.org/D17169
Differential Revision: http://reviews.llvm.org/D17171
llvm-svn: 260629
|
|
|
|
| |
llvm-svn: 259005
|
|
|
|
|
|
|
|
| |
Subscribers: tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D16374
llvm-svn: 258999
|
|
|
|
| |
llvm-svn: 258253
|
|
|
|
|
|
|
|
|
| |
Summary: Extracting GetRangeOffset function before report-on-dump
functionality.
Differential Revision: http://reviews.llvm.org/D16332
llvm-svn: 258211
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15871
llvm-svn: 256804
|
|
|
|
|
|
| |
not in addition to, regular coverage. Do the regular coverage in the run-time instead
llvm-svn: 254483
|
|
|
|
| |
llvm-svn: 252815
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Atomic RMW is not necessary in InitializeGuardArray.
It is supposed to run when no user code runs.
And if user code runs concurrently, then the atomic
RMW won't help anyway. So replace it with non-atomic RMW.
InitializeGuardArray takes more than 50% of time during re2 fuzzing:
real 0m47.215s
51.56% a.out a.out [.] __sanitizer_reset_coverage
6.68% a.out a.out [.] __sanitizer_cov
3.41% a.out a.out [.] __sanitizer::internal_bzero_aligned16(void*, unsigned long)
1.79% a.out a.out [.] __asan::Allocator::Allocate(unsigned long, unsigned long,
With this change:
real 0m31.661s
26.21% a.out a.out [.] sanitizer_reset_coverage
10.12% a.out a.out [.] sanitizer_cov
5.38% a.out a.out [.] __sanitizer::internal_bzero_aligned16(void*, unsigned long)
2.53% a.out a.out [.] __asan::Allocator::Allocate(unsigned long, unsigned long,
That's 33% speedup.
Reviewed in http://reviews.llvm.org/D14537
llvm-svn: 252715
|
|
|
|
| |
llvm-svn: 251071
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Trim spaces.
- Use nullptr in place of 0 for pointer variables.
- Use '!p' in place of 'p == 0' for null pointer checks.
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13310
llvm-svn: 248964
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had to call __sanitizer_cov_dump() from tool-specific
callbacks - instead, let sanitizer_common library handle this in a
single place.
This is a re-application of r245770, with slightly different approach
taken.
llvm-svn: 245890
|
|
|
|
|
|
|
| |
These changes break both autoconf Mac OS X buildbot (linker errors
due to wrong Makefiles) and CMake buildbot (safestack test failures).
llvm-svn: 245784
|
|
|
|
|
|
|
| |
Previously we had to call __sanitizer_cov_dump() from tool-specific
callbacks - instead, let sanitizer_common library handle this in a single place.
llvm-svn: 245770
|
|
|
|
|
|
| |
sanitizer coverage. Also fix pedantic warnings
llvm-svn: 243721
|
|
|
|
| |
llvm-svn: 236907
|
|
|
|
| |
llvm-svn: 236294
|
|
|
|
| |
llvm-svn: 235779
|