Add Mach-O relocatable object fixtures

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Problem

The repository carries Mach-O executables, dylibs and one kext, but no
MH_OBJECT, so nothing covers the relocatable-object load path. On master both
paths are absent:

CLEFileNotFoundError: Could not find file .../tests/aarch64/relocatable_object.macho
CLEFileNotFoundError: Could not find file .../tests/x86_64/relocatable_object.macho

Root cause

Every Mach-O here was added as a whole program or library, and MH_OBJECT is
an intermediate a build normally deletes, so the filetype never arrived on its
own.

Fix

Adds tests/aarch64/relocatable_object.macho (920 bytes) and
tests/x86_64/relocatable_object.macho (792 bytes), the same freestanding
source built for both architectures. Freestanding on purpose: compiling to an
object never resolves headers, so tests_src/macho_relocatable/build.sh needs
only a clang that can target Apple, and no SDK. Both are one unnamed segment
holding __text and __bss, which is the shape that distinguishes an object
from every other Mach-O here.

Testing

Read back, each carries __text and __bss and four symbols —
_keccak_init, _keccak_absorb, _keccak_squeeze and _state — and cle at
master refuses both with CLECompatibilityError: Unsupported Mach-O file type: 1. With cle 787, which teaches the Mach-O backend to load MH_OBJECT,
the aarch64 object maps [0x0:0x1e7] and the x86_64 one [0x0:0x1c7], with
__bss following __text in each.

Validation: #193 (comment)

session: sharpen

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Validation record for head af665c9f4fcf7247694053e74ca178450343a46b.

• tests/aarch64/relocatable_object.macho — 920 bytes, sha256 3c904d858490966bff53d168a28f38b7d9a6b86358bd3a504386a5da054e0ebe; header reads MH_MAGIC_64, cputype CPU_TYPE_ARM64 (0x0100000c), filetype 1 (MH_OBJECT)
• tests/x86_64/relocatable_object.macho — 792 bytes, sha256 263cba44d8604a82315e0c47c5c89877c013cef61c7f1fd15712776e542c2cec; cputype CPU_TYPE_X86_64 (0x01000007), filetype 1 (MH_OBJECT)
• Rebuild: running tests_src/macho_relocatable/build.sh reproduces both committed files byte for byte, offline, with a clang that can target Apple and no SDK
• Consumer behaviour today: cle.Loader(path, auto_load_libs=False) on cle b58ea02a446106647cdaae32bdf91b7062404cc1 raises CLECompatibilityError: Unsupported Mach-O file type: 1 for both files, which is the gap the Mach-O backend change closes

Caveats: this repository has no test suite, so the record is header verification of the committed artifacts, a byte-for-byte rebuild from the committed source, and the load attempt above. Nothing here exercises the unmerged loader change itself.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Both added objects loaded with the cle branch that consumes them, cle 787, so
the only thing that differs between the two sides is whether the fixtures are
present. The command is the same on both sides:

import cle
ld = cle.Loader(path, auto_load_libs=False)
m = ld.main_object
print(type(m).__name__, m.arch, hex(m.min_addr), hex(m.max_addr))
print([(s.name, hex(s.vaddr), hex(s.memsize)) for s in m.sections])
print([(s.name, hex(s.rebased_addr)) for s in m.symbols])

Before — neither object is in the repository, so the MH_OBJECT path has
no input:

angr/binaries master

tests/aarch64/relocatable_object.macho:
  not present in this checkout
tests/x86_64/relocatable_object.macho:
  not present in this checkout

After — both load as MH_OBJECT, one unnamed segment holding __text and
__bss, with the four symbols the source defines:

with this change

tests/aarch64/relocatable_object.macho:
  920 bytes
  backend MachO  arch <Arch AARCH64 (LE)>  mapped [0x0:0x1e7]
  section __text   vaddr 0x000000 memsize 0x0120
  section __bss    vaddr 0x000120 memsize 0x00c8
  symbol  ltmp0            0x000000
  symbol  _keccak_init     0x000000
  symbol  _keccak_absorb   0x00002c
  symbol  _keccak_squeeze  0x0000a8
  symbol  _state           0x000120
  symbol  ltmp1            0x000120
tests/x86_64/relocatable_object.macho:
  792 bytes
  backend MachO  arch <Arch AMD64 (LE)>  mapped [0x0:0x1c7]
  section __text   vaddr 0x000000 memsize 0x00f9
  section __bss    vaddr 0x000100 memsize 0x00c8
  symbol  _keccak_init     0x000000
  symbol  _keccak_absorb   0x000030
  symbol  _keccak_squeeze  0x000090
  symbol  _state           0x000100

With cle at master both are refused instead, with
CLECompatibilityError: Unsupported Mach-O file type: 1.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

cle master is red, and this branch holds one of the two fixtures it is waiting
on.

angr/cle#787 merged at 2026-09-03T17:48:10Z as
3812052df2ad284cd16684fb7b7eb66e8d14dc6d. Its new test loops over aarch64
then x86_64, loading relocatable_object.macho for each. Both files exist only
on this branch: at binaries master 3de2c41a297606c45be7985aa09b3ae615424d61,
GET /repos/angr/binaries/contents/tests/aarch64/relocatable_object.macho and
GET /repos/angr/binaries/contents/tests/x86_64/relocatable_object.macho both
return 404. So on cle master it raises on the first iteration:

FAILED tests/test_macho.py::test_relocatable_object - cle.errors.CLEFileNotFoundError: Could not find file .../binaries/tests/aarch64/relocatable_object.macho

Read from cle CI run 33786713158, job Test macos-15 (id 100753147049), at cle
master head 3812052df2ad284cd16684fb7b7eb66e8d14dc6d; the ... stands in for
/Users/runner/work/cle/cle/cle/tests/../... The same failure appears in that
run's Test (Pyodide) job and in its ci / Test (2) shard. On a push to master
the cle workflow always takes angr/binaries at master --
actions/binaries-ref reads the pull-request body, which a push does not have,
and resolve_refs.py skips its branch match when the branch is master -- so
no branch or pull-request reference can supply the files instead.

Merging this branch clears that one. It does not make cle master green by
itself: angr/cle#808 merged at 2026-09-03T17:44:30Z and needs
#224 for tests/aarch64/langdetect_go.macho. Both binaries pull
requests have to land.

Head here is 82c153d08ec98310db9a2b5ce35fed76c4949859, which GitHub reports
mergeable and clean against binaries master
3de2c41a297606c45be7985aa09b3ae615424d61, and not behind it.