Some mips64 binaries have ELFCLASS32

irsb = pyvex.IRSB('\xdf\xbf\x00\x18\xdf\xbc\x00\x10\xdf\xb1\x00\x08\xdf\xb0\x00\x00', 0x5193c, archinfo.ArchMIPS32('Iend_BE'), opt_level=0)

gives:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/workspace/angr-dev/pyvex/pyvex/block.py", line 64, in __init__
    lift(self, data, max_bytes, max_inst, bytes_offset, opt_level, traceflags)
  File "/home/user/workspace/angr-dev/pyvex/pyvex/lift/__init__.py", line 100, in lift
    raise PyVEXError('\n\n'.join(errors))
pyvex.errors.PyVEXError: 
vex: priv/guest_mips_toIR.c:1219 (putIReg): Assertion `typeOfIRExpr(irsb->tyenv, e) == ty' failed.

The bytes should be:

0x5193c ld      $ra, 0x20+var_8($sp)
0x51940 ld      $gp, 0x20+var_10($sp)
0x51944 ld      $s1, 0x20+var_18($sp)
0x51948 ld      $s0, 0x20+var_20($sp)

(ODA confirms)

[rhelmot]

ok that one was weird. there were actually two bugs, one in pyvex, one in vex, intersecting very weirdly. The bug in pyvex was that we were claiming that our emulated mips cpu was baseline, which was causing MIPS to mark your cins32 instruction as undecodable. The second bug was that vex will assert out if it hits an undecodable instruction found in the branch delay slot. I’ve fixed both of these, you’ll need to pull the newest pyvex and vex.

[github-actions[bot]]

This issue has been marked as stale because it has no recent activity. Please comment or add the pinned tag to prevent this issue from being closed.