Wrong disasm m68k

[alex-bender]

Hello. I'm having problems with m68k binary, the disasm output is tend to be wrong.
Details are here: radareorg/radare2#17047

From running this ./cstool/cstool m68k 61ff00000bea I see:

0  61 ff  dc.w $61ff
2  00 00 0b ea  ori.b  #$ea, d0

I'm expecting bsr.l out of that 61 ff 00 00 0b ea

Could it be some configuration issue?

[aquynh]

@emoon do you have any comments?

[ret2libc]

By the way, right output:

$ rasm2 -a m68k.net -b 32 -d 61ff00000bea
bsr.l 0xbec

wrong output:

$ rasm2 -a m68k -b 32 -d 61ff00000bea
invalid
ori.b 0xea, d0                

[emoon]

Hi, so there are two problems here.

1. The bsr.l instruction is only supported on 020+ CPUs which generates the the first output listed above. The above test seems to be have done in 000 mode (I have no idea how radare uses capstone)
2. There was a bug where bsr.l wouldn't read enough data thus next instruction would be wrong, this has been fixed in Fixed incorrect read of 32-bit imm for bsr #1644

[ret2libc]

@emoon with your fix I see:

./cstool/cstool m68k40 61ff00000bea
 0  61 ff 00 00 0b ea  bsr.l    $bec

Did I select the correct architecture? Also, is $bec expected? Another disassembler in r2 says bsr.l 0xbec, but I'm not really familiar with m68k, so I'm just asking.

[emoon]

Yeah 040 supports long branches (it's the 000 and 010 generation that doesn't)

$bec is correct. It may look a bit strange but the opcode size (61 ff) that is 2 bytes is "added" to the immediate value.

[ret2libc]

@emoon but shouldn't it be something like $0xbec (instead of $bec)?

[emoon]

$ is used in many assemblers as hex.

[ret2libc]

I see, thanks for the answer. As said, I'm not really familiar with this arch, and in x86 it is not used AFAIK. I think this can be closed then, thanks for the prompt fix!

[alex-bender]

Thanks all!