No arch expresses a 64-bit MIPS ISA in a 32-bit ELF container

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Measuring CFG recovery against binaries' own DWARF line tables, symbol tables and `.eh_frame` across a large corpus turned up a class where angr recovers nothing for large parts of an object, and the cause is that no `Arch` can describe the file. It is the single largest source of missed code in that measurement: 36 objects, 859 function symbols with no block at their entry, and 12,439 line-table addresses covered by no block.

The files are ELFCLASS32 MIPS binaries whose `e_flags` report `EF_MIPS_ARCH` of MIPS3 or later — the o32 and n32 ABIs on a 64-bit ISA. `arch_from_id("EM_MIPS", bits=32)` returns `ArchMIPS32`, so `ld`, `sd`, `daddiu` and the rest of the 64-bit instructions fail to decode. Lifting fails per block, and angr's `drop_bad_functions` then removes the surrounding functions, so the result is silent: the CFG simply has a hole where a third of the code was.

Pointer width and register width are not the same thing here, and archinfo currently ties them together. o32/n32 on MIPS III+ needs 64-bit registers with 32-bit pointers, which no existing arch expresses.

The question is whether archinfo should grow that combination, or whether these files should be rejected at load time with a clear error rather than analyzed as MIPS32 and quietly under-recovered. The present behaviour is the worst of the three, because nothing reports a problem.

A reproducer needs no special corpus: `mips64-linux-gnu-gcc -mabi=32 -march=mips64r2` produces an ELFCLASS32 object with `EF_MIPS_ARCH` set to MIPS64, and any function using a 64-bit instruction will be missing from the recovered CFG.

angr/archinfo#369 is the same shape on a different architecture and probably wants the same answer.