esaulenka / ghidra_v850 Goto Github PK

Ghidra can not disassemble the code "e05f 2000".
The code is disassembled to "ldsr r0, FPEC".
I add "FPEC" by changing "_" after "FPCFG" to "FPEC" in 2 sections "@elif defined(V850E3)" in v850_common.sinc.

The project doesn't contain an opinion file, that is required for the analyzeHeadless for loading file an ELF.

Hello

With Ghidra version 10.1.4 it compiles the slaspec file itself when you first select the language. V850E2 worked fine, I get this error with V850E3. Please advise ?

Errors compiling C:\ghidra_10.1.4_PUBLIC\Ghidra\Extensions\ghidra_v850-master\data\languages\v850e3.slaspec -- please check log messages for details
ghidra.app.plugin.processors.sleigh.SleighException: Errors compiling C:\ghidra_10.1.4_PUBLIC\Ghidra\Extensions\ghidra_v850-master\data\languages\v850e3.slaspec -- please check log messages for details
at ghidra.app.plugin.processors.sleigh.SleighLanguage.reloadLanguage(SleighLanguage.java:506)
at ghidra.app.plugin.processors.sleigh.SleighLanguage.initialize(SleighLanguage.java:145)
at ghidra.app.plugin.processors.sleigh.SleighLanguage.(SleighLanguage.java:111)
at ghidra.app.plugin.processors.sleigh.SleighLanguageProvider.getNewSleigh(SleighLanguageProvider.java:112)
at ghidra.app.plugin.processors.sleigh.SleighLanguageProvider.getLanguage(SleighLanguageProvider.java:99)
at ghidra.program.util.DefaultLanguageService$LanguageInfo.lambda$getLanguage$0(DefaultLanguageService.java:385)
at ghidra.util.task.TaskBuilder$TaskBuilderTask.run(TaskBuilder.java:306)
at ghidra.util.task.Task.monitoredRun(Task.java:134)
at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:106)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

Build Date: 2022-May-19 0956 EDT
Ghidra Version: 10.1.4
Java Home: C:\Program Files\Java\jdk-11.0.7
JVM Version: Oracle Corporation 11.0.7
OS: Windows 8.1 6.3 amd64

Trying to compile v850e3.slaspec with "sleigh.bat" under "support" folder of Ghidra 10.1.2. but sleigh.bat reports ERROR regarding symbol duplication. It looks like a double-definition of SCBP and SCCFG in the file of v850e3.sinc and v850_common.sinc, which are both included in v850e3.slaspec.

Can you please advise and help? Thanks.

Ghidra can not disassemble the code "e05f 2008" and "e067 2008".
They are disassembled to "ldsr r0, SCCFG,1" and "ldsr r0, SCBP,1".
I change "_ _" after "TCSEL" to "SCCFG SCBP" in the section "attach variables [ SR0004_1 SR1115_1 ] []" in v850e3.sinc.

Is it possible to improve callt parsing according to spec?

For support this feature, user can set CTBP value in some Proccessor specific dialog in Ghidra.
Value can be found in assembly:

If CTBP value is set, then Ghidra can set labels to subroutines instead of imediate value in callt.

Also there is a Global Pointer (GP / r4) register. But I don't know, how it can be useful for analyzing.

Thank you for you work!

Firmware dump for test you can find here https://www.mynissanleaf.com/viewtopic.php?t=32034

Hello, sorry for the maybe stupid question. But what is this repo exactly? Is there a processor which is already in Ghidra public release? v850/e1/e2/e2m. Or does this data have a lot of differences? If yes, do you have any instructions on using it inside Ghidra? To decompile and understand the sources of my v850e2. Thanks and sorry.

I found two missing register names in v850e3.sinc.
The current package cannot disassemble code "e05f 2008" and "e067 2008". They should be "ldsr r0, SCCFG,1" and "ldsr r0, SCBP,1".
I changed the line 51 of the "v850e3.sinc" from "_ _ tcsel _ _ hvccfg hvcbp vsel" to "_ _ tcsel SCCFG SCBP hvccfg hvcbp vsel".
I'm using Ghidra 10.2.2.
If the changes are correct, please change the original package.

