fosslinux / fosslinux/live-bootstrap
riscv64: pinned tcc-mes (0.9.26-1147) cannot build through; the checksum set mixes eras
- Dominant language
- Shell
- Stars
- 750
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
The riscv64 checksum set describes a chain that cannot be built through
as pinned.
What does reproduce: building tcc-mes from the pinned
tcc-0.9.26-1147-gee75a10c with the mes-0.27.1 MesCC toolchain yields
the pinned binary byte-exactly (sha256 3e2d226b...). But that binary
cannot take the next step, for two independent reasons in revision
1147:
1. riscv64-gen.c's immediate-range assert,
assert(!((imm + (1 << 11)) >> 12)), false-positives on every
negative 12-bit immediate when tcc was built by MesCC: MesCC-riscv64
evaluates the uint32 addition as a full 64-bit add without
re-truncating mod 2^32 (long-standing MesCC behaviour, identical in
mes 0.26.1 and 0.27.1; reported to bug-mes with a minimal
reproducer). The addi sp,sp,-16 of the first function epilogue
trips it, so compiling even void f(){} dies. Revision 1157 casts
the expression to (uint32_t) (riscv64-gen.c:123,130), which MesCC
evaluates correctly.
2. 1147's assembler has no .option directive (added in the 1157 era),
and mes-0.27.1's riscv64 crt1.c startup asm uses
.option push/norelax/pop -- crt1.o cannot assemble at all.
Meanwhile the downstream riscv64 pins are outputs of the LATER
revision: a self-rebuilt tcc-0.9.26-1157-gdd46e018 compiles
mes-0.27.1's crt1.c to the pinned crt1.o cc417e9d... byte-exactly.
Commit 865b9aea ("Update mes to 0.27.1") refreshed only the tcc-mes
hash, so the set mixes eras, and no buildable path leads from the
pinned tcc-mes to the artifacts the later entries record.
One nuance for regeneration: the 1157 tcc built BY MesCC (generation
1) takes benign large-offset fallbacks at its now-non-fatal range
checks and produces a different but working crt1.o; its self-rebuild
has correct semantics and reproduces cc417e9d.... Byte verification
should target the self-rebuilt compiler's outputs -- which is what the
recorded downstream pins already are.
A CI job that re-checks what master pins today and evaluates the 1147
and 1157 range-check guards verbatim under MesCC (host gcc as passing
control) is live-bootstrap-riscv64-stale-pins.yml at
https://github.com/JasonGross/bootstrap-chain-bug-reproducers
The companion pull request bumps the riscv64 pin to 1157.
---
Authorship note: this issue was researched, written, and posted by
Claude (Anthropic's Fable 5 model), working on Jason Gross's behalf.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the pinned riscv64 bootstrap chain and the range-check expressions in riscv64-gen.c, especially around lines 123 and 130. Run live-bootstrap-riscv64-stale-pins.yml and compare the 1147 and 1157 paths under MesCC and host GCC. Done means the riscv64 pins describe a buildable chain and byte verification targets the self-rebuilt compiler outputs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, shell
- Domain
- build-system, ci-cd, compilers
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100