search

capstone-engine / capstone

Capstone disassembly/disassembler framework for ARM, ARM64 (ARMv8), Alpha, BPF, Ethereum VM, HPPA, LoongArch, M68K, M680X, Mips, MOS65XX, PPC, RISC-V(rv32G/rv64G), SH, Sparc, SystemZ, TMS320C64X, TriCore, Webassembly, XCore and X86.
http://www.capstone-engine.org
7.53k stars 1.55k forks source link

PPC ins.opstr flaw for displacement of 0 #534

Closed kevemueller closed 2 years ago

kevemueller commented 8 years ago

On the PowerPC architecture Capstone 3.0 decodes 0x80010000 as

ins.mnemonic: lwz ins.opstr: r0, (r1)

The GNU assembler v2.25 does not accept lwz r0, (r1), it expects lwz r0, 0(r1), i.e. the correctly determined displacement value of 0 needs to be emitted into the opstr, as it is already done for any non zero displacement value.

radare commented 8 years ago

Comparing Capstone vs GNU disassemblers:

$ rasm2 -a ppc -b32 -e -d 0x80010000
lwz r0, (r1)
$ rasm2 -a ppc.gnu -b32 -e -d 0x80010000
lwz r0, 0(r1)

The default syntax of Capstone is not the same as the default one from GNU, which is AT&T compatible. Imho the syntax provided by Capstone should be valid and it should be supported by the GNU assembler, not the other way. We can probably handle the AT&T syntax in the PPC disassembler of capstone in order to make the output compatible with the GNU assembler.

kevemueller commented 8 years ago

Checked and agreed. Capstone is emitting an AT&T syntax compliant statement, hence it is correct. Due to the widespread use of GAS, it would still be convenient if Capstone could support the apparent flaw of GAS in this respect, i.e. via a CS_OPT_SYNTAX_GAS. As that might be an overkill, adding the 0 displacement in the AT&T mode - still a valid AT&T syntax - would not hurt that much.