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.
This will be relevant once #31605 is merged.
In general, stack traces do *not* contain unique addresses for inlined
frames, but for error return traces, they will after the above PR. This
bool indicates that code printing the trace should not try to resolve
inline frames since they're explicitly encoded into the instruction
addresses.
This is set as state on stack trace rather than passed into the
formatting methods as an argument, as it's not really a formatting
option--whether or not it's correct to resolve inlines is decided at the
time of capture!
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.
On POSIX, start.zig did not reset the `environ_initialized` field, which
prevented the environment variables from ever actually getting scanned.
On Windows, environment variable scanning is allocation-free, so it's
okay for `std.Io.Threaded.init_single_threaded` to use the global
environment block.
When linking libc, these targets can get their environment variables
from `std.c.environ`. Additionally, it's okay for WASI to use ANSI
escape sequences; nothing in the relevant specs claim otherwise.
Andrew Kelley