Robert Allan JamesandClaude Sonnet 5
0a7f144367
vm_find_word() and dict_find_word_heat_aware() reference the same extern globals (sf_fc_list/sf_fc_count/sf_fc_cap) but GCC compiled cross-TU references to them with GOT-indirect addressing (R_X86_64_REX_GOTPCRELX) under -fPIC. This freestanding, statically-linked UEFI PE image has no dynamic linker to populate a GOT, so those reads silently returned NULL instead of the array's real address -- amd64-only, and exquisitely sensitive to unrelated code-size changes since the choice between direct and GOT-indirect addressing is a per-call-site GCC heuristic. Fix: -fno-pic -fno-pie for amd64 only (ARCH_CFLAGS, overriding COMMON_CFLAGS's -fPIC, which riscv64's -shared loader link still needs). Also removes -DPLATFORM_TIME_NO_INLINE, a prior one-off workaround for the identical bug applied to sf_monotonic_ns() specifically, now redundant. Adds R_X86_64_PC32/R_X86_64_PLT32 handling to elf_apply_relocations() as a robustness fix for the non-monolithic split-build path (dead code for the current monolithic boot, where OVMF's own PE loader relocates the image, not this loader). Verified: all three architectures boot clean and pass the full item-4.2 Hermes self-test, including MSG-DELIVER-ALL, which previously triggered the corruption on amd64 only. Write-up in FABRIC.md under item 4.2. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
src/starkernel/boot/
UEFI boot, kernel-image loading, and boot-time command-line handling.
uefi_loader.c— the UEFI application entry point (BOOTX64.EFI); callsExitBootServices()to take ownership of hardware, buildsBootInfo(memory map, ACPI, framebuffer), and hands off tokernel_main().elf_loader.c— ELF64 kernel image parsing/loading.cmdline.c— parses the boot-time kernel command line /starforth.cfgcontents (seeinclude/starkernel/cmdline.h,kernel_args.h).reloc_stub.c,reloc.S— position-independent relocation support for the loaded image.