* Use Instant::now instead of duration
* Use Some
* add custom serde for Instant
* fix linter
* only enable TimeFeedback when std flag is enabled
* fix typo
* fix linter std
* cargo fmt
* allow clippy::trivially_copy_pass_by_ref on custom serde serialize function
* allow TimeObserver and Timefeedback for no_std
* cargo fmt
---------
Co-authored-by: Andrea Fioraldi <andreafioraldi@gmail.com>
Reduces total number of packages from 577 to 571 on building with:
`cargo +nightly build --workspace --all-features`
* ahash 0.7 -> 0.8
* Move `AHasher::new_with_keys` to `RandomState::with_seeds` given the
recommendation from: aHash maintainer:
https://github.com/tkaitchuck/aHash/issues/132#issuecomment-1288207069
* bindgen: 0.61 -> 0.63
* c2rust-bitfields: 0.3 -> 0.17
* criterion: 0.3 -> 0.4
* crossterm: 0.25 -> 0.26
* dynasmrt: 1.2 -> 2
* goblin: 0.5.3 -> 0.6
* hashbrown: 0.12 -> 0.13
* nix: 0.25 -> 0.26
* The `addr` arg of `mmap` is now of type `Option<NonZeroUsize>`
* The `length` arg of `mmap` is now of type `NonZeroUsize`
* Requires updating implementers to update `nix` as well
* prometheus-client: 0.18.0 -> 0.19
* Do not box metrics
* Gauges (a majority of the LibAFL metrics) are now i64 types so there
is a small chance of overflow, with the u64 values that LibAFL
tracks, but unlikely to be problematic.
* Keep `exec_rate` as a floating point value
* serial_test: 0.8 -> 1
* typed-builder: 0.10.0 -> 0.12
* windows: 0.42.0 -> 0.44
Co-authored-by: Dominik Maier <domenukk@gmail.com>
Most of the time, fuzzing campaigns are reasonably long. Accordingly, when
using `NewHashFeedback`, you might have good reason to believe that you'll
find thousands (or more) different observations with different hashes. When
the `HashSet` outgrows its capacity, it can cause reallocation, which is slow.
See the following link for more details:
https://doc.rust-lang.org/std/vec/struct.Vec.html#capacity-and-reallocation
* libafl: Remove `{update,clear}_hash` from `ObserverWithHashField`
These methods aren't used by `NewHashFeedback`, so there's no compelling reason
to keep them in the interface. They preclude implementations of
`ObserverWithHashField` that calculcate a hash on-the-fly from a value. For
example, my use-case is to store the stdout of a process, and use
`NewHashFeedback` to only collect inputs that result in new messages on stdout.
Both of these methods are pretty suspicious to begin with - why should other
code be able to update the internal state of the observer? What are the
semantics of `update_hash`? If there are compelling reasons to keep these
methods, let's clarify their intent in the documentation.
* libafl: Return hash by value from `ObserverWithHashField`
This allows implementors of this trait to not store the hash, but rather to
compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and
this method is called once per execution of the target program, this is likely
to have negligible performance impact.
* libafl: Implement `ObserverWithHashField` for `ValueObserver`
This demonstrates the utility of the previous two commits. Now, `ValueObserver`
can be used with `NewHashFeedback`.
* Clippy, move to ahasher
* Oops :)
---------
Co-authored-by: Langston Barrett <langston.barrett@gmail.com>
* tmp
* more
* save
* TODO
* fix
* update to tinyinst on crates
* dep
* fmt
* shmem done
* cpp fmt
* clp
* fmt
* why??
* ver
* more makefile.toml
* windows test
* Update build_and_test.yml
* fix
* a
* install
* fmt
* fix
* only macos and win
* more
* The order matters
* remove
* fmt
* chg
* typo
Co-authored-by: Andrea Fioraldi <andreafioraldi@gmail.com>
* fix multiple subtle bugs with grimoire, mutators, and state
* obey the clippy overlord
* grimoire: skip over token after splice
* remove extraneous length check
