| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously it wasn't obvious what the default value of various sanitizer
options were. A very close approximation of the "default values" for the
options are the current value of the options at the time of printing the
help output.
In the case that no other options are provided then the current values
are the default values (apart from `help`).
```
ASAN_OPTIONS=help=1 ./program
```
This patch causes the current option values to be printed when the
`help` output is enabled. The original intention for this patch was to append
`(Default: <value>)` to an option's help text. However because this
is technically wrong (and misleading) I've opted to append
`(Current Value: <value>)` instead.
When trying to implement a way of displaying the default value of the
options I tried another solution where the default value used in `*.inc` files
were used to create compile time strings that where used when printing
the help output. This solution was not satisfactory for several reasons:
* Stringifying the default values with the preprocessor did not work very
well in several cases. Some options contain boolean operators which no
amount of macro expansion can get rid of.
* It was much more invasive than this patch. Every sanitizer had to be changed.
* The settings of `__<sanitizer>_default_options()` are ignored.
For those reasons I opted for the solution in this patch.
rdar://problem/42567204
Reviewers: kubamracek, yln, kcc, dvyukov, vitalybuka, cryptoad, eugenis, samsonov
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69546
|
|
|
|
| |
llvm-svn: 371704
|
|
|
|
| |
llvm-svn: 371687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It's handling isses as described here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
Patch by Martin Liška.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: cryptoad, kubamracek
Differential Revision: https://reviews.llvm.org/D59876
llvm-svn: 363480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adds a 64-bit signed flag parser for GWP-ASan's use.
Reviewers: vlad.tsyrklevich, eugenis
Subscribers: kubamracek, #sanitizers, llvm-commits, vitalybuka, morehouse, pcc, kcc
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61342
llvm-svn: 359631
|
|
|
|
| |
llvm-svn: 359133
|
|
|
|
| |
llvm-svn: 359125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
| |
llvm-svn: 334900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
String flags values appear to be duped twice. Once in `FlagParser::parse_flag`
using the `LowLevelAllocator` via `ll_strndup`, once in
`FlagHandler<const char *>::Parse` using the `InternalAllocator` via
`internal_strdup`. It looks like the second one is redundant, as the memory
for the first one is never freed and not used for anything else.
Assigning the value to the flag instead of duping it has a few advantages:
- if it was the only use of the `InternalAllocator` (which is the case for
Scudo), then the related code will not be compiled it, which saves us a
whole instantiation of the CombinedAllocator worth of extra code;
- in the event a string flag is parsed, the `InternalAllocator` would have
created a whole SizeClassAllocator32 region for a single allocation, which is
kind of wasteful.
- also, the string is dup'ed twice for the whole lifetime of a process.
I tested check-{sanitizer,asan,tsan,ubsan,scudo} successfully, so as far as I
can tell this doesn't appear to have bad side effects.
Reviewers: eugenis, alekseyshl
Reviewed By: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D36970
llvm-svn: 311386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.
Reviewers: eugenis, alekseyshl, kcc
Subscribers: llvm-commits, dberris, kubamracek
Differential Revision: https://reviews.llvm.org/D33371
llvm-svn: 303941
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
|
|
|
|
|
|
|
|
| |
Reason: breaks sanitizers builds.
Original Differential Revision: https://reviews.llvm.org/D317
llvm-svn: 299679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Recently, Clang enabled the check for virtual destructors
in the presence of virtual methods. That broke the bootstrap
build. Fixing it.
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31776
llvm-svn: 299672
|
|
|
|
|
|
|
|
|
| |
include_if_exists=/path/to/sanitizer/options reads flags from the
file if it is present. "%b" in the include file path (for both
variants of the flag) is replaced with the basename of the main
executable.
llvm-svn: 242853
|
|
|
|
| |
llvm-svn: 228893
|
|
|
|
|
|
| |
Print a warning at verbosity=1 and higher instead of dying immediately.
llvm-svn: 226458
|
|
|
|
|
|
|
|
|
| |
InternalAlloc is quite complex and its behavior may depend on the values of
flags. As such, it should not be used while parsing flags.
Sadly, LowLevelAlloc does not support deallocation of memory.
llvm-svn: 226453
|
|
|
|
|
|
| |
Allows loading sanitizer options from file.
llvm-svn: 226175
|
|
The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
|