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`.
Instead of hardcoding a call to defaultRandomSeed() use the customizable
std.options.cryptoRandomSeed() like in the rest of the function.
Closes#19943.
In #22522 I said:
> RC="zig rc" will now work in combination with zig cc and CMake. Here's an example of cross-compiling a simple Windows GUI CMake project
>
> $ RC="zig rc" CC="zig cc --target=x86_64-windows-gnu" cmake .. -DCMAKE_SYSTEM_NAME=Windows -G Ninja
However, I didn't realize that the time that this only works because of the `-G Ninja` part. When not using Ninja as the build tool, CMake adds a workaround for 'very long lists of object files' where it takes all object files and runs them through `ar` to combine them into one archive:
4a11fd8dde/Modules/Platform/Windows-GNU.cmake (L141-L158)
This is a problem for the Windows resource use-case, because `ar` doesn't know how to deal with `.res` files and so this object combining step fails with:
unknown file type: foo.rc.res
Only the linker knows what to do with .res files (since it has its own `.res` -> `.obj` ('cvtres') conversion mechanism). So, when using Ninja, this object file combining step is skipped and the .res file gets passed to the linker and everyone is happy.
Note: When CMake thinks that its using `windres` as the Windows resource compiler, it will pass `-O coff` to windres which causes it to output a COFF object file instead of a `.res` file, which means that the `ar` step can succeed because it's only working on actual object files.
---
This commit gives `zig rc` the ability to output COFF object files directly when `/:output-format coff` is provided as an argument. This effectively matches what happens when CMake uses `windres` for resource compilation, but requires the argument to be provided explicitly.
So, after this change, the following CMake cross-compilation use case will work, even when not using Ninja as the generator:
RC="zig rc /:output-format coff" CC="zig cc --target=x86_64-windows-gnu" cmake .. -DCMAKE_SYSTEM_NAME=Windows
