fix(amd64): the image runs wherever the firmware loads it -- -fpie, every symbol hidden; qemu-stick-high in acceptance
The SER5 stopped at the loader's "Loading kernel from ESP...": built -fno-pic -fno-pie with
ImageBase 0, the image carried ~9,000 32-bit absolute addresses, and the firmware loaded it above
2 GiB, where the sign-extended ones (R_X86_64_32S) point into unmapped memory -- a page fault in
debug_checkpoint() before [CKPT 001]. Reproduced on QEMU's pc machine at 3 GiB (#PF, CR2 =
FFFFFFFFBD316542, the right address sign-extended); q35 always loads it below 2 GiB, so no QEMU
boot ever showed it.
amd64 now builds -fpie with kernel/include/starkernel/pie_hidden.h force-included (#pragma GCC
visibility push(hidden)), so globals are RIP-relative and none is reached through a GOT -- the
2026-08-06 bug that put -fno-pic there. The link refuses any object carrying a 32-bit absolute or
GOT relocation (4,531 on the old objects, none now). test_runner.c's visibility("default") on
global_test_stats is kept for the -fPIC ISAs only. make -f kernel/Makefile ARCH=amd64
qemu-stick-high boots the PC stick on pc with 3 GiB and is part of acceptance (.claude/CLAUDE.md).
Captain Bob, 2026-10-29; FABRIC-3.md XLIV.
Verified: qemu-stick-high with Zuse's pair, ok> and 7 ok, RIP sampled inside .text at base
0xBD297000 (logs/20261029-070253); acceptance amd64 -070508, aarch64 -070715, riscv64 -071138,
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, dict_hash=0xfec8c47cfc6f437f on all;
make -C v4 test-32, 39 suites, 0 failures. Not yet booted on the SER5.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
0a31e558be
commit
d6ea592c08
@@ -5897,3 +5897,48 @@ acceptance rule (`.claude/CLAUDE.md`) became: the three ISAs as built (v4), and
|
||||
of it ("i don't care about v3"); it stays in the tree, `system=v3` still boots it. Verified: the three images rebuilt with `system=v4` in their boot files; the
|
||||
SER5 image under OVMF as built boots v4, and after changing the word, v3 (`logs/20261014-ser5-image/`).
|
||||
|
||||
|
||||
## XLIV. The amd64 image runs wherever the firmware loads it -- a PC loads it above 2 GiB (the SER5, 2026-10-29)
|
||||
|
||||
**Found.** The first SER5 boot of the PC stick (`make write_stick`, 2026-10-29) stopped at the
|
||||
loader's second line, "Loading kernel from ESP...", with no `[CKPT 001]`. The amd64 image was
|
||||
built `-fno-pic -fno-pie`, ImageBase 0: about 9,000 of its addresses were 32-bit absolutes
|
||||
(8,168 `R_X86_64_32`, 839 `R_X86_64_32S`), of which the firmware's base relocations patch only the
|
||||
low 32 bits. `R_X86_64_32S` is sign-extended, so at a load address of 2 GiB or more it points into
|
||||
unmapped memory. The first such access is `debug_checkpoint()` reading its `L"[CKPT "` prefix --
|
||||
the zero-extended `mov $imm32` string pointers of the two lines before it still worked, which is
|
||||
why exactly those printed. QEMU never showed it: OVMF on q35 with the RAM we give it loads the
|
||||
image below 2 GiB. Reproduced with the stick image unchanged on QEMU's `pc` machine at 3 GiB
|
||||
(OVMF loads it at `0xBD297000`): `#PF` at ImageBase + `0x104C`, `CR2=FFFFFFFFBD316542` -- the
|
||||
right address, `0xBD316542`, sign-extended. At 1 GiB the same image boots to `[zuse@Hera] ok> `.
|
||||
|
||||
**Ruled** (Captain Bob, 2026-10-29), from a written trade-off: `-fpie` with every symbol hidden
|
||||
(not `-mcmodel=large`, which costs code size and speed in the VM's inner loop, nor keeping the image low),
|
||||
and a 3 GiB boot added to acceptance.
|
||||
|
||||
**Built.**
|
||||
- `kernel/Makefile`, amd64 `ARCH_CFLAGS`: `-fpie -include kernel/include/starkernel/pie_hidden.h`
|
||||
in place of `-fno-pic -fno-pie`. `pie_hidden.h` is `#pragma GCC visibility push(hidden)`:
|
||||
`-fvisibility=hidden` marks definitions only, and an extern declaration of default visibility
|
||||
is reached through the GOT -- which `ld -m i386pep` never builds: the 2026-08-06 bug (FABRIC-0.md)
|
||||
that put `-fno-pic` there. With the pragma GCC uses no GOT. (EDK2's GCC X64 `ProcessorBind.h`
|
||||
does the same.)
|
||||
- The amd64 link refuses any object carrying `R_X86_64_32`, `_32S`, a GOT or `PLTOFF64`
|
||||
relocation (`AMD64_RELOC_FORBIDDEN`), listing them -- on the old objects it lists 4,531.
|
||||
Now none: `PC32`, `PLT32` and `64` only. `.text` grew 2.9%.
|
||||
- `v3/src/test_runner/test_runner.c`: `global_test_stats`' `visibility("default")` (a workaround
|
||||
for the old `-fPIC` GOT) is kept for aarch64/riscv64 and dropped under `pie_hidden.h`, where it
|
||||
contradicted the hidden declaration.
|
||||
- `make -f kernel/Makefile ARCH=amd64 qemu-stick-high`: `qemu-stick` on the `pc` machine with
|
||||
3 GiB (`STICK_MACHINE`, `STICK_MEM`), so OVMF loads the image above 2 GiB as a PC does.
|
||||
|
||||
**Verified.** `qemu-stick-high`, the stick with Zuse's pair (`qemu_session.py stick_zuse`):
|
||||
`POST: PASSED`, `PARITY:V4_POST tests=538 pass=538 fail=0`, `[zuse@Hera] ok> `, `7 ok`
|
||||
(`logs/20261029-070253`); the same image's RIP sampled during a 3 GiB boot ran at
|
||||
`0xBD29CE70`..`0xBD2F40FF`, inside its `.text` at base `0xBD297000`. Acceptance: amd64
|
||||
`-070508`, aarch64 `-070715`, riscv64 `-071138`, each `PARITY:V4_POST tests=538 pass=538 fail=0`,
|
||||
`POST: PASSED`, `[zuse@Hera] ok> `, `dict_hash=0xfec8c47cfc6f437f` on all four boots;
|
||||
`make -C v4 test-32`, 39 suites, 0 failures. The SER5 itself: a new stick, not yet booted.
|
||||
|
||||
Not covered by QEMU: a load above 4 GiB (OVMF keeps images below it). The relocation check
|
||||
covers that case statically -- no 32-bit absolute is left to break there.
|
||||
|
||||
Reference in New Issue
Block a user