zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. https://ziglang.org

Age	Commit message (Collapse)	Author
6 days	fix build runner compilation errors on macOS	Andrew Kelley

6 days	std.debug: simplify printLineFromFile	Andrew Kelley

6 days	update all std.fs.cwd() to std.Io.Dir.cwd()	Andrew Kelley

6 days	update all occurrences of openFile to receive an io instance	Andrew Kelley

6 days	update all occurrences of close() to close(io)	Andrew Kelley

2025-12-06	std: make stack unwinding faster on macOS	Matthew Lugg
	https://github.com/ziglang/zig/issues/26027#issuecomment-3571227050 tracked some bad performance in `DebugAllocator` on macOS down to a function in dyld which `std.debug.SelfInfo` was calling into. It turns out `dladdr`'s symbol lookup logic is horrendously slow (looking at its source code, it appears to be doing a linear scan over all symbols in the image?!). However, we don't actually need the symbol, so we want to try and avoid this logic. Luckily, dyld has more precise APIs for what we need! Unluckily, Apple, in their infinite wisdom, decided they should be deprecated in favour of `dladdr`, despite the latter being several times slower (and by "several times", I have measured a 50x slowdown on repeated calls to `dladdr` compared to the other API). But luckily again, the deprecated APIs are still exposed. So, after a careful analysis of the situation (reading dyld code and cursing Apple engineers), I think it makes sense to just use these deprecated APIs for now. If they ever go away, we can write our own cache for this data to bypass Apple's awfully slow code, but I suspect these functions will stick around for the foreseeable future. Uh, and if `_dyld_get_image_header_containing_address` goes away, there's also `dyld_image_header_containing_address`, which is a seemingly identical function, exported by dyld just the same, but with a separate (functionally identical) implementation, and not documented in the public header file. Apple work in mysterious ways, I guess.
2025-11-20	fuzzer: account for runtime address slide	Matthew Lugg
	This is relevant to PIEs, which are notably enabled by default on macOS. The build system needs to only see virtual addresses, that is, those which do not have the slide applied; but the fuzzer itself naturally sees relocated addresses (i.e. with the slide applied). We just need to subtract the slide when we communicate addresses to the build system.
2025-11-20	std.debug: split up Mach-O debug info handling	Matthew Lugg
	Like ELF, we now have `std.debug.MachOFile` for the host-independent parts, and `std.debug.SelfInfo.MachO` for logic requiring the file to correspond to the running program.
2025-10-29	std: fix compilation errors on Windows	Andrew Kelley

2025-10-29	std: fix macos compilation errors	Andrew Kelley

2025-10-07	std.debug.SelfInfo.MachO: don't restore vector registers during unwinding	Alex Rønne Petersen
	We know that these are unsupported and irrelevant for unwinding, so don't fail the unwind attempt trying to read/write them for no ultimate purpose.
2025-10-01	std.debug: some adjustments to target handling	Alex Rønne Petersen
	* driverkit handling missing in a few places. * x86-solaris is a dead target. * aarch64_be does not exist on Darwin, FreeBSD, Windows.
2025-10-01	std.debug.SelfInfo: rename Darwin to MachO	Alex Rønne Petersen