`DebugActiveProcess()` can fail under certain circumstances, which results
in us not seeing the crashing thread, hence you don't get a backtrace (in
fact, the backtracer used to crash, since we never expected to be in that
situation).
Instead, use `NtQuerySystemInformation()` to get the thread list, then
`OpenProcess()` and `OpenThread()` to get process/thread handles. This
should be more robust.
rdar://171438432
The Win32 unwinder has to locate function entry records for the
`StackWalk64()` API to use; the code that was doing this was
incorrect and sometimes found the wrong record, which would result
in a corrupted stack walk.
rdar://172911008
Due to unfortunate structure packing rules in C, `struct pe_symbol` ends up
being 20 bytes instead of 18. The upshot is that when presented with a PE-COFF
binary that contains symbols (noting that this is actually a spec violation),
the backtracer will crash.
Unfortunately we often generate such binaries. We shouldn’t crash, though, and
the fix is to get the correct size for `struct pe_symbol`.
rdar://171711254
Also, fix two files that managed to use Windows API without
importing `WinSDK` as a result of the leakage caused by including
`windows.h` from `codeview.h`.
rdar://101623384
On-crash backtracing is basically there for 64-bit Windows. It
won't work on 32-bit because of a Swift compiler issue, and there
is a little more work to do yet, but it is now working!
rdar://101623384
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
We should expose the demangle functionality; It's been widely used by
calling into internal _swift_demangle and instead we should offer a real
API. It's also already used in the Runtime module already when forming
backtraces.
[Previous
discussions](https://forums.swift.org/t/demangle-function/25416/15)
happened between 2019 and 2024, and just never materialized in a
complete implementation and proposal.
Right now, even more tools are in need of this API, as we are building
continious profiling solutions etc, so it is a good time to revisit this
topic.
This PR is roughly based off @Azoy's
https://github.com/swiftlang/swift/pull/25314/files#diff-fd379a721cc9a1c9ef6486eae713e945da842b42170d4d069029a57334371eba
from 2019, however it brings it over to the new Runtime module which is
a great place to put this functionality - even Backtrace had to recently
reinvent calling the demangling infra in this module.
Pending SE review, [proposal
here](https://github.com/swiftlang/swift-evolution/pull/2989).
cc @azoy @al45tair
---------
Co-authored-by: Alastair Houghton <alastair@alastairs-place.net>
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
Alastair Houghton
Konrad `ktoso` Malawski
eeckstein