Registration is required and Gum registers the one it runs on, so the
other architectures were unreachable weight: 29 MB of archive down to
4.4. This only makes sense on non-Barebone, where we also build tools
that work cross-arch, such as gum-graft.
GLib cannot run its C99 probes when cross-compiling and falls back to
gnulib's printf, whose frames are 1.8 KiB where picolibc's are 240
bytes. Say what the freestanding libc offers, and ask picolibc for the
positional arguments GLib wants before it will take them.
Put GLib on a diet there too: it skips the locale conversion in
g_strerror() and the filename display in the file-error path, which is
what drags libiconv in.
Rust signs no function pointer, so what is linked beside it was
built not to either. That left Gum unable to speak the ABI at all:
its trampolines returned to signed pointers as if they were plain,
and NativePointer#sign did nothing.
Sign, but leave out the type discrimination the kernel's own ABI
uses: a union of differently typed function pointers is how QuickJS
dispatches, and it cannot survive a discriminator per type. What
crosses to the kernel is signed where it crosses, as before.
The generic ARM flags name armv5t, which has neither Thumb-2 nor the
divide a Cortex-A7 has, and nothing took the float out of the ABI.
Clang also wants the eabi environment rather than elf.
The flavor is detected from the driver's own linker, which on macOS
is Apple's, while a bare-metal target links with LLD. LLD refuses
the option, so every link probe fails and each feature behind one
is detected as missing.
Rust's arm64e signs no function pointer and authenticates none, so
what is linked beside it must not either. Sign what crosses to the
kernel where it crosses.
Compile a machine whose config is kernel with the kernel's ABI,
against no system headers, and against the prefix being filled:
picolibc and the compiler-rt builtins are packages here, as they
are for a machine with no operating system at all.
Say the system is none, which is what a Darwin kernel is to
anything built here, and leave out the packages that belong to an
operating system.
Make a link work, since a build system asks its questions by
linking one: no dynamic linker, and the entry point named.
Read the config as a set of tags, thus a bare flavor says in its name
whether its code is position-independent: softfloat becomes
softfloat_nopic, and softfloat_msabi becomes softfloat_pic_msabi. This
also gives x86 a position-independent flavor, which it had no way to
name before.
A bare target is soft-float in each case now, thus remove the newlib
path that the other targets took.
The SDK that would have supplied a compiler is what is being built,
so either a triplet names the toolchain or the tools are named
outright. "No C compiler found" on a box full of them helps nobody.
The one we had suits a Linux module: System V, and not position
independent — the module loader resolves no GOT relocation, and the
kernel code model expects the top 2GB. A Windows kernel follows
another convention, and the agent's text is mapped a second time
into each instrumented process, shared, so that flavor is position
independent instead.
Soft float is what kernel mode means rather than what either
convention says, so both carry it. The convention is a property of
the machine rather than the toolchain, so it rides in the machine
file for whoever generates or inspects the code.
Everything in it is built -fno-pic, so a distribution whose driver
defaults to PIE rejects the resulting R_386_32 relocations outright.
Only 32-bit x86 minds, its addressing having nowhere else to go.
Straight to the linker: clang swallows the driver spelling when it is
gcc doing the link.
Share the soft-float flags both x86 bitnesses need and keep the
64-bit-only ones — the red zone, the kernel code model and the IBT
pair — with x86_64. clang has no i386 bare-metal triple under the
arch's own name, so map it to i686, and skip the hard-float arch
flags, which -mfpmath=sse would contradict.
A jump table is reached by an indirect jump, which the compiler marks
notrack and an IBT kernel does not permit, having left NOTRACK_EN clear.
Its own C is compiled this way for the same reason.
Soft-float on x86_64 is LLVM's +soft-float feature, which is what Rust's
own x86_64-unknown-none turns on, so both halves of a kernel-mode build
agree on where a double travels. -mno-sse alone does not reach the ABI.
long double has to be narrowed as well: soft-float has no lowering for
x87's 80-bit format, and LLVM crashes selecting it.
Only clang's bare-metal driver searches the sysroot on its own, and it
picks that driver for arm64 but not for x86_64, hence spelling out both
paths.
The SDK puts it inside the tree the devkit inlines from, so a bare-metal
target ended up with half of picolibc pasted into the header and the
other half missing. It is the consumer's libc to provide.
