<div dir="ltr"><div dir="ltr">On Fri, Jul 12, 2019 at 4:19 PM Szabolcs Nagy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * Designed and developed from the start to work with LLVM tooling and<br>
> testing like fuzz testing and sanitizer-supported testing.<br>
<br>
the difficulty of this is not in the libc, but various<br>
issues in the sanitizer libraries.. e.g. you don't want to<br>
fuzz test a libc with a fuzz runtime that depends on a c++<br>
runtime (or any other external component that can call<br>
back to libc outside of the control of the fuzz runtime).<br></blockquote><div><br></div><div>FWIW, I was able to fuzz-test some functions in musl using the AFL fuzzer with only small changes (yes, this is not LLVM libFuzzer -- I haven't gotten around to tryingthat yet). It required only minor modifications to the musl makefile and to AFL.</div><div><br></div><div>The existing "NOSSP_OBJS" listed in the musl Makefile were exactly the correct ones that needed to be excluded from fuzz coverage instrumentation. I compiled the rest of the library with "afl-gcc", and those files with plain "gcc".</div><div><br></div><div>Additionally, a 2-line change was needed in AFL to avoid trying to recursively re-enter initialization while it was already in progress (startup initialization calls getenv which then tries to call back into initialization, because initialization hasn't completed yet). Other than initialization, the instrumentation doesn't call back into libc, so just suppressing that recursion is sufficient.</div><div><br></div></div></div>