This is an archive of the discontinued LLVM Phabricator instance.

[crt][fuzzer] Fix up various numeric conversions
ClosedPublic

Authored by aarongreen on Mar 4 2021, 5:10 PM.

Details

Summary

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.

Diff Detail

Event Timeline

aarongreen requested review of this revision.Mar 4 2021, 5:10 PM
aarongreen created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2021, 5:10 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
charco added a comment.Mar 4 2021, 6:39 PM

LGTM, but someone else must approve

compiler-rt/lib/fuzzer/FuzzerCorpus.h
81–82

Do we really need long doubles here (and throughout this function)? Can we just use log?

aarongreen added inline comments.Mar 4 2021, 8:45 PM
compiler-rt/lib/fuzzer/FuzzerDictionary.h
29

I spent to much time in std=c++17... I need a message here.

aarongreen updated this revision to Diff 328375.Mar 4 2021, 8:53 PM

Added a comment to the static_assert to make it -std=c++11 compatible.

aarongreen added inline comments.Mar 4 2021, 8:54 PM
compiler-rt/lib/fuzzer/FuzzerCorpus.h
81–82

I'm not certain. If neither kcc nor morehouse object, I'm completely open to running the tests with that modification and comparing the result.

morehouse accepted this revision.Mar 5 2021, 9:58 AM
morehouse added inline comments.
compiler-rt/lib/fuzzer/FuzzerCorpus.h
81–82

If tests pass with log, I'd prefer to just use that for simpler code.

compiler-rt/lib/fuzzer/FuzzerDataFlowTrace.h
72

Unintentional indent? Please remove.

This revision is now accepted and ready to land.Mar 5 2021, 9:58 AM

Changed SumIncidence's type to double to reduce a lot of superfluous static_casting back a forth.

aarongreen marked an inline comment as done.

Fixed indent added by clang-format.

compiler-rt/lib/fuzzer/FuzzerDataFlowTrace.h
72

It seems the single space indent on the "public" keyword was throwing off clang-format.

This revision was automatically updated to reflect the committed changes.