[phix33]

Your checklist for this pull request

• I've documented or updated the documentation of every API function and struct this PR changes.
• I've added tests that prove my fix is effective or that my feature works (if possible)

Detailed description

Follow-up to #3142. On v5, Sparc ldstub fails to decode:

$ cstool sparc c26e2028
ERROR: invalid assembly code
$ cstool sparc c26e001a
ERROR: invalid assembly code

These should be ldstub [%i0+0x28], %g1 and ldstub [%i0+%i2], %g1 and next decodes them correctly. As with ldd/std, the v5 decoder table has no entry for it nor does it have an instruction id for it.

Resolved by:

• The [v5] Sparc: decode integer LDD and STD #3142 fallback (renamed decodeMemFallback) now also accepts op3 0x0d, with two new internal opcodes appended after the existing ones.
• A new public id SPARC_INS_LDSTUB was appended after SPARC_INS_RETL so no existing id moves.

The new id is the only API change, which is why this is separate from #3142. If you'd rather not touch the v5 enum, ldstub could map to an existing id instead (although cs_insn_name would then return the wrong name).

Test plan

Three lines in suite/MC/Sparc/sparc-atomic-instructions.s.cs which fail before this change. The cstest Sparc detail output has no instruction id, so the id is checked with cstool only:

$ cstool -d sparc c26e2028
 0  c2 6e 20 28  ldstub	[%i0+0x28], %g1
	ID: 279 (ldstub)

Closing issues

None.

[phix33]

Sorry I opened this against next by accident then switched but looks like it picked up the 'wrong' labels but I can't edit. I can close and reopen if need be. Sorry for hassle.