aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-10-01ci: add Forgejo Actions workflow fileAlex Rønne Petersen
2025-10-01ci: we don't require s3cmd anymoreAlex Rønne Petersen
2025-10-01ci: move Git repository unshallowing to the workflowAlex Rønne Petersen
2025-10-01ci: stop requiring an ARCH environment variable to be setAlex Rønne Petersen
2025-10-01test: disable an error trace test on optimized riscv64-linuxAlex Rønne Petersen
2025-09-30ArrayHashMapWithAllocator: add `sortUnstable` fn alongside `sort`Ryan Liptak
2025-09-30Fix zig build lazy -> eager dependency promotionTimothy Bess
Before, this had a subtle ordering bug where duplicate deps that are specified as both lazy and eager in different parts of the dependency tree end up not getting fetched depending on the ordering. I modified it to resubmit lazy deps that were promoted to eager for fetching so that it will be around for the builds that expect it to be eager downstream of this.
2025-09-30add deflate compression, simplify decompressionKendall Condon
Implements deflate compression from scratch. A history window is kept in the writer's buffer for matching and a chained hash table is used to find matches. Tokens are accumulated until a threshold is reached and then outputted as a block. Flush is used to indicate end of stream. Additionally, two other deflate writers are provided: * `Raw` writes only in store blocks (the uncompressed bytes). It utilizes data vectors to efficiently send block headers and data. * `Huffman` only performs Huffman compression on data and no matching. The above are also able to take advantage of writer semantics since they do not need to keep a history. Literal and distance code parameters in `token` have also been reworked. Their parameters are now derived mathematically, however the more expensive ones are still obtained through a lookup table (expect on ReleaseSmall). Decompression bit reading has been greatly simplified, taking advantage of the ability to peek on the underlying reader. Additionally, a few bugs with limit handling have been fixed.
2025-10-01ci: enable running libc-test on x86_64-linux-releaseAlex Rønne Petersen
2025-10-01libc-test: set a 1.6G max_rss for each test caseAlex Rønne Petersen
1.4G was the highest value I observed for any test case on x86_64-linux. This change should prevent OOM conditions in CI.
2025-10-01libc-test: disable malloc-oom.cAlex Rønne Petersen
This causes QEMU to OOM in CI.
2025-10-01ci: bump x86_64-freebsd max_rss from 30G to 40GAlex Rønne Petersen
2025-10-01ci: run test-error-traces on riscv64-linuxAlex Rønne Petersen
2025-10-01test: remove stack_iterator standalone testAlex Rønne Petersen
Our new stack trace tests cover all the important parts of this.
2025-10-01test: don't run error/stack trace tests on self-hosted on BSDsAlex Rønne Petersen
See: 0700ec35bda705fccb61cb3f28734ce11166fda5
2025-10-01test: disable an error trace test on optimized x86_64-freebsd and ↵Alex Rønne Petersen
loongarch64-linux
2025-09-30Merge pull request #25227 from mlugg/capture-stackMatthew Lugg
The Great `std.debug` Refactor
2025-09-30std.debug.SelfInfo: remove shared logicmlugg
There were only a few dozen lines of common logic, and they frankly introduced more complexity than they eliminated. Instead, let's accept that the implementations of `SelfInfo` are all pretty different and want to track different state. This probably fixes some synchronization and memory bugs by simplifying a bunch of stuff. It also improves the DWARF unwind cache, making it around twice as fast in a debug build with the self-hosted x86_64 backend, because we no longer have to redundantly go through the hashmap lookup logic to find the module. Unwinding on Windows will also see a slight performance boost from this change, because `RtlVirtualUnwind` does not need to know the module whatsoever, so the old `SelfInfo` implementation was doing redundant work. Lastly, this makes it even easier to implement `SelfInfo` on freestanding targets; there is no longer a need to emulate a real module system, since the user controls the whole implementation! There are various other small refactors here in the `SelfInfo` implementations as well as in the DWARF unwinding logic. This change turned out to make a lot of stuff simpler!
2025-09-30Dwarf.Unwind: fix typomlugg
2025-09-30typomlugg
2025-09-30Dwarf.Unwind: handle macOS deviation from standardmlugg
Apparently the `__eh_frame` in Mach-O binaries doesn't include the terminator entry, but in all other respects it acts like `.eh_frame` rather than `.debug_frame`. I have no idea.
2025-09-30std.debug: significantly speed up capturing stack tracesmlugg
By my estimation, these changes speed up DWARF unwinding when using the self-hosted x86_64 backend by around 7x. There are two very significant enhancements: we no longer iterate frames which don't fit in the stack trace buffer, and we cache register rules (in a fixed buffer) to avoid re-parsing and evaluating CFI instructions in most cases. Alongside this are a bunch of smaller enhancements, such as pre-caching the result of evaluating the CIE's initial instructions, avoiding re-parsing of CIEs, and big simplifications to the `Dwarf.Unwind.VirtualMachine` logic.
2025-09-30cbe: workaround GCC miscompilationmlugg
This was causing a zig2 miscomp, which emitted slightly broken debug information, which caused extremely slow stack unwinding. We're working on fixing or reporting this upstream, but we can use this workaround for now, because GCC guarantees arithmetic signed shift.
2025-09-30std.debug.SelfInfo: mark ARM unwinding as unsupportedmlugg
We need to parse the `.ARM.exidx` section to be able to reliably unwind the stack on ARM.
2025-09-30typomlugg
2025-09-30std: clarify cpu_context register order rationalemlugg
2025-09-30std.debug: cap total stack trace framesmlugg
...just in case there is broken debug info and/or bad values on the stack, either of which could cause stack unwinding to potentially loop forever.
2025-09-30std.debug: don't assume return address register is defined if not specifiedmlugg
This logic was causing some occasional infinite looping on ARM, where the `.debug_frame` section is often incomplete since the `.exidx` section is used for unwind information. But the information we're getting from the compiler is totally *valid*: it's leaving the rule as the default, which is (as with most architectures) equivalent to `.undefined`!
2025-09-30std.debug.SelfInfo: thread safetymlugg
This has been a TODO for ages, but in the past it didn't really matter because stack traces are typically printed to stderr for which a mutex is held so in practice there was a mutex guarding usage of `SelfInfo`. However, now that `SelfInfo` is also used for simply capturing traces, thread safety is needed. Instead of just a single mutex, though, there are a couple of different mutexes involved; this helps make critical sections smaller, particularly when unwinding the stack as `unwindFrame` doesn't typically need to hold any lock at all.
2025-09-30ElfModule: fix assertion failuremlugg
2025-09-30std: don't get CPU context when using CBE targeting MSVCmlugg
Calling `current` here causes compilation failures as the C backend currently does not emit valid MSVC inline assembly. This change means that when building for MSVC with the self-hosted C backend, only FP unwinding can be used.
2025-09-30std.posix.abort: only trigger breakpoint on Windows if being debuggedmlugg
Processes should reasonably be able to expect their children to abort with typical exit codes, rather than a debugger breakpoint signal. This flag in the PEB is what would be checked by `IsDebuggerPresent` in kernel32, which is the function you would typically use for this purpose. This fixes `test-stack-trace` failures on Windows, as these tests were expecting exit code 3 to indicate abort.
2025-09-30std.debug: go back to storing return addresses instead of call addressesmlugg
...and just deal with signal handlers by adding 1 to create a fake "return address". The system I tried out where the addresses returned by `StackIterator` were pre-subtracted didn't play nicely with error traces, which in hindsight, makes perfect sense. This definition also removes some ugly off-by-one issues in matching `first_address`, so I do think this is a better approach.
2025-09-30std: work around crash parsing LLVM PDBmlugg
This crash exists on master, and seems to have existed since 2019; I think it's just very rare and depends on the exact binary generated. In theory, a stream block should always be a "data" block rather than a FPM block; the FPMs use blocks `1, 4097, 8193, ...` and `2, 4097, 8194, ...` respectively. However, I have observed LLVM emitting an otherwise valid PDB which maps FPM blocks into streams. This is not a bug in `std.debug.Pdb`, because `llvm-pdbutil` agrees with our stream indices. I think this is arguably an LLVM bug; however, we don't really lose anything from just weakening this check. To be fair, MSF doesn't have an explicit specification, and LLVM's documentation (which is the closest thing we have) does not explicitly state that FPM blocks cannot be mapped into streams, so perhaps this is actually valid. In the rare case that LLVM emits this, previously, stack traces would have been completely useless; now, stack traces will work okay.
2025-09-30std.debug: fix typomlugg
2025-09-30update to new std.debug changesmlugg
2025-09-30std: allow disabling stack tracingmlugg
This option disables both capturing and printing stack traces. The default is to disable if debug info is stripped.
2025-09-30std.debug: update support checksmlugg
2025-09-30std.debug: miscellaneous fixesmlugg
Mostly on macOS, since Loris showed me a not-great stack trace, and I spent 8 hours trying to make it better. The dyld shared cache is designed in a way which makes this really hard to do right, and documentation is non-existent, but this *seems* to work pretty well. I'll leave the ruling on whether I did a good job to CI and our users.
2025-09-30std: rework/remove ucontext_tmlugg
Our usage of `ucontext_t` in the standard library was kind of problematic. We unnecessarily mimiced libc-specific structures, and our `getcontext` implementation was overkill for our use case of stack tracing. This commit introduces a new namespace, `std.debug.cpu_context`, which contains "context" types for various architectures (currently x86, x86_64, ARM, and AARCH64) containing the general-purpose CPU registers; the ones needed in practice for stack unwinding. Each implementation has a function `current` which populates the structure using inline assembly. The structure is user-overrideable, though that should only be necessary if the standard library does not have an implementation for the *architecture*: that is to say, none of this is OS-dependent. Of course, in POSIX signal handlers, we get a `ucontext_t` from the kernel. The function `std.debug.cpu_context.fromPosixSignalContext` converts this to a `std.debug.cpu_context.Native` with a big ol' target switch. This functionality is not exposed from `std.c` or `std.posix`, and neither are `ucontext_t`, `mcontext_t`, or `getcontext`. The rationale is that these types and functions do not conform to a specific ABI, and in fact tend to get updated over time based on CPU features and extensions; in addition, different libcs use different structures which are "partially compatible" with the kernel structure. Overall, it's a mess, but all we need is the kernel context, so we can just define a kernel-compatible structure as long as we don't claim C compatibility by putting it in `std.c` or `std.posix`. This change resulted in a few nice `std.debug` simplifications, but nothing too noteworthy. However, the main benefit of this change is that DWARF unwinding---sometimes necessary for collecting stack traces reliably---now requires far less target-specific integration. Also fix a bug I noticed in `PageAllocator` (I found this due to a bug in my distro's QEMU distribution; thanks, broken QEMU patch!) and I think a couple of minor bugs in `std.debug`. Resolves: #23801 Resolves: #23802
2025-09-30link.Dwarf: i just fixed error union values, s'nothin' else to itJacob Young
2025-09-30std.start: also don't print error trace targeting `.other`mlugg
This only matters if `callMain` is called by a user, since `std.start` will never itself call `callMain` when `target.os.tag == .other`. However, it *is* a valid use case for a user to call `std.start.callMain` in their own startup logic, so this makes sense.
2025-09-30test-error-traces: skip some more optimized tracesmlugg
2025-09-30tests: fix 32-bit compatible arch selectionmlugg
2025-09-30windows_bat_args: fix path handlingmlugg
The input path could be cwd-relative, in which case it must be modified before it is written into the batch script. Also, remove usage of deprecated `GeneralPurposeAllocator` alias, rename `allocator` to `gpa`, use unmanaged `ArrayList`.
2025-09-30std.debug.Pdb: fix leakmlugg
2025-09-30test-standalone: update for std.debug changesmlugg
2025-09-30fix compile errors and minor bugsmlugg
2025-09-30test-stack-traces: fix on x86-windowsmlugg
2025-09-30std.debug: don't attempt SelfInfo unwinding when unsupportedmlugg