update yaxpeax-arm to 0.5.0

[iximeow]

I and several other contributors have fixed a large slate of ARMv7/thumb decoding bugs upstream. there are a number of places in sp-emu that note bugs in yaxpeax-arm and otherwise include in-tree ad-hoc decoding to work around not fixing those issues upstream; many of those can probably be removed now, but I'm not sure what all of them are nor what relevant testing is to know if there were load-bearing bugs that were fixed here.

I'm not sure what all the places where sp-emu is working around upstream bugs are, or if all of them are commented as such, and given that most workarounds are "sp-emu will decode the bytes itself", presumably "reverting to using upstream as bugs are fixed" is not entirely straightforward.

---

this change is mostly a heads up about the update. I've run cargo build and cargo test with this change, and everything seems ok. but the existing behavior for what was RRX rotates seems incorrect, so I'm not sure how much of the ISA the test suite covers.

in the RRX case, it should shift by one bit, rather than return v directly, so I assume no test program nor current Hubris build uses that particular rotate form in a codepath that sp-emu is asked to exercise.. you may want to re-evaluate the emulator or the necessity of workarounds in decoding with whichever tools (Claude?) you'd here.

[sion42x]

Thanks for hopping in! This change is fine for the SP images because of the redecodes you mentioned, but I can definitely go through all the instances of those and remove the ones where 0.5 comes back clean. And can add more tests as well.

Where this will be a problem is in the RoT side since that code ended up using the workarounds after a decode-error which won't happen in 0.5 (they'll hit a trap instead). @lzrd can you please confirm this one? Even with cargo test I don't think we can trust the result because the tests never boot a RoT. But we could add tests that step various instructions to validate that they don't fail (e.g. ldaexb. I'd check that before we merge this in.

Back to the RRX point, I believe as you mentioned Hubris only uses standalone RRX and we only use what Hubris uses. But it's still a bug and I'll get it fixed.

[lzrd]

Was a search done for rrx instructions in rot binaries?

[iximeow]

the rrx instruction is different from the rrx rotate mode, which is encoded like "ror 0". previously, yaxpeax-arm did not decode "ror 0" into rrx as an ARM core would interpret it, which was both a bug and left the correct handling of that case up to library users. the handling of Opcode::RRX seems plausible to me - that sure looks like a rotate right by one bit, anyway - but the handling of something like add r4, r3, r7 rrx where rrx is a shift style is what seems like it's been wrong before and after.

[lzrd]

I built a RoT image from app/oxide-rot-1/app-dev.toml, had Claude search for RRX:

● Certain. Three independent checks, all zero:

  1. Proper disassembly of every constituent ELF, each with correct arch and real code sections: the
     10 task ELFs, the kernel, and the endoscope binary disassembled as thumbv7em-none-eabihf
     (Cortex-M7, its own ELF at target/bindeps/swd/thumbv7em-none-eabihf/release/endoscope). Zero
     rrx/rrxs.
  2. Forced linear Thumb disassembly of the flat .sec1 blob in each final.elf (~78,500 lines). Zero.
  3. An exhaustive bit-pattern scan of all 206,888 bytes of each final.bin at every even offset,
     independent of any disassembler sync. RRX only exists as one encoding family: the 32-bit Thumb-2
     data-processing shifted-register form, hw1 & 0xFE00 == 0xEA00 with hw2 shift type 0b11 and
     imm3:imm2 == 0. Zero candidates in either image.

  On the endoscope point: it is Cortex-M7 code, but RRX's encoding is identical in Thumb-2 on ARMv7-M
  and ARMv8-M, so check 3 covers it whatever arch produced the bytes, and check 1 disassembled it with
  the right arch anyway. A32 RRX encodings do not apply since both parts are Thumb-only.

[sion42x]

@lzrd I think the RoT and bootleby are still going to have issues here. The RRX case was only one case. I was specifically commenting on the v8-M family of instructions.

[sion42x]

Okay, there are 31 spots in oxide-rot-1 a and b using ARMv8-M load-acquire and store-release instructions. In 0.4 they were rejected, and sent to sp-emu's try_v8m workaround handler.

In 0.5 they decode successfully with no operands, and will fall through to an unimplemented-instruction trap.

The bootleby image also has 2 such instructions, ldaexb and stlexb. That's the thing I was saying cargo test can't see because nothing boots a RoT.

If it's better to stick with a workaround till we can absorb all the new new with yaxpeax-arm 0.5, we'd want to route all LDA/LDAB/LDAH/STL/STLB/STLH/LDAEX*/STLEX* opcodes into try_v8m explicitly instead of counting on their failure.

[sion42x]

As for the RRX side you're right, the RoTs and bootleby don't use RRX. net, ignition, monorail, and sequencer do, but they're all using the standalone mov.w rd, rm, rrx form which is unaffected.