Wasmtime GitHub notifications bot (Mar 23 2026 at 06:00): Wasmtime GitHub notifications bot (Mar 23 2026 at 06:00):eckertliam opened PR #12824 from eckertliam:issue-12818 to bytecodealliance:main:
Fixes #12818
On aarch64 in non-PIC mode, colocated symbols (non-preemptible linkage like
Local,Hidden,Export) generateadrp+addinstruction pairs viaLoadExtNameNear, producingAarch64AdrPrelPgHi21andAarch64AddAbsLo12Ncrelocations. These were not handled incranelift-object'sprocess_reloc, causing anunimplemented!()panic.Changes
- Add match arms in
process_relocfor both relocations, mapping to the correct ELF (R_AARCH64_ADR_PREL_PG_HI21,R_AARCH64_ADD_ABS_LO12_NC) and MachO (ARM64_RELOC_PAGE21,ARM64_RELOC_PAGEOFF12) relocation types- Add
aarch64_colocated_data_symbol_relocintegration test that exercises the full code path: declares a local data symbol, builds a function that loads its address, and verifies the object file emits successfully- Enable the
arm64feature in cranelift-object dev-dependencies to support the new test:robot: Generated with Claude Code
Wasmtime GitHub notifications bot (Mar 23 2026 at 06:00):eckertliam requested cfallin for a review on PR #12824.
Wasmtime GitHub notifications bot (Mar 23 2026 at 06:00):eckertliam requested wasmtime-compiler-reviewers for a review on PR #12824.
Wasmtime GitHub notifications bot (Mar 23 2026 at 08:29):bjorn3 submitted PR review.
Wasmtime GitHub notifications bot (Mar 23 2026 at 08:29):bjorn3 created PR review comment:
Please sort these next to the other arm64 relocs.
Wasmtime GitHub notifications bot (Mar 23 2026 at 11:55):github-actions[bot] added the label cranelift:module on PR #12824.
Wasmtime GitHub notifications bot (Mar 23 2026 at 11:55):github-actions[bot] added the label cranelift on PR #12824.
Wasmtime GitHub notifications bot (Mar 23 2026 at 14:08):cfallin submitted PR review:
Thanks for this!
In addition to the enum arm ordering pointed out by bjorn3's comment, a high-level thought. Thanks for being straightforward about having used Claude Code for this. I think such tools are fine given the right checks and controls. However for something as low-level and important as binary relocations, I want to make sure we verify in the human layer as well (that is, have a domain expert look at every line). Relying solely on the human PR reviewer (that's me) isn't great either because of the effort asymmetry -- your agent does the work automatically, I have to go Google the Mach-O and ELF relocation specs and make sure it did the right thing. The etiquette around all of this is still evolving but in this case I think I want to ask for the following:
If you don't mind, would you be able to (as a human, without an LLM assisting please):
- Link us to some docs here that describe the ELF and Mach-O relocations;
- Verify yourself that they're the right ones, and that the associated fields are correct (e.g. for a specific case: the
r_length: 2is curious -- that must be the log2 of the size? It looks like the other Mach-O cases do that too? Can you verify?)No need to update the code with any citations or anything -- our other cases don't have anything like that. I just want to make sure we get this right, and also establish a norm of checking an agent's work carefully.
Thanks!
Wasmtime GitHub notifications bot (Mar 24 2026 at 04:15):eckertliam commented on PR #12824:
Thanks for being so welcoming. I will be sure to link these docs when I have a chance. For future cases, what should be gates for agent assisted PRs? I'm a compiler engineer and we've adopted these at my place of work so I'm trying to give them a go to help out in OSS projects as well. Just would like to know if there's anything I could do to make the review process better in the future outside of citations.
Wasmtime GitHub notifications bot (Mar 24 2026 at 05:45):eckertliam updated PR #12824.
Wasmtime GitHub notifications bot (Mar 24 2026 at 06:18):eckertliam commented on PR #12824:
I verified the relocs manually, here are the references:
ELF relocs. ADR_PREL_PG_HI21 is 275, ADD_ABS_LO12_NC is 277. https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#static-aarch64-relocations
This is the reference I found for MachO. PAGE21 = 3, PAGEOFF12 = 4. https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/MachO.h
re r_length: 2: LLVM's AArch64MachObjectWriter.cpp does Log2_32(4) for both. PAGE21 is pcrel, PAGEOFF12 is not. https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/MCTargetDesc/AArch64MachObjectWriter.cpp
Wasmtime GitHub notifications bot (Mar 24 2026 at 15:41):cfallin submitted PR review:
OK, this looks good, thanks!
Re: quality gates for the future -- I think the sort of concerns/questions I raise are mostly relevant when interfacing with an external system/spec of some sort, as we can handle reviews of changes to our own internal implementation/logic much more easily. For externally-interfacing bits, providing citations and an indication you've checked the agent's work are probably more than enough for now.
Thanks again for the contribution!
Wasmtime GitHub notifications bot (Mar 24 2026 at 15:41):cfallin added PR #12824 Implement Aarch64AdrPrelPgHi21 and Aarch64AddAbsLo12Nc relocations in cranelift-object to the merge queue.
Wasmtime GitHub notifications bot (Mar 24 2026 at 16:30):eckertliam commented on PR #12824:
Thank you for the review! Hope to do more in the future.
Wasmtime GitHub notifications bot (Mar 24 2026 at 16:42):cfallin merged PR #12824.
Wasmtime GitHub notifications bot (Mar 24 2026 at 16:44):cfallin removed PR #12824 Implement Aarch64AdrPrelPgHi21 and Aarch64AddAbsLo12Nc relocations in cranelift-object from the merge queue.
Last updated: Apr 13 2026 at 00:25 UTC