WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
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
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
This entails passing a linker flags to Apple linkers when the standard
library is not meant for inclusion in such cache.
For this to have effect on every library, propagate link flags when
building _Concurrency and Observation.
This is needed for Apple internal configurations.
Addresses rdar://120653968
These triples don't need additional adjustments in the standard library and complement existing embedded triples for i686 and x86_64 CPU architectures.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
Running `swiftc` with `wasm32-none-none` or `wasm32-unknown-none` currently fails, as this embedded target is not built. Let's include it in the list of embedded targets.
LLVM might not be build with support for all architectures to save time.
The changes in this commit check the value of LLVM_TARGETS_TO_BUILD
provided by LLVMConfig.cmake to add or skip the different embedded
targets if LLVM happens to not build with support for that target.
While x86_64 and ARM/AArch64 are very common in `LLVM_TARGETS_TO_BUILD`,
targets like RISCV are more specialized and might not be always enabled.
This is not a problem for builds using the `build-script` because of the
changes introduced in #70057, but it is still a problem for other builds
that do not use `build-script`. This solution should work for any build.
This is needed for some Apple internal configurations that needs to build the
standard library in pieces to construct an SDK.
Given the limited audience, only introduce this flag in CMake.
Addresses rdar://118178539
