Without scanning the main symbol stream, we get weird names for the
Swift functions in the backtrace, because the compiler generates C++-style
names for them. We actually want the mangled names, if possible, which
only seem to be in the symbol stream, so scan that as well and use it
to find mangled names.
rdar://168454023
Instead of the symbolication method being decided by what platform the symbolication code is running on, use a parameter passed to the symbolication function, defaulted to the current platform for backward compatibility.
Useful for the upcoming offline symbolicator.
rdar://168769519
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
---------
Co-authored-by: Carl Peto <carlpeto@Carls-MacBook-Pro.local>
Tweaked the comment in `Runtime/Config.h`.
Fixed a couple of incorrect ARM64 instruction mnemonics. This still needs
testing on ARM64 Windows.
Fixed an out-of-date comment in `swift-backtrace`.
Use a macro in `Backtrace.cpp` to guarantee we don't overrun the buffer,
and in the process simplify the code slightly.
rdar://101623384
We can't use `|| true` on Windows, so use `not` instead.
Also, on Windows, program names get downcased because `lit` uses
`os.path.normcase()`, so if we have program names in the output,
make sure the programs are already lower-case.
Fix up the stack overflow test to match the expected output.
Plus fix the macOS build to always build for macOS 26.0 or above.
rdar://101623384
We should only add the assembly files if we're actually going
to build the `Runtime` module. This was tripping up iOS/tvOS/
watchOS builds.
rdar://101623384
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
Also fix things so that we use the right path separator, depending
on image type, and add support for `DW_AT_specification` attributes
on `DW_TAG_subprogram` entries.
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
DWARF 3 doesn't have the `maximum_operations_per_instruction` field
in the line number header. As a result, we were mis-reading the
subsequent fields in the DWARF line table header.
rdar://168996222
This is slightly complicated by us currently not supporting this code
on iOS/tvOS/watchOS/visionOS. We should fix that, at which point we
can use the `SwiftStdlib`/`StdlibDeploymentTarget` macros instead.
rdar://164850733
Changed the way swift-backtrace works for JSON, so that it captures
into a CrashLog, then writes to JSON from the CrashLog. Separating out
the two sets of logic so that writing the CrashLog to JSON becomes
simpler and more modular.
The ELF specification says that if a section's type is set to `SHT_NULL`,
_none_ of the other fields are valid, so we shouldn't even be trying to
read the section name.
(We won't crash, because of how all of this code works, but we might
read an incorrect name.)
rdar://154837649
Musl's `clone()` wrapper returns `EINVAL` if you try to use `CLONE_THREAD`,
which seems a bit wrong (certainly it is in this particular application,
since we *really* don't care whether the thread is a valid C library
thread at this point).
Also properly support ELF images that are built with a base address other
than zero (this typically isn't an issue for dynamically linked programs,
as they will be relocated at runtime anyway, but for statically linked
binaries it's very common to set the base address to a non-zero value).
rdar://154282813
When fixing the previous problem, I should have realised that this
would cascade; the `@_specialize` annotations refer to the cached
versions of the types, and those are now turned off except on macOS
and Linux because they rely on the uncached versions, which are only
available on macOS and Linux.
rdar://144023438
To do this we also need to fix AddSwiftStdlib because if you set the
`INSTALL_WITH_SHARED` flag, the CMake scripts don't make a target
with the `-static` suffix, but AddSwiftStdlib also assumes that it
should dad `-static` to any module dependencies when building a
static library.
