[all-commits] [llvm/llvm-project] 670818: [crt][fuzzer] Fix up various numeric conversions

Aaron via All-commits all-commits at lists.llvm.org
Thu Mar 11 16:01:50 PST 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6708186c91dd7c5463b83091ade40e721c0e62ab
      https://github.com/llvm/llvm-project/commit/6708186c91dd7c5463b83091ade40e721c0e62ab
  Author: Aaron Green <aarongreen at google.com>
  Date:   2021-03-11 (Thu, 11 Mar 2021)

  Changed paths:
    M compiler-rt/lib/fuzzer/FuzzerBuiltins.h
    M compiler-rt/lib/fuzzer/FuzzerBuiltinsMsvc.h
    M compiler-rt/lib/fuzzer/FuzzerCorpus.h
    M compiler-rt/lib/fuzzer/FuzzerDataFlowTrace.cpp
    M compiler-rt/lib/fuzzer/FuzzerDataFlowTrace.h
    M compiler-rt/lib/fuzzer/FuzzerDictionary.h
    M compiler-rt/lib/fuzzer/FuzzerDriver.cpp
    M compiler-rt/lib/fuzzer/FuzzerFork.cpp
    M compiler-rt/lib/fuzzer/FuzzerLoop.cpp
    M compiler-rt/lib/fuzzer/FuzzerMerge.cpp
    M compiler-rt/lib/fuzzer/FuzzerMutate.cpp
    M compiler-rt/lib/fuzzer/FuzzerRandom.h
    M compiler-rt/lib/fuzzer/FuzzerSHA1.cpp
    M compiler-rt/lib/fuzzer/FuzzerTracePC.cpp
    M compiler-rt/lib/fuzzer/FuzzerTracePC.h
    M compiler-rt/lib/fuzzer/FuzzerUtil.cpp
    M compiler-rt/lib/fuzzer/FuzzerUtil.h
    M compiler-rt/lib/fuzzer/FuzzerUtilFuchsia.cpp

  Log Message:
  -----------
  [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




More information about the All-commits mailing list