65922a2d4 started using some (deprecated but still available) dyld
functions for stack unwinding and debug information on Darwin targets,
because they are significantly faster than `dladdr` (which is the
"correct" thing to use). However, these functions are unavailable on
Darwin targets other than macOS, for instance on iOS. Therefore, on
those targets, we must fall back to the slow `dladdr` path.
The DWARF spec has CFI instructions that take signed offsets, but at least LLVM
always emits the unsigned variants, even for e.g. `.cfi_def_cfa_offset -4`.
Previously, if the same inline function was called multiple times
by the same caller, the inline function's frame would be repeated
multiple times, once for each prior call.
Followup to #30769
I grepped for `try .*toOwnedSlice` and checked all of them by hand.
Fixes a bunch of memory leaks removes usages or `errdefer` and `vars` in some places. I also switched array_list.Managed to ArrayList where it was convenient.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/32001
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
The intention behind the iterator was to avoid needing to allocate the
symbols, but in practice we need to allocate them anyway since we need
to reverse their order and don't have random access. The alternative
would be an N^2 algorithm.
In practice this isn't that bad, because even if the allocation fails,
we'll still end up printing the address, so the user still ends up with
the necessary information to reconstruct the crash. I don't think it's
worth it to try to set up some kind of ring buffer or return partial
results on failure, but may revisit this.
This fix reveals another bug--we need to display the inline site syms in
the reverse of the encoded order. The parent/child relationships are
actually encoded on the inline sites, but it's likely a bit fragile to
try to trace those, and also more complex. As long as there aren't
multiple matches this is fine, and if there are, tracing the parent/child
chain won't work anyway.
Apple's ld emit N_BNSYM and N_ENSYM to mark the start and end of
functions, while ld64.lld doesn't.
This resulted in MachOFile.load bailing out on unsupported STABS
layout when the linker used is ld64.lld.
This commit supports both layouts.
I hit an unexpected errno 30 on macos attempting to call createFile on a
directory in PATH. errno 30 is EROFS, this change propagates that error
as error.ReadOnlyFileSystem.
`resolveAddresses` now also works if some calls to `getDwarfForAddress`
fail with `error.MissingDebugInfo`; the affected source location is set
to `.invalid`.
This makes fuzzing work with `ReleaseSafe` for Mach-O.
Alex Rønne Petersen