x32 binaries are analyzed as 32-bit x86

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

The x32 ABI — ELFCLASS32 containers holding `EM_X86_64` code — is loaded as 32-bit x86, so the 64-bit instruction stream does not decode. Measured across a large corpus against the binaries' own symbol tables, this accounts for 20 objects and 425 function symbols with no block at their entry.

`arch_from_id` lowercases the machine name and matches `"em_x86_64"` against the x86 pattern, and `bits=32` then excludes `ArchAMD64`, so `ArchX86` wins. Everything using a REX prefix or 64-bit operand size lifts incorrectly or not at all, and `drop_bad_functions` removes the affected functions afterwards, so the loss is silent rather than reported.

As with MIPS o32/n32 on a 64-bit ISA, the underlying problem is that archinfo ties pointer width to register width. x32 needs AMD64 decoding with 32-bit pointers.

The question is whether archinfo should express that, or whether CLE should refuse the file with a clear error instead of analyzing it as x86. Silently recovering a fraction of the code seems the worst available option.

`gcc -mx32` reproduces it without needing any particular corpus.

The MIPS issue filed alongside this one is the same decision on a different architecture.