RH850 branch disasembly not correct

[veskohard]

Hi am trying to disassemble a Renesas rh850(using v850 language) dump and have bad branch result:

GHIDRA: ROM:00196748 f9 07 49 fe ld.hu -0x1b8 [r25 ],r0=>DAT_fffffe49

Here is correct disassembly:

IDAPRO: ROM:00196748 F9 07 49 FE bnc lab_196590

TRACE32: ROM:00196748 07F9FE49 bnl 0x196590

[GhidorahRex]

According to the instruction manual, bcond matches the bits ddddd101 1dddcccc.

The condition code, cccc for nc would be 1001.

Looking at the displacement above, the addresses look like they are in hex, the jump is -0x1B8 (0x196590-0x196748), which requires 10 bits - but the limit is 9 bits for the bcond instruction. If they're decimal and the labeling of the instructions on Trace32 sample is just wrong. That makes it -158 or 10110001, broken into two pieces 10110 and 001. The full instruction becomes 10110101 10011001 or b5 99. Either way, it doesn't seem to match.

I get a bnc if I swap the 07 byte for 05. bcond instructions should only consume two bytes, so that would be f9 05. I'll have to dig into this further. It's not an endianness issue - there's no permutation of the bytes in f9 07 49 fe that would match the bits in the v850 instruction set description for bcond to get the opcode x101 1xxx.

[veskohard]

Another one example: GHIDRA: ROM:0005aff6 e9 07 21 01 ld.hu 0x120 [r9],r0

IDAPRO: ROM:0005AFF6 E9 07 21 01 bnc loc_5B116

TRACE32: ROM:0005AFF6 07E90121 bnl 0x5B116

Processor is: R7F701418

[GhidorahRex]

Apparently there's a variant of bcond that has a 17-bit jump, that one is the one that's not being disassembled.

[veskohard]

I found it documented: Bcond disp17 https://www.renesas.com/us/en/document/mas/rh850g3kh-users-manual-software Page161

is there any way to add it to ghidra processor module (Special.sinc)?

[mumbel]

ah here is the conflict in ld.hu ... rrrrr != 00000 (Do not specify r0 for reg2.)

[mumbel]

looking at the remark section for the overview of instructions, potential problematic instructions include:

• dispose
• divh
• fetrap <- good maybe
• jarl
• ld.bu
• ld.hu
• mov <- good maybe
• movea <- good maybe
• movhi <- good maybe
• mulh
• mulhi
• satadd <- good maybe
• satsub <- good maybe
• satsubi <- good maybe
• satsubr <- good maybe
• sld.bu
• sld.hu
• switch
• adf
• sbf

[GhidorahRex]

is there any way to add it to ghidra processor module (Special.sinc)?

@veskohard Yes, I'll get a fix in. There's a two other instructions that should be added, especiallyjarl [reg1], reg3. I'm testing a patch now that should work. If you want to try it out, add the following to Special.sinc:

# Should be moved to Extras.sinc
adr17: res is  s0404; s1731
[ res = ((s0404 << 16) | (s1731 << 1)) + inst_start; ] 
{ 
    export *:4 res; 
}

#Bcond adr17 - 00000111111DCCCC|ddddddddddddddd1
:b^c0003 adr17 is (op0515=0x3F & c0003; op1616=1) & adr17
{
    if (c0003) 
        goto adr17;
}

and add the token to instr token(16) : s0404 = (4,4) signed

Let me know if that fixes it for you. Collision between this instruction and ld.hu shouldn't be an issue since specifying the bits explicity in bcond overrides the unspecified subconstructor R1115. But if it does become an issue, we can solve it with some context. There's several places in the code where it's being used in the V850, but I don't think it's needed for most of them. If we do it too much it can cause issues with the number of instructions, so we try to avoid it as much as possible.

[darkleon78]

Hi mate. Is there any way to get patched files with fixed disassembling code for jarl [reg1],reg3 instructions? Code above looks like fix for Bcond instructions but not for jarl [reg1], reg3...

Thanks

[GhidorahRex]

Add

# JARL [reg1], reg3 - 11000111111RRRRR|WWWWW00101100000
:jarl [R0004] R2731 is op0515=0x63F & R0004; op1626=0x160 & R2731
{
    R2731 = inst_next;
    call [R0004];
}

I haven't had time to thoroughly review the change, but that should be good.

[darkleon78]

It's works perfectly. Thank you!

[darkleon78]

Hi guys. Another one problem found in ghidra RH850 disassemble. bins assebler command can't be recognized by ghidra example from IDA: f3 0f dc 90 bins r19, 0x6, 0x4, r1

[GhidorahRex]

@darkleon78 This is a known issue. Currently, the v850 module only supports v850 instructions. We don't support any of the rh850-only instructions currently, although there are plans to add them in the near future.

[esaulenka]

@veskohard, @darkleon78 Hello guys, you can try my implementation of V850 / RH850 language. Due some historical reasons it is not a part of Ghidra. It covers more variants of 850 cores, but I am too lazy to push my changes to the main Ghidra branch. I don't have any real binaries from modern RH850 devices, but I hope it works well enough.

[darkleon78]

@veskohard, @darkleon78 Hello guys, you can try my implementation of V850 / RH850 language. Due some historical reasons it is not a part of Ghidra. It covers more variants of 850 cores, but I am too lazy to push my changes to the main Ghidra branch. I don't have any real binaries from modern RH850 devices, but I hope it works well enough.

Hi. It's good idea, i trying but i don't have enough expirience with compile slegh and always got error on complie. May be we can contact directly? In Telegram? Give me a link or contact with me please in Telegram @Darkleon78 Thank you