Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
facf22b8 |
| 26-May-2023 |
Vitaly Buka <vitalybuka@google.com> |
[fuzzer] Platfom specific version of PageSize
|
#
baa1488c |
| 26-May-2023 |
zhanglimin <zhanglimin@loongson.cn> |
[fuzzer] Don't hard-code page size in FuzzerUtil.h
Don't hard code the page in FuzzerUtil.h, this breaks on e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
[fuzzer] Don't hard-code page size in FuzzerUtil.h
Don't hard code the page in FuzzerUtil.h, this breaks on e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
show more ...
|
#
cb9f2de2 |
| 26-May-2023 |
Jason Molenda <jason@molenda.com> |
Revert "[fuzzer] Don't hard-code page size in FuzzerUtil.h"
This reverts commit a2b677e8153758997a9043360cf51333eecc3c44.
reverting
Differential Revision: https://reviews.llvm.org/D140607
because
Revert "[fuzzer] Don't hard-code page size in FuzzerUtil.h"
This reverts commit a2b677e8153758997a9043360cf51333eecc3c44.
reverting
Differential Revision: https://reviews.llvm.org/D140607
because <sys/auxv.h> and getauxval() are not available on macOS; this change is breaking the mac CI bots.
show more ...
|
#
a2b677e8 |
| 25-May-2023 |
zhanglimin <zhanglimin@loongson.cn> |
[fuzzer] Don't hard-code page size in FuzzerUtil.h
Don't hard code the page in FuzzerUtil.h, this breaks on e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
[fuzzer] Don't hard-code page size in FuzzerUtil.h
Don't hard code the page in FuzzerUtil.h, this breaks on e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
c7bd6435 |
| 01-Oct-2021 |
Hans Wennborg <hans@chromium.org> |
[libFuzzer] Use octal instead of hex escape sequences in PrintASCII
Previously, PrintASCII would print the string "\ta" as "\x09a". However, in C/C++ those strings are not the same: the trailing 'a'
[libFuzzer] Use octal instead of hex escape sequences in PrintASCII
Previously, PrintASCII would print the string "\ta" as "\x09a". However, in C/C++ those strings are not the same: the trailing 'a' is part of the escape sequence, which means it's equivalent to "\x9a". This is an annoying quirk of the standard. (See https://eel.is/c++draft/lex.ccon#nt:hexadecimal-escape-sequence)
To fix this, output three-digit octal escape sequences instead. Since octal escapes are limited to max three digits, this avoids the problem of subsequent characters unintentionally becoming part of the escape sequence.
Dictionary files still use the non-C-compatible hex escapes, but I believe we can't change the format since it comes from AFL, and libfuzzer never writes such files, it only has to read them, so they're not affected by this change.
Differential revision: https://reviews.llvm.org/D110920
show more ...
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
7c921753 |
| 03-Aug-2021 |
Kostya Serebryany <kcc@google.com> |
[libFuzzer] replace Vector/Set with std::vector/std::set. The custom names are not required any more since we now build with a private version of libc++. Fix some of the 81+ character lines. Mechanic
[libFuzzer] replace Vector/Set with std::vector/std::set. The custom names 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
show more ...
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5 |
|
#
08891816 |
| 02-Apr-2021 |
Aaron Green <aarongreen@google.com> |
Tweak SimpleFastHash
This change adds a SimpleFastHash64 variant of SimpleFastHash which allows call sites to specify a starting value and get a 64 bit hash in return. This allows a hash to be "resu
Tweak SimpleFastHash
This change adds a SimpleFastHash64 variant of SimpleFastHash which allows call sites to specify a starting value and get a 64 bit hash in return. This allows a hash to be "resumed" with more data.
A later patch needs this to be able to hash a sequence of module-relative values one at a time, rather than just a region a memory.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D94510
show more ...
|
Revision tags: llvmorg-12.0.0-rc4 |
|
#
6708186c |
| 12-Mar-2021 |
Aaron Green <aarongreen@google.com> |
[crt][fuzzer] Fix up various numeric conversions
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
[crt][fuzzer] Fix up various numeric conversions
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
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
#
292ab49d |
| 03-Mar-2020 |
serge-sans-paille <sguelton@redhat.com> |
Fix UB in compiler-rt base64 implementation
As a follow-up to 1454c27b60447d969d0c1ecaf20b2186fe9d85ec
|
#
1454c27b |
| 03-Mar-2020 |
serge-sans-paille <sguelton@redhat.com> |
Syndicate, test and fix base64 implementation
llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine
Syndicate, test and fix base64 implementation
llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine
results, which is a problem when shifting signed values. (0xFF << 16) is implicitly converted to a (signed) int, and thus results in 0xffff0000, h is negative. Combining negative numbers with a + in that context is not what we want to do.
This is a recommit of 5a1958f2673f8c771e406a7e309e160b432c9a79 with UB removved.
This fixes https://github.com/llvm/llvm-project/issues/149.
Differential Revision: https://reviews.llvm.org/D75057
show more ...
|
#
49684f9d |
| 02-Mar-2020 |
Mitch Phillips <31459023+hctim@users.noreply.github.com> |
Revert "Syndicate, test and fix base64 implementation"
This reverts commit 5a1958f2673f8c771e406a7e309e160b432c9a79.
This change broke the UBSan build bots. See https://reviews.llvm.org/D75057 for
Revert "Syndicate, test and fix base64 implementation"
This reverts commit 5a1958f2673f8c771e406a7e309e160b432c9a79.
This change broke the UBSan build bots. See https://reviews.llvm.org/D75057 for more information.
show more ...
|
#
5a1958f2 |
| 24-Feb-2020 |
serge-sans-paille <sguelton@redhat.com> |
Syndicate, test and fix base64 implementation
Move Base64 implementation from clangd/SemanticHighlighting to llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous im
Syndicate, test and fix base64 implementation
Move Base64 implementation from clangd/SemanticHighlighting to llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine some results, which is a problem when shifting signed values. (0xFF << 16) is implicitly converted to a (signed) int, and thus results in 0xffff0000, which is negative. Combining negative numbers with a + in that context is not what we want to do.
This fixes https://github.com/llvm/llvm-project/issues/149.
Differential Revision: https://reviews.llvm.org/D75057
show more ...
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo 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
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
#
14cf71a3 |
| 08-May-2018 |
Matt Morehouse <mascasa@google.com> |
[libFuzzer] Guard symbolization with try-lock.
Summary: When out-of-memory or timeout occurs, threads can be stopped during symbolization, thereby causing a deadlock when the OOM/TO handlers attempt
[libFuzzer] Guard symbolization with try-lock.
Summary: When out-of-memory or timeout occurs, threads can be stopped during symbolization, thereby causing a deadlock when the OOM/TO handlers attempt symbolization. We avoid this deadlock by skipping symbolization if another thread is symbolizing.
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46605
llvm-svn: 331825
show more ...
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2 |
|
#
065421f0 |
| 17-Nov-2017 |
Vitaly Buka <vitalybuka@google.com> |
[fuzzer] Initialize PcDescr buffer before calling __sanitizer_symbolize_pc
__sanitizer_symbolize_pc is not instrumented so msan assumes that PcDescr was not initialized.
llvm-svn: 318488
|
Revision tags: llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4 |
|
#
bebcbfb4 |
| 27-Aug-2017 |
George Karpenkov <ekarpenkov@apple.com> |
[libFuzzer] Use custom allocators for STL containers in libFuzzer.
Avoids ODR violations causing spurious ASAN warnings.
Differential Revision: https://reviews.llvm.org/D37086
llvm-svn: 311866
|
#
24069a04 |
| 26-Aug-2017 |
George Karpenkov <ekarpenkov@apple.com> |
Revert "[libFuzzer] Use custom allocators for STL containers in libFuzzer"
This reverts commit 3539efc2f2218dba2bcbd645d0fe276f2b5cf588.
llvm-svn: 311831
|
#
d50410bf |
| 26-Aug-2017 |
George Karpenkov <ekarpenkov@apple.com> |
[libFuzzer] Use custom allocators for STL containers in libFuzzer
Avoids ODR violations causing spurious ASAN container overflow warnings.
Differential Revision: https://reviews.llvm.org/D37086
ll
[libFuzzer] Use custom allocators for STL containers in libFuzzer
Avoids ODR violations causing spurious ASAN container overflow warnings.
Differential Revision: https://reviews.llvm.org/D37086
llvm-svn: 311830
show more ...
|
Revision tags: llvmorg-5.0.0-rc3 |
|
#
10ab2ace |
| 21-Aug-2017 |
George Karpenkov <ekarpenkov@apple.com> |
Move libFuzzer to compiler_rt.
Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.l
Move libFuzzer to compiler_rt.
Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
show more ...
|