| Age | Commit message (Collapse) | Author |
|
|
|
Avoid some unneccessary copy
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D145758
|
|
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D77457
|
|
are not required any more since we now build with a private version of libc++. Fix some of the 81+ character lines. Mechanical change, NFC expected.
[libFuzzer] replace Vector/Set with std::vector/std::set.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D107374
|
|
Attempting to build a standalone libFuzzer in Fuchsia's default toolchain for the purpose of cross-compiling the unit tests revealed a number of not-quite-proper type conversions. Fuchsia's toolchain include `-std=c++17` and `-Werror`, among others, leading to many errors like `-Wshorten-64-to-32`, `-Wimplicit-float-conversion`, etc.
Most of these have been addressed by simply making the conversion explicit with a `static_cast`. These typically fell into one of two categories: 1) conversions between types where high precision isn't critical, e.g. the "energy" calculations for `InputInfo`, and 2) conversions where the values will never reach the bits being truncated, e.g. `DftTimeInSeconds` is not going to exceed 136 years.
The major exception to this is the number of features: there are several places that treat features as `size_t`, and others as `uint32_t`. This change makes the decision to cap the features at 32 bits. The maximum value of a feature as produced by `TracePC::CollectFeatures` is roughly:
(NumPCsInPCTables + ValueBitMap::kMapSizeInBits + ExtraCountersBegin() - ExtraCountersEnd() + log2(SIZE_MAX)) * 8
It's conceivable for extremely large targets and/or extra counters that this limit could be reached. This shouldn't break fuzzing, but it will cause certain features to collide and lower the fuzzers overall precision. To address this, this change adds a warning to TracePC::PrintModuleInfo about excessive feature size if it is detected, and recommends refactoring the fuzzer into several smaller ones.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D97992
|
|
Adds the -fast-16-labels flag, which enables efficient instrumentation
for DFSan when the user needs <=16 labels. The instrumentation
eliminates most branches and most calls to __dfsan_union or
__dfsan_union_load.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D84371
|
|
Summary:
- Fail loudly if SetFocusFunction failed when it should not. For more info see
- https://github.com/google/oss-fuzz/issues/3311
- https://github.com/google/sanitizers/issues/1190
- Fail loudly if CollectDataFlow is called without seed corpus.
Reviewers: kcc, metzman
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D73813
|
|
llvm-svn: 363473
|
|
llvm-svn: 363469
|
|
mode that traces up to 16 labels at a time and never runs out of labels. Second attempt. This time with a fix for windows (putenv instead of setenv))
llvm-svn: 363445
|
|
faster DFSan mode that traces up to 16 labels at a time and never runs out of labels."
It broke the Windows build:
C:\b\s\w\ir\cache\builder\src\third_party\llvm\compiler-rt\lib\fuzzer\FuzzerDataFlowTrace.cpp(243): error C3861: 'setenv': identifier not found
This also reverts the follow-up r363327.
llvm-svn: 363358
|
|
mode that traces up to 16 labels at a time and never runs out of labels.
llvm-svn: 363326
|
|
present in the corpus
llvm-svn: 361579
|
|
functionality is now part of libFuzzer proper; also write functions.txt to the disk only if this file doesn't exist yet
llvm-svn: 361452
|
|
if -collect_data_flow= is given
llvm-svn: 361448
|
|
just slower.
llvm-svn: 360717
|
|
llvm-svn: 360715
|
|
don't need external python scripts
llvm-svn: 360712
|
|
llvm-svn: 360400
|
|
collect_data_flow; attempt to fix the windows bot
llvm-svn: 360399
|
|
llvm-svn: 360378
|
|
instrumented blocks in a function; update merge_data_flow.py to merge coverage
llvm-svn: 360272
|
|
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
|
|
(DFT=data-flow-trace)
llvm-svn: 337434
|
|
llvm-svn: 334158
|
|
flow trace and prints the summary, but doesn't use the information in any other way yet
llvm-svn: 334058
|