[swift-dev] Swift kernel hacking, compiler options and target triples

[John McCall]

> On Mar 28, 2016, at 11:16 AM, Simon Evans via swift-dev <swift-dev at swift.org> wrote:
> Hi
> 
> I’ve been experimenting with kernel programming in Swift and this required
> disabling the use of the red zone. Currently Im compiling to ELF on Linux and
> linking in my own minimal libc/libcpp with libswiftCore.a so its not using any
> Linux libraries.
> 
> I did a PR for adding a '-disable-red-zone' option but it was suggested to add
> a target triple instead of adding extra compiler options so I wanted to
> discuss it. I don't think there is a specific target I can currently use so
> I thought of adding one. Some suggested names I came up with:
> 
> x86_64-none-baremetal
> x86_64-elf-none
> 
> I don't have a strong preference but I couldnt find anything that really matched
> for an ELF kernel with no OS
> 
> On a related note about compiler options, what could be done about options such
> as enabling/disabling certain instruction sets eg SSE or FP or other such
> lowlevel options etc? These wouldn't necessarily always be on or off for a given
> target but the programer may want the ability to fine tune for firmware and
> embedded etc. Is there anyway this can be accomplished without adding lots of
> compiler options? I understand not wanting to go the gcc route of having a large
> option list.

I agree with Chris that it would be better in the abstract to tie these things to some
enumerable set of supported target configurations rather than accumulating huge
set of low-level options.  I am, however, worried about that philosophical stance
committing Swift to recording a bunch of information for (apologies, but...) experiments
that are likely to be trivial or abandoned.

Now, for your specific case, it's not clear whether you're writing your own kernel
or just writing code that you'd like to embed within an existing kernel.

If you're targeting an existing kernel, that really is a known target with well-defined
ABI rules, and the most sensible encoding into a triple is just to say that the OS is
the kernel environment, something like:
  x86_64-unknown-linux_kernel4.6
If you're targeting your own kernel, it's probably easiest to just adopt some existing
kernel's ABI unless you really get to a point that that's insufficient, and that leaves us
in the same situation.

I think it's completely reasonable in the abstract for Swift to support kernel triples
(ignoring for now all the bigger issues with running Swift in a kernel context).
There are two ways to do that: we can translate them to triples actually supported
by LLVM (plus necessary ABI-tweaking options like -disable-red-zone), or we can
get LLVM and Clang to accept the kernel triple natively and do sensible things with it.
The latter would be better; you'll need to bring it up on llvm-dev, though.

John.