- User Since
- Jul 24 2020, 3:05 PM (53 w, 2 d)
Jan 11 2021
Dor1s, what do you suggest? I haven't been able to find a good way to pass this information to libFuzzer without extending the API. The best we came up with was to simulate a memcmp(), but it didn't seem to work very well.
Dec 31 2020
I'll tell you more about my use-case with Atheris. In Python, it's very common for control flow to be decided by regular expressions. However, regular expression matching is implemented inside of CPython, in the _sre.c module. This means that unless CPython itself is compiled with coverage, re.match() appears as an atomic operation that libFuzzer has no insight into.
Dec 28 2020
Aug 11 2020
Aug 5 2020
Updated to use -lc++ instead of lstdc++ on Darwin.
Aug 4 2020
While this now builds with Ninja, there are some rtti-related issues with linking.
Adjusted rule to skip -z,defs when building under Ninja.
So it looks like the bug in question was pre-existing, and this change just exposes it. Specifically, when building with Ninja instead of Makefiles, the code path for statically linking libc++ isn't actually hit. Rather, the fallthrough "normal" code path is hit. I've confirmed this by verifying that the assemblies produced before my change with Ninja still want regular libc++.
Aug 3 2020
Updated to skip building i386 output, but to statically link libc++.
Jul 30 2020
Sticking just with x86_64 is possible; I actually have the code for that here, but it's a bit ugly:
Jul 24 2020
Removed changes that were already made in a previous change, and adds docs.