'tricore' arch disassembler outputs 'nop' for any opcode

[onesk]

on 881960bd21f091efe42b073b0011296f5f67ad0d:

rasm2 -a tricore -d 200a

returns 'nop', while it should return "sub.a sp, 10" as mentioned in the #4644

Trying r2 & rasm2 on real Tricore binaries returns nothing but a bunch of 16 bit 'nops':

0xa000205c f713 nop 0xa000205e 0100 nop 0xa0002060 0f02 nop 0xa0002062 0000 nop 0xa0002064 7cb1 nop 0xa0002066 0880 nop 0xa0002068 f813 nop 0xa000206a 0200 nop

Issue persists on macOS builds 1.1.0 & 1.2.0 too.

[onesk]

My limited debugging shows that the problem is in _tricore_buffer_readmemory function, and it is almost the same one that caused #4644 - the guard condition is too restrictive and sometimes would not copy the bytes to the temporary buffer. The patch from the mentioned issue (e0610dcba72ead0cdc2fbc742f32cbf56fbfbe2a), while not being safe bounds-wise, does not suffer from this problem.

[wargio]

i think it's missing an = after the >. i'll let you know

[onesk]

@wargio i tried this as my first attempt, but all the commands seem to have zero-valued immediate args then, like if the first opcode byte is fetched ok and the next ones are still wrongly zero

[wargio]

By changing that if (https://github.com/radare/radare2/blob/master/libr/asm/p/asm_tricore.c#L21) i got this:

[0x00000000]> pd 10
            0x00000000      f713           .hword 0x00f7
            0x00000002      01000f02       mov.aa a0, a0
            0x00000006      0000           nop
            0x00000008      7cb1           jnz.a a0, 0x00000008
            0x0000000a      0880           ld.bu d0, [a15]0
            0x0000000c      f813           st.a [sp]0, a15
            0x0000000e      0200           mov d0, d0

$ rasm2 -a tricore -d 0xf71301000f0200007cb10880f8130200
.hword 0x00f7
mov.aa a0, a0
nop
jnz.a a0, 0x00000008
ld.bu d0, [a15]0
st.a [sp]0, a15
mov d0, d0

[onesk]

@wargio i do disagree, here is the test:

• your patch

  % rasm2 -a tricore -d d916606c lea a0, [a0]0

• the patch from #4644

  % rasm2 -a tricore -d d916606c lea a6, [a1]-14944

The latter is correct. To illustrate the problem

% rasm2 -a tricore -d d9000000 lea a0, [a0]0

[wargio]

Yeah, i noticed that too. i'm looking into it. There must be some other changes that were made.. :|

[wargio]

@onesk please check again for regressions, now should work.

> rasm2 -a tricore -d d916606c
lea a6, [a1]-14944
> rasm2 -a tricore -d 200a
sub.a sp, 10

[onesk]

@wargio your tricore_bug2 branch works okay on my Tricore binaries.

[wargio]

Good.

[wargio]

Can you provide a simple tricore bin?

[Maijin]

That would be super useful for the testsuite !