Compile patch code for the target architecture, not the build host

[xintenseapple]

Addresses #39. (Deliberately not using a closing keyword — please close the issue yourself if you take this, or close it in favour of your own fix.)

Summary

ElfAmd64Linux and ElfX86Linux pass no --target triple to clang, so InsertFunctionPatch / ModifyFunctionPatch compile the patch body for the build host rather than the binary being patched. On a non-x86 host that writes a function in the wrong instruction set into the target at full size, with nothing raised anywhere. On an x86 host the omission is invisible because the host default happens to match.

-m32 on ElfX86Linux is worth calling out separately: it reads as architecture-selecting but only sets the width, so on an arm64 host it produces 32-bit ARM.

Changes

1. Pin the triple — matching the targets that already do:

Target	Flag
elf_amd64_linux (clang, clang19)	-target x86_64-linux-gnu
elf_x86_linux	-target i386-linux-gnu (replaces -m32)
elf_amd64_linux_recomp	-target x86_64-linux-gnu
elf_arm_linux_recomp	-target arm-linux-gnueabihf

The two _recomp variants had the same gap. Their -emit-llvm step embeds the triple in the .ll, so pinning the compiler flag fixes the downstream llc invocation too.

2. Check the compiled object's machine against the target's, and raise on a mismatch.

Compiler.check_object_arch() compares the object's e_machine, EI_CLASS and EI_DATA against the target's expectation, raising ObjectArchMismatchError. It is called from both Compiler.compile and LLVMRecomp.compile at the point where the ELFFile handle is already open for the .rodata section walk, so the header read costs nothing.

This is the part that matters more than (1): a wrong-ISA patch that reports success is the worst failure mode available here, and it is not detectable from the patcherex2 API by a caller. The check also covers a target whose triple is wrong rather than missing, and any future host/target divergence.

Targets declare their expectation via a new Target.expected_object_arch; None (the default) skips the check, so nothing is imposed on targets that do not opt in. All targets now declare one — the ARM-derived (elf_arm_bare, elf_arm_mimxrt1052) and _recomp targets inherit theirs from their base class.

IHexRiscv32Bare and BinPpcPegasos2Bare already pinned their triples correctly and were never affected by the bug; they just had no expectation, so they got no check. Their declared values were verified against what clang actually emits for their real compiler flags rather than inferred from the triple.

Verification

Reproduced and fixed on a native arm64 Linux host (clang 15), the condition from the issue:

Flags	Resulting machine
old amd64 (none)	EM_AARCH64 ✗
new -target x86_64-linux-gnu	EM_X86_64 ✓
old x86 -m32	EM_ARM ✗
new -target i386-linux-gnu	EM_386 ✓

With the triple reverted, the new check raises instead of emitting a silently broken patch:

Compiled patch code does not match the target architecture
(e_machine: expected EM_X86_64, got EM_AARCH64). This usually means the
compiler is missing or has the wrong target triple, and the patch would
not run on the binary being patched. Compiler flags: []

New tests in tests/test_compiler_arch.py (42 passing) cover wrong machine, wrong class, wrong endianness, the no-expectation passthrough, that every target declares an expectation consistent with the binaries it detects, and that each target's configured compiler emits an object for its own architecture. They drive the compiler with a stub p rather than a full Patcherex, so they do not depend on a binary analyzer.

test_every_registered_target_declares_expectation guards the gap that let the two newer targets slip through: a missing expectation silently disables the check rather than erroring. I confirmed it fails when a declaration is removed, rather than passing vacuously.

Full suite on this branch: 506 passed, 67 skipped, 0 failed (all architectures, both angr and ghidra). ruff format --check and ruff check clean.

This touches no files that d9106f4 (#37) touched — utils.py is untouched here.

Note

IHexRiscv32Bare is absent from targets/__init__.py, so it never registers in Target.target_classes; the new coverage test cannot see it and Target.detect_target cannot reach it either. Pre-existing and out of scope for this PR — its expectation is set regardless — but it likely wants a one-line fix separately.

🤖 Generated with Claude Code