The tool will now skip over undefined symbols. These can only occur as a result
of building musl without compiler-rt, i.e. -rtlib=none. Thanks to this, it's no
longer necessary to patch Zig's compiler-rt, nor is it necessary to maintain a
symbol blacklist.
See the updated instructions here: https://github.com/ziglang/zig/wiki/Updating-libc#updating-the-libcs-file
Additionally, the tool now produces slightly more compact output by recognizing
symbols that are defined for a single arch, for a family of arches, or only for
arches using 32-bit or 64-bit time as their primary ABI.
Finally, the tool now supports all architectures that we can emit code for, with
the single exception of x86_64-linux-muslx32. (x32 currently fails with a ton of
relocation errors, leading me to believe that it might be an LLVM or LLD bug.)
Like d1d95294fd, this is more Apple nonsense where
they abused the arch component of the triple to encode what's really an ABI.
Handling this correctly in Zig's target triple model would take quite a bit of
work. Fortunately, the last Armv7-based Apple Watch was released in 2017 and
these targets are now considered legacy. By the time Zig hits 1.0, they will be
a distant memory. So just remove them.
If no external executor is available for a successful binary, its
execution is silently skipped. This allows the CI to test, to the
fullest extent possible, incremental cross-compilation to targets whose
binaries can't be executed on the host.
This is contained in the `test` step, so is tested by CI.
This commit also includes some enhancements to the `incr-check` tool to
make this work correctly.
At bare minimum, the compiler expects std.Target.<arch>.cpu.generic to work for
any given architecture when generating the builtin module. So rather than try to
hack that into working when the affected modules are omitted, just actually keep
them.
This affected lanai and xcore.
cortex-m85 already has 8msecext, which is not the same as trustzone. The former
is for the M profile, while the latter is for the A profile.
Revert of a small part of #18498.
* Add `ProcessorAlias` support.
* Bump output buffer size.
* Include `i` extension in RISC-V baselines.
* Update evaluation branch quota for RISC-V.
* Retain some CPU features that LLVM removed.
* Flatten more 'meta-features' used for CPU models.
* Remove some superfluous dependencies.
The compiler actually doesn't need any functional changes for this: Sema
does reification based on the tag indices of `std.builtin.Type` already!
So, no zig1.wasm update is necessary.
This change is necessary to disallow name clashes between fields and
decls on a type, which is a prerequisite of #9938.
A compilation build step for which the binary is not required could not
be compiled previously. There were 2 issues that caused this:
- The compiler communicated only the results of the emitted binary and
did not properly communicate the result if the binary was not emitted.
This is fixed by communicating the final hash of the artifact path (the
hash of the corresponding /o/<hash> directory) and communicating this
instead of the entire path. This changes the zig build --listen protocol
to communicate hashes instead of paths, and emit_bin_path is accordingly
renamed to emit_digest.
- There was an error related to the default llvm object path when
CacheUse.Whole was selected. I'm not really sure why this didn't manifest
when the binary is also emitted.
This was fixed by improving the path handling related to flush() and
emitLlvmObject().
In general, this commit also improves some of the path handling throughout
the compiler and standard library.
The implementation assumed that compilation units did not overlap, which
is not the case. The new implementation uses .debug_ranges to iterate
over the requested PCs.
This partially resolves#20990. The dump-cov tool is fixed but the same
fix needs to be applied to `std.Build.Fuzz.WebServer` (sorting the PC
list before passing it to be resolved by debug info).
I am observing LLVM emit multiple 8-bit counters for the same PC
addresses when enabling `-fsanitize-coverage=inline-8bit-counters`. This
seems like a bug in LLVM. I can't fathom why that would be desireable.
* Upgrade from u8 to usize element types.
- WebAssembly assumes u64. It should probably try to be target-aware
instead.
* Move the covered PC bits to after the header so it goes on the same
page with the other rapidly changing memory (the header stats).
depends on the semantics of accepted proposal #19755closes#20994
Before this commit, the name `v9.5a` was being used for two different features, and one was overwriting the other in the `all_features` array.
`arrowlake_s` is an alias for `arrowlake-s`
* libfuzzer: close file after mmap
* fuzzer/main.js: connect with EventSource and debug dump the messages.
currently this prints how many fuzzer runs have been attempted to
console.log.
* extract some `std.debug.Info` logic into `std.debug.Coverage`.
Prepares for consolidation across multiple different executables which
share source files, and makes it possible to send all the
PC/SourceLocation mapping data with 4 memcpy'd arrays.
* std.Build.Fuzz:
- spawn a thread to watch the message queue and signal event
subscribers.
- track coverage map data
- respond to /events URL with EventSource messages on a timer
