PUBLIC is a MASM directive and causes a build error in a certain version of MSVC
```
Microsoft (R) ARM Macro Assembler Version 14.44.35217.0 for 64 bits
Copyright (C) Microsoft Corporation. All rights reserved.
D:\r\_work\swift-build\swift-build\SourceCache\swift\stdlib\public\RuntimeModule\get-cpu-context-aarch64.asm(21) : error A2003: improper line syntax: PUBLIC
```
EXPORT is an ARMASM equivalent, which is already there.
- Remove spurious `unsafe` on non-unsafe calls in TaskCancellation.swift
and UnsafeCxxIterators.swift
- Change `var fd` to `let fd` in ImageSource.swift since it is never mutated
This is better than the `alternativePaths` mechanism because it means that
a client of the `Runtime` module can do its own thing, which might even
mean fetching things from a remote server or decompressing files or any
other thing we might find useful.
rdar://170642627
We can't test the alternate image support for ELF, because that's been
removed in favour of `SymbolLocator`/`SymbolSource`.
Also we must pass `/opt:icf` in the symbolicated backtrace test when
using PDB, otherwise we corrupt the metadata.
Finally fix a mistake in `Utils.swift` where we were crashing if the
environment variable in question wasn't set.
rdar://168454023
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