Ghidra can not disassemble the code "f867 4068".
The code is disassembled to "stsr cdbcr, r12,13".
I add the following 4 definitions (a,b,c,d) in v850e3.sinc and 2 definitions (e,f) in v850_common.sinc.

a) at the last of the secction "define register offset=0x104 size=4[]"

     # selID = 13
     _ _ _ _ _ _ _ _
     _ _ _ _ _ _ _ _
     _ _ _ _ _ _ _ _
     cdbcr _ _ _ _ _ _ _

b) at the last of the secction "# More special registers"

attach variables [ SR0004_d SR1115_d ] [
    _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _
    cdbcr _ _ _ _ _ _ _
];

c) in the section # STSR regID, reg2, selId
:stsr SR0004_d, R1115, 13 is op0510=0x3F & R1115 & SR0004_d; op1626=0x40 & op2731=0x0d { R1115 = SR0004_d; }
d) in the section # LDSR reg2, regID, selId
:ldsr R0004, SR1115_d, 13 is op0510=0x3F & SR1115_d & R0004; op1626=0x20 & op2731=0x0d { SR1115_d = R0004; }
e)
SR0004_d = (0,4)
f)
SR1115_d = (11,15)

I have a weird issue where the first operand of the cmp instruction is always 0. See screenshot:

Is there anyway to improve the RH850 decompiled output a little bit... below is an example of the output from your extension:

And this is the upstream v850 output:

There are a few places in a bin that I am working on where I will hit an apparent issue in the disassembly. Here is an example:

To me it seems obvious that the address pointer at 0x677ac should be passed to the first argument of ProcessMap3D but instead the address of 0x677a8 is getting used which is 4 bytes off or 1 word.

I'm using "Ghidra processor module for Renesas v850" on RH850/U2A code.
It couldn't disassemble the following binary codes.
0019e018 e9 77 20 10 ldsr param_4,Sr142,2
I made a patch for v850e3.sinc, then it could dissassemble as the above.
But "Sr142" is a temporary name, it should be "PLMR".
According to the "RH850/U2A-EVA Group User’s Manual: Hardware", many system registers were extended in U2A.
Could you please fix them?

Hi the following instructions fail to disassemble on RH850

87EF2820 ldsr r15,mpidx
87EE2820 ldsr r14,mpidx
87E02820 ldsr r0,mpidx
C7EB2820 ldsr r11,mpid0
C7E82820 ldsr r8,mpid0
CFEB2820 ldsr r11,mpid1
D7EB2820 ldsr r11,mpid2
DFEB2820 ldsr r11,mpid3
E7EB2820 ldsr r11,mpid4
EFEB2820 ldsr r11,mpid5
F7EB2820 ldsr r11,mpid6
FFEB2820 ldsr r11,mpid7
17E18B78 ld.w [r1]+,r17
17E19378 ld.w [r1]+,r18
0FE80840 stsr svlock,r1
9FE80840 stsr svlock,r19
47E10820 ldsr r1,svlock
47F30820 ldsr r19,svlock
07EB6B70 ldl.bu [r11],r13
17FE937A st.w r18,[r30]+
77EB1020 ldsr r11,plmr
77EF1020 ldsr r15,plmr
....

Im not sure these are correct:
[07E60820 ldsr r6,spid ] vs Ghidra... [e6 07 20 08 ldsr r6,MCFG0,1]

hey Man, I am not sure if this is an issue with the language. or with my machine/install. I think I am running into a previously encountered issue where the SLA file is not automatically being generated. I have corrected all my permissions, and I have also tried running the sleigh.bat. I am fairly new too all of this so I am sure I am just doing something wrong. when I click on sleigh.bat, it opens CMD prompt, says click any key, and then when I do it closes, no change takes place in the processor files or anywhere else that I can tell.

I am working on a few V850 and RH850 based ECUs, 99% of the binaries seem to be disassembling fine but in a few instances bad instruction data is encountered.

Here is an example from an RH850:

