TypeSystem: extend the triple sanitization for Swift #1577
Conversation
The triple as computed from the executable by lldb is `x86_64--linux`. While this is sufficient for many uses, it is insufficient for Swift which requires a matching triple. `x86_64--linux` is morally equivalent to `x86_64-unknown-linux` which is easily achieved through normalization. However, this is insufficient on its own. This new triple is morally equivalent to `x86_64-unknown-linux-none-elf`: a freestanding environment, that is, it is a bare-metal target. Unlike the Darwin environments, the environment on Linux is important as that identifies the libc (GNU = glibc, uclibc = µlibc, musl = musl). Furthermore, it contains extended ABI information, e.g. `gnueabi` vs `gnueabihf` which indicates glibc + EABI + soft float vs hard float (`-meabi`, `-mfloat-abi=soft`/`mflot-abi=hard`) which are incompatible targets. Fortunately, triple normalization is a very common process in clang and the API on `llvm::Triple` allows us to do this as explicit operations. The previous approach explicitly replaced the arch name spelling of `x86_64h` which is the Haswell slice with the generic `x86_64` architecture to handle Darwin targets. Because the Haswell slice only enables better code generation and is ABI compatible (though not executable across previous generations), this difference does not matter. Re-apply this change in terms of `llvm::Triple`. This code now assumes that the Linux environment is `gnu` which is woefully inadequate but given that the REPL currently is not meant to execute on android (which uses `android` or `androideabi` for the environment and the bionic libc) and Swift is currently hosted only, it is a stop gap until this can be addressed more thoroughly. This change is sufficient to enable unification of the Swift resource directory layout across Darwin and non-Darwin targets.
|
@swift-ci please test |
| /// It also add the GNU environment for Linux. Although this is technically | ||
| /// incorrect, as the `*-unknown-linux` environment represents the bare-metal | ||
| /// environment, because Swift is currently hosted only, we can get away with | ||
| /// it. |
There was a problem hiding this comment.
I always thought GNU was a vendor, not an environment? Is it both? Can you add to the comment what the effect of this is / why this is needed?
The aim of this function is to translate the real triple into a triple that we have a stdlib for. If that is what this is enables, I'm on board with the change.
Please cherry-pick to master-rebranch and master-next, too.
There was a problem hiding this comment.
GNU isn't a vendor, its an environment - the distributions are the vendors, and they all largely use unknown as they dont have any vendor extensions. I can certainly extend the comment (most of that is in the commit message anyways). An example is SuSE which vends a toolchain as x86_64-suse-linux-gnu.
Yeap, you nailed exactly: this is translating a triple (that is computed by lldb from repl_swift) into a triple that the Swift compiler can work with because it has a standard library for that target.
Ah, the joys of the rebranching, thanks for the reminder on that!
There was a problem hiding this comment.
An example is SuSE which vends a toolchain as x86_64-suse-linux-gnu.
Ah that makes perfect sense. Thanks for clearing that up!
The triple as computed from the executable by lldb is
x86_64--linux.While this is sufficient for many uses, it is insufficient for Swift
which requires a matching triple.
x86_64--linuxis morally equivalent tox86_64-unknown-linuxwhich iseasily achieved through normalization. However, this is insufficient on
its own. This new triple is morally equivalent to
x86_64-unknown-linux-none-elf: a freestanding environment, that is, itis a bare-metal target. Unlike the Darwin environments, the environment
on Linux is important as that identifies the libc (GNU = glibc, uclibc =
µlibc, musl = musl). Furthermore, it contains extended ABI information,
e.g.
gnueabivsgnueabihfwhich indicates glibc + EABI + soft floatvs hard float (
-meabi,-mfloat-abi=soft/mflot-abi=hard) which areincompatible targets.
Fortunately, triple normalization is a very common process in clang and
the API on
llvm::Tripleallows us to do this as explicit operations.The previous approach explicitly replaced the arch name spelling of
x86_64hwhich is the Haswell slice with the genericx86_64architecture to handle Darwin targets. Because the Haswell slice only
enables better code generation and is ABI compatible (though not
executable across previous generations), this difference does not
matter. Re-apply this change in terms of
llvm::Triple.This code now assumes that the Linux environment is
gnuwhich iswoefully inadequate but given that the REPL currently is not meant to
execute on android (which uses
androidorandroideabifor theenvironment and the bionic libc) and Swift is currently hosted only, it
is a stop gap until this can be addressed more thoroughly.
This change is sufficient to enable unification of the Swift resource
directory layout across Darwin and non-Darwin targets.