The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
```
stdlib/public/libexec/swift-backtrace/main.swift:590:15: warning: variable 'now' was never mutated; consider changing to 'let' constant
588 | let name = target!.name
589 | let pid = target!.pid
590 | var now = timespec(tv_sec: 0, tv_nsec: 0)
| `- warning: variable 'now' was never mutated; consider changing to 'let' constant
591 |
592 | let ext: String
```
Linux gives the main thread a name based on the process name, and also
we need to tolerate an extra slash on the `<compiler-generated>` filename
for some reason.
rdar://121430255
Always put `registers` in the thread record, and always use the `threads`
top level key, even if we ask for only the crashed thread. Also add an
`omittedThreads` key.
rdar://121430255
Add the ability to specify a filename or directory name as the output-to
setting in `SWIFT_BACKTRACE`. If the option is set to a directory name,
generate a unique filename in that directory using the process name,
process ID and timestamp.
rdar://136977833
It's useful to capture the platform and platform version with the image map.
Also, display both the platform and architecture information when generating
a crash log.
rdar://124913332
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
We have some problems on Linux where Glibc pulls in `<elf.h>` and then
we end up with conflicting definitions. Fix by using C++ interop and
putting our definitions into a namespace.
rdar://137201928
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`.
We need to make sure that we build swift-backtrace with a deployment target
newer than 10.14.4 in order that we get linked against
`/usr/lib/swift/libswiftCore.dylib` rather than using an `@rpath`-based
path.
If we fail to do that, dyld becomes confused and we end up crashing with
weird errors about missing method implementations on `Swift.__StringStorage`.
To make this work, add support for `DEPLOYMENT_VERSION_*` in the
`add_swift_target_executable()` CMake function. And since I spotted a bug
in it, fix the existing support in `add_swift_target_library()` while I'm
there.
rdar://132710670
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