I am not sure if I am doing something wrong because I am still fairly novice with Ghidra, but in the v850 binaries that I am working with I often encounter these switch statements with jumps out to other functions. At the beginning and end of the parent function is prepares and disposes the link pointer, and from what I can tell this link pointer is passed as a parameter to the functions that are jumped to.

As a result, in the decompiled code for the function that is jumped to there are many references to this link pointer as a param by index and its totally a pain to make sense of what is going on.

Am I missing something? Is there a way to handle this better?

Ghidra cannot disassemble "e0bf 5284" and "e05f 5294".
They shoud be "cvtf.wd r23r24, r16r17" and "cvtf.wd r11r12, r18r19".
Ghidra CAN disassemble "e087 5274" as "cvtf.wd r16r17, r14r15".
I could not find a bug in code.

Hi,

interesting extension. I'm new to sleigh and try to follow installation but get errors during compile:

ghidra_v850-master\data\languages\v850.slaspec" is not properly case dependent: Case difference found:

ERROR Unrecoverable error(s), halting compilation (SleighCompile) ghidra.sleigh.grammar.BailoutException: input file "ghidra_v850-master\data\languages\v850.slaspec" 

is not properly case dependent: Case difference found:

I'm not sure if im doing something wrong. I've set GHIDRA_HOME to Ghidra root dir.
I've tried different ghidra versions including 9.1.0. Do you know what could be the problem?

I don't have GNU make installed on Windows. What would the sleigh.bat commands be?

Ghidra cannot disassemble "ac07 89f3 0000" and "a307 4ff5 0000", which are actual pieces of code.
They should be "ld.dw 0x38[r12], r30r31" and "st.dw r30r31, 0x54[sp]".
I have made the following changes.
Ghidra/Processors/rh850/data/languages$ diff v850_common.bak v850_common.sinc
14c14
< [ r0r1 r2sp _ r6r7 r8r9 r10r11 r12r13 r14r15 r16r17 r18r19 r20r21 r22r23 r24r25 r26r27 r28r29 _ ];
---
> [ r0r1 r2sp _ r6r7 r8r9 r10r11 r12r13 r14r15 r16r17 r18r19 r20r21 r22r23 r24r25 r26r27 r28r29 r30r31 ];
218c218
< [ r0r1 _ r2sp _ _ _ r6r7 _ r8r9 _ r10r11 _ r12r13 _ r14r15 _ r16r17 _ r18r19 _ r20r21 _ r22r23 _ r24r25 _ r26r27 _ r28r29 _ _ _ ];
---
> [ r0r1 _ r2sp _ _ _ r6r7 _ r8r9 _ r10r11 _ r12r13 _ r14r15 _ r16r17 _ r18r19 _ r20r21 _ r22r23 _ r24r25 _ r26r27 _ r28r29 _ r30r31 _ ];

"jarl" definition is missing "op1626=0x160 & " in v850e3.sinc.
It should be the follows.
:jarl [R0004], R2731 is op0515=0x63f & R0004; op1626=0x160 & R2731 {

Hi.
Example of correct operand from real Renesas OCD:
fde7b8f0 bins r29, 0x4, 0x1c, r28

Disassembled by IDA:
bins r29, 4, 0x1C, r28

Disassebmled by Ghidra and your extension:
fd e7 b8 f0 bins r29,0x4,0x1b,r28

You can see that extension show 0x1b instead of 0x1c

All BINS operand incorectly disassembled:
bins r29, 5, 0x1B, r1 - IDA Correct

bins r29,0x5,0x1a,r1 - incorrect by extension

Always incorrect disassembled command contains wrong bits offset (0x1B instead of 0x1C) (0x1A instead of 0x1B) and so

When disassembling, the module seems to fail at the following bytecodes:

a3 07 4F 40 00 00

This instruction does not seem to be present in any architecture specification that I've seen online - could this be a proprietary instruction or are we simply missing an architecture document somewhere?

It is close to the LD.BU and LD.HU instructions but it does not line up perfectly with either.

It could be an LD.BU format 1, but it would seem to be storing the value in r0 which doesn't seem like it should be possible according to the architecture document.