Toolchain: am I crazy if I use the Apple-supplied clang?

[technix]

After a quick test, it turned out that the copy of clang compiler supplied by Apple can produce elf files as well as Mach-O when targeting any platform Apple uses in their products (i686 and x86_64 for Macs, armv6, armv7a and armv8a for iPhones, plus armv6-m, armv7-m, armv7e-m and armv8-m for th Mx coprocessors in recent iPhones) and with some additional arguments it will even call linkers for you properly, as if you are using the prefix-gcc commands. I decided to poke around this:

Code: Select all

clang -target x86_64-pc-linux-gnu -fuse-ld=/usr/local/bin/x86_64-elf-ld # for x86_64
clang -target i686-linux-gnu -fuse-ld=/usr/local/bin/x86_64-elf-ld # for i686, you can reuse x86_64-ld
clang -target arm-none-eabihf -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=arm1176jzf-s -mfloat-abi=hard # for armv6f, for example arm1176jzf-s Raspberry Pi 1
clang -target arm-none-eabihf -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-a7 -mfloat-abi=hard # for armv7a, for example cortex-a7 in Raspberry Pi 2
clang -target aarch64-linux-gnu -fuse-ld=/usr/local/bin/aarch64-linux-gnu-ld -mcpu=cortex-a53 # for aarch64, for example cortex-a53 in Raspberry Pi 3

# Some other ARM cores you might run across
clang -target arm-none-eabi -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=arm7tdmi
clang -target arm-none-eabi -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=arm926ej-s
clang -target arm-none-eabi -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m0
clang -target arm-none-eabi -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m3
clang -target arm-none-eabihf -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m4 -mfloat-abi=hard
clang -target arm-none-eabihf -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m7 -mfloat-abi=hard
clang -target arm-none-eabi -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m23
clang -target arm-none-eabihf -fuse-ld=/usr/local/bin/arm-none-eabi-ld -mcpu=cortex-m33 -mfloat-abi=hard

You need to install binutils from source separately to get x86_64-elf-ld and aarch64-linux-gnu-ld. As of 32-bit ARM I used the linker from GNU ARM Embedded project, which is maintained directly by ARM themselves.

I was trying to use "-target x86_64-gnu" but that resulted in clang generating arguments targeting Apple's ld, freaking GNU ld out. Similar situation happened for aarch64. So you do need to lie a bit so clang would emit the correct command line for the linker, and the linker would accept it.

[Octocontrabass]

We recommend a cross-compiler because it gives you a consistent toolchain that will be the same no matter what host OS you're using (or what host OS the people you're asking for help are using).

I don't know if it applies to Apple's Clang, but some host-specific compilers are built in a way that prevent them from generating freestanding binaries.

[Acceleration]

The Apple-supplied Clang is really just suited for Mach-O executables, though here is what I use to compile Glowtide's initial boot stage (works on QEMU, haven't tested it on X99 platforms yet):

Code: Select all

clang-6.0 -m16 -Wl,--script=src/init.ld -nostdlib -static src/init.S -o init

I use the bleeding edge 6.0 version as of this message, this method might just make flat binaries that are suited for use with realmode assembly, right after QEMU SeaBIOS hands off.

-m16 signifies that you want x86 16-bit code. You're in real mode or some variation of it so you have to define that. I use a linkerscript (-Wl,--script=src/init.ld) since you want to strip away all Mach-O/ELF information at the very beginning of the boot stage. You do not want to have a standard library just yet and after this stage, you ought to have a cross-compiler/cross-interpreter. -nostdlib -static forces usage of no C libraries and a static executable.

Apple-supplied Clang may have APSL-specific components. Do not link statically to Apple code.