Add an x32 relocatable object

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Problem

The x32 ABI is an ELFCLASS32 container whose e_machine is EM_X86_64: the class gives the pointer width and the machine gives the instruction set, and they disagree about the word size. cle's ELF.extract_arch has to decide from both, and no relocatable object here lets a test assert on that decision. Searching every ELF under tests/:

searched 735 ELF objects under tests/ for: ELFCLASS32 container whose e_machine is EM_X86_64
1 match
    tests/x86_64/elfcore_linux_x32.core  --  ET_CORE

The one object with the two fields disagreeing is a core dump, which reaches the ELFCore backend rather than the ordinary one.

Root cause

Nothing emits an x32 object by accident. It takes clang -target x86_64-linux-gnux32, and no fixture here was built that way.

Fix

Add tests/x86_64/x32_relocatable.o — ET_REL, ELFCLASS32, EM_X86_64, 536 bytes. Source and a build script are in tests_src/x32. Compiling to an object needs no x32 libc, so any clang that can target it will do; built here with clang 21 from nixpkgs. Nothing existing is touched.

Testing

tests_src/x32/build.sh under nix shell nixpkgs#clang (clang 21) rebuilds the committed object byte for byte, sha256 b792c4d4873832edf6e998370206812851852b3fee42aa89e73c8a02af21a29b, so the recipe and the artifact agree. The header was read back with readelf -h and independently with pyelftools. This repository has no suite of its own, so the fixture is exercised by the cle change to ELF.extract_arch, which today loads it as <Arch X86 (LE)> — pointer width from the class, instruction set wrong.

Validation: #198 (comment)

session: sharpen

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Validation record for head 4f749ef2629fd2641286b0cc020db8d821f75a7b.

• tests/x86_64/x32_relocatable.o — 536 bytes, sha256 b792c4d4873832edf6e998370206812851852b3fee42aa89e73c8a02af21a29b
• Header: EI_CLASS is ELFCLASS32, e_machine is EM_X86_64 (62), e_type is ET_REL — the class and the machine disagree about the word size, which is the shape the fixture exists for. Read independently with readelf -h and with pyelftools
• Consumer behaviour today: cle.Loader(path, auto_load_libs=False) on cle b58ea02a446106647cdaae32bdf91b7062404cc1 loads it as <Arch X86 (LE)> — it takes the pointer width from the class and gets the instruction set wrong, which is what the ELF.extract_arch change fixes

Caveats: this repository has no test suite, so the record is header verification of the committed artifact plus the load attempt above. Rebuild, 2026-08-28: tests_src/x32/build.sh run under nix shell nixpkgs#clang (clang 21) reproduces the committed object byte for byte, sha256 unchanged at b792c4d4873832edf6e998370206812851852b3fee42aa89e73c8a02af21a29b; this supersedes the earlier note that the script had not been rerun.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Searching every ELF object under tests/ for an ELFCLASS32 container whose e_machine is EM_X86_64, before and after this change.

Before — the only object with the two fields disagreeing is a core dump, which reaches a different loader path:

angr/binaries at the merge base

angr/binaries at baseline 8646be4
searched 735 ELF objects under tests/ for: ELFCLASS32 container whose e_machine is EM_X86_64
1 match
    tests/x86_64/elfcore_linux_x32.core  --  ET_CORE

After — a relocatable object with the same disagreement, which is what the arch-selection path reads:

with this change

angr/binaries at head 4f749ef
searched 736 ELF objects under tests/ for: ELFCLASS32 container whose e_machine is EM_X86_64
2 match
    tests/x86_64/elfcore_linux_x32.core  --  ET_CORE
    tests/x86_64/x32_relocatable.o  --  ET_REL