If you're using Rosetta 2, there are ARM64 threads in your process as
well, which the backtracer skips. Unfortunately doing that messed up
the crashing thread index, so the backtracer might have crashed or
told you that a different thread was crashing than the one you
thought.
This only affects running x86-64 code on an Apple Silicon Mac.
rdar://135787913
The `swift-backtracing` module is an executable rather than a library so it
should have no reason to use the deprecated `@_implementationOnly import` over
`internal import`.
Rather than just on or off, I've changed it to allow "off", "fast",
or "full". "fast" means that we'll do symbol lookup, but we won't
try to find inline frames and we won't run line number programs
(those are the things that are taking considerable time in some
cases).
rdar://122302117
Symbolication can take some time, depending on the binaries involved.
In certain contexts it's better for the backtrace to finish quickly,
and then symbolication could be done offline.
rdar://122302117
Currently we read many small chunks from the process we're backtracing.
If it so happens that it's the local process, that isn't really a big
problem, but if it's a remote process, especially on Linux where we have
to use the memory server, it's probably a little slow.
Fix by adding a caching layer.
rdar://117681625
Use the new module structure rather the old SwiftShims header. This
is much cleaner and lets us include operating system headers to get
the relevant definitions where possible.
Add code to support ELF and DWARF, including decompression using
zlib, zstd and liblzma if those turn out to be required and available.
rdar://110261712
