Conversation
aarch64 + riscv64 stage2 changes needed to host the in-image mes build across all (arch, board) variants: * syscall_brk caps requests at the user-space ceiling (PA 0x4FF00000 on aarch64, PA 0x8FF00000 on riscv64) and returns the *current* brk on failure — matches Linux semantics. Without this, mes's large arena brk requests zeroed past user memory into kernel structures. * absolute_path now collapses consecutive '/' to a single '/', mirroring x86 stage2's strcpy_path_loop. mes's include-from-path macro builds paths like "module//srfi/srfi-16.scm" because %moduledir already ends with "/"; without normalisation, find_file's strcmp never matches. * riscv64 setup_page_table sets the A and D bits in every PTE (V|R|W|X (|U) |A|D = 0xDF or 0xCF instead of 0x1F / 0x0F). The riscv64 virt CPU auto-updates these on access, but the SiFive U54 (sifive_u machine) raises an instruction page fault on the first fetch through a PTE with A=0 — that was the sifive_u boot hang. Setting them statically works on both boards; bootstrap code never inspects A/D so the semantics are advisory here.
There was a problem hiding this comment.
Pull request overview
This PR updates aarch64 and riscv64 stage2 to reliably host in-image mes builds across board variants by preventing heap growth into kernel memory, normalizing paths so file lookups work with redundant slashes, and adjusting RISC-V PTE flags to avoid first-access page faults on SiFive U54.
Changes:
- Cap
syscall_brkto the user-space ceiling and return the current brk on failure (Linux-like semantics). - Normalize absolute paths by collapsing consecutive
/to a single/before further normalization. - On riscv64, set PTE A/D bits in
setup_page_tableto avoid access faults on SiFive U54.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| builder-hex0-riscv64-stage2.S | Implements brk cap semantics, PTE A/D bits, and // collapse in absolute_path. |
| builder-hex0-riscv64-stage2.hex2 | Regenerated riscv64 stage2 hex2 output reflecting the assembly changes. |
| builder-hex0-riscv64-stage2.hex0 | Regenerated riscv64 stage2 hex0 output reflecting the assembly changes. |
| builder-hex0-aarch64-stage2.S | Implements brk cap semantics and // collapse in absolute_path. |
| builder-hex0-aarch64-stage2.hex2 | Regenerated aarch64 stage2 hex2 output reflecting the assembly changes. |
| builder-hex0-aarch64-stage2.hex0 | Regenerated aarch64 stage2 hex0 output reflecting the assembly changes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The brk cap test used bgeu, rejecting brk == 0x8FF00000. aarch64's b.hi accepts the boundary; match it so any allocator that lands on the cap exactly succeeds instead of silently returning the prior brk.
- 36f05b9 changed .S (bgeu->bgtu) but left .hex0/.hex2 stale; regenerate so committed artifacts match source (bgtu = 63600000) - rv64-asm2hex2.py: add bgt/ble/bgtu/bleu pseudos (swap blt/bge/bltu/ bgeu operands); rv64+a64 encoders sys.exit(1) on unknown mnemonic - stage2.S: correct stale 0x81000000/0x80800000 annotations to 0xA0820000/0xA0020000; drop stream-of-consciousness PTE comment - build.yml: add committed-vs-regenerated .hex0/.hex2 drift check - Makefile: drop dead asm.py prerequisite - delete orphan asm.py and builder-hex0-riscv64-stage1.S
- riscv64-stage2.S: delete 18 lines of stream-of-consciousness debug commentary above hoc_not_found (the described fix was already applied at shell_return:); regenerate .hex2/.hex0 since hex2tohex0.py carries source comments into the artifacts and these bytes flow into the riscv64 bh0 image - riscv64-stage1-sifive_u.S: register-conventions header referenced an unused s4 and omitted the actually-used s10; regenerate .hex2/.hex0 - a64_asm.py: delete the unreferenced _parse_arg / __main__ CLI / batch mode (the Makefile imports the module rather than shelling out to it); fix a refactor-scar in load_addr where first=True was assigned immediately before first=False - a64-asm2hex2.py: hoist the in-function load_addr import to the top-level import line - hex2tohex0.py: docstrings claimed RISC-V-only but the Makefile uses this script for AArch64 stage1/stage2 too; reword as "4-byte instruction RISC ISA" to match reality - Makefile: clean rule had "rm -f ... BUILD -rf" which parsed -rf as literal filenames; split into separate rm -f and rm -rf BUILD - DEVELOP.md: drop the asm.py row (no such file; rv64 encoder is inlined in rv64-asm2hex2.py); rephrase the parent-abuild bullet to back-reference instead of listing concrete file paths that may rot
absolute_path's comments said the scratch buffer is at 0x80600000 (the user process area); the code loads 0xA0000000 (matching the header memory map). Correct both comments and regenerate the committed .hex2/.hex0 (comment-only; machine code unchanged) so the CI drift check stays green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
aarch64 + riscv64 stage2 changes needed to host the in-image mes build across all (arch, board) variants:
syscall_brk caps requests at the user-space ceiling (PA 0x4FF00000 on aarch64, PA 0x8FF00000 on riscv64) and returns the current brk on failure — matches Linux semantics. Without this, mes's large arena brk requests zeroed past user memory into kernel structures.
absolute_path now collapses consecutive '/' to a single '/', mirroring x86 stage2's strcpy_path_loop. mes's include-from-path macro builds paths like "module//srfi/srfi-16.scm" because %moduledir already ends with "/"; without normalisation, find_file's strcmp never matches.
riscv64 setup_page_table sets the A and D bits in every PTE (V|R|W|X (|U) |A|D = 0xDF or 0xCF instead of 0x1F / 0x0F). The riscv64 virt CPU auto-updates these on access, but the SiFive U54 (sifive_u machine) raises an instruction page fault on the first fetch through a PTE with A=0 — that was the sifive_u boot hang. Setting them statically works on both boards; bootstrap code never inspects A/D so the semantics are advisory here.