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
We shouldn't try to erase the message when in non-color mode; mostly
that's intended for redirected output scenarios anyway, and in that case
we don't really want garbage in the output.
Also, improve the failure messages when the backtracer itself goes
wrong or can't be executed.
Finally, change the behaviour slightly so that *if* we're explicitly
enabled, *and* the backtracer path wasn't explicitly specified, *and*
we can't find the backtracer, we print a warning on start-up. We
don't do that in any other case because we don't want spurious warnings
everywhere.
rdar://118055527
When we crash, emit a message straight away that says we're working
on a backtrace. If starting the backtracer fails, report that also.
Finally, add a duration to the messages output by the backtracer, so
that we can see how long it took.
rdar://118055527
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
This adds a new binary, `swift-backtrace-static`, to the build. The runtime
will not by default use this binary as the backtracer, but if you want to
statically link your own binaries against the standard library you can copy
`swift-backtrace-static` rather than `swift-backtrace` alongside your binary,
naming it `swift-backtrace`, and the runtime should find and use it, which
will mean you don't need to have `libswiftCore.so` et al installed.
rdar://115278959
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
Use `task_read_for_pid()` rather than having the crashing program pass its
own task port through. This opts us in to additional OS security measures
surrounding the use of this call.
rdar://107362003
Added some extra code to AddSwiftStdlib.cmake so executable targets can
specify target SDKs the same way libraries currently can.
Updated the Backtracing targets to specify just OS X for now.
The Linux Swift compiler is ICEing when building _Backtracing, while
Windows still needs some tweaks. In order to land this sooner, disable
this code except for macOS.
While I was doing this, it turns out Saleem was fixing things to avoid
having to patch the Windows include directories, which is awesome but
necessitates an extra change to the backtracing stuff to make the build
not fail on Windows.
rdar://105409147
Some symbolication frameworks have a symbol cache; we probably don't want
to use that for test cases, to avoid running into problems where the cache
holds stale information.
rdar://105409147
Fixed the colours so that they work with all of the default Terminal
presets. Also changed things so that when colour is off, we only use
ASCII characters in our source code displays.
rdar://105452194
This is Swift's external backtracer. It's written in Swift, and it's
responsible for generating nice backtraces when Swift programs crash.
It makes use of the new `_Backtracing` library, which is also (mostly,
aside from some assembly language) implemented in Swift.
rdar://103442000
