Implement Aarch64AdrPrelPgHi21 and Aarch64AddAbsLo12Nc relocations in cranelift-object

[eckertliam]

Fixes #12818

On aarch64 in non-PIC mode, colocated symbols (non-preemptible linkage like Local, Hidden, Export) generate adrp+add instruction pairs via LoadExtNameNear, producing Aarch64AdrPrelPgHi21 and Aarch64AddAbsLo12Nc relocations. These were not handled in cranelift-object's process_reloc, causing an unimplemented!() panic.

Changes

• Add match arms in process_reloc for 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_reloc integration 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 arm64 feature in cranelift-object dev-dependencies to support the new test

🤖 Generated with Claude Code

[cfallin]

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: 2 is 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!

[eckertliam]

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.

[eckertliam]

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

[cfallin]

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!

[eckertliam]

Thank you for the review! Hope to do more in the future.