We want to be able to efficiently serialise lists of images, and to do so
it makes most sense to create a separate `ImageMap` type. This also provides
a useful place to put methods to e.g. find an image by address or by build
ID.
rdar://124913332
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
Now that Darwin is provided by the system, we no longer need to disable the
system module maps in favour of our own, which also resolves a few other
problems that doing that was creating.
rdar://137201928
Also remove the code that deals with file descriptors; we will now
only start the backtracer for processes that have the get-task-allow
entitlement, which means that they've been specifically signed for
debugging, and *that* means that it is no longer critical to ensure
that unexpectedly inherited fds are closed.
rdar://137551812
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
