this is a bad commit that contains work in progress
changes to make fuzzing on macos work.
more specifically it contains macho-specific code
for loading debug information in the webserver.
it's messy because I'm still trying to understand
how this stuff works. with these changes the web
server loads but the wasm code panics.
it's unclear if the wasm panic is due to my dwarf
loading code being wrong or if we're encountering
some other latent issue.
This commit implements the linker-related code
required to have the `zig init` canyoufindme test
succeed on macos.
It fixes usage of the linker in order to account
for macos specific symbol mangling and introduces
some checks in the fuzzer code to prevent crashes
in case that instrumented code is invoked before
`fuzz_init` runs.
`@disableInstrumentation` has been added to the
start code to help reduce the amount of (needlessly)
instrumented code that runs, but the builtin is
active only in the scope where it's used, meaning
that any non-inlined function call that happens in
that same scope will still have instrumentation
enabled unless it too gets its own
`@disableInstrumentation` call.
Removing temporarily the code that bails out from
instrumentation callbacks when the fuzzer has not
been inited can be used to turn early (and wasteful)
execution of instrumented code into a crash, helping
finding places where to put more calls to
`@disableInstrumentation`.
Problem here is if zig is asked to create multiple static libraries, it
will build the runtime multiple times and then they will conflict.
Instead we want to build the runtime exactly once.
Unlike `compiler-rt`, `ubsan` uses the standard library quite a lot.
Using a similar approach to how `compiler-rt` is handled today, where it's
compiled into its own object and then linked would be sub-optimal as we'd
be introducing a lot of code bloat.
This approach always "imports" `ubsan` if the ZCU, if it exists. If it doesn't
such as the case where we're compiling only C code, then we have no choice other
than to compile it down to an object and link. There's still a tiny optimization
we can do in that case, which is when compiling to a static library, there's no
need to construct an archive with a single object. We'd only go back and parse out
ubsan from the archive later in the pipeline. So we compile it to an object instead
and link that to the static library.
TLDR;
- `zig build-exe foo.c` -> build `libubsan.a` and links
- `zig build-obj foo.c` -> doesn't build anything, just emits references to ubsan runtime
- `zig build-lib foo.c -static` -> build `ubsan.o` and link it
- `zig build-exe foo.zig bar.c` -> import `ubsan-rt` into the ZCU
- `zig build-obj foo.zig bar.c` -> import `ubsan-rt` into the ZCU
- `zig build-lib foo.zig bar.c` -> import `ubsan-rt` into the ZCU
