NationalSecurityAgency
Ghdira unable to show TRICORE XREF with certain address registers
With respects to the following code:
a00da6ec d9 02 3e 59 lea a2,[a0]-0x6e82
a00da6f0 94 2f ld.h d15,[a2]=>DAT_d001117e
a00da6f2 d9 02 18 5b lea a2,[a0]-0x4ea8
a00da6f6 09 20 c0 08 ld.hu d0,[a2]0x0=>DAT_d0013158
a00da6fa d9 12 ae 7a lea a2,[a1]-0x5612
a00da6fe 09 21 c0 08 ld.hu d1,[a2]0x0=>DAT_a02029ee = 5271h
a00da702 7f 01 0b 80 jge.u d1,d0,LAB_a00da718
a00da706 d9 12 86 aa lea a2=>DAT_a0202a86,[a1]-0x557a = 0040h
Ghidra is able to correctly display the XREF to the address referenced by the offset applied to [a1] at the bottom of the abovementioned code, however it is not able to do it for the case of the first instance. I am working on Tricore code, specifically TC179x.
Both instructions are load effective address yet it is only able to find the XREF on one of the instructions. This appears to be the case for much of the code, where Ghidra is correctly finding the XREF on many of the instructions, however it is missing the majority of them. I have correctly set the General Purpose Registers [a0], [a1], [a8] and [a9] for the context boundaries of the entire program. I have only noticed this issue on the current build I am using.
- OS: Windows 11 Pro Version 10.0.22631 Build 22631
- Java Version: 21.0.3
- Ghidra Version: 11.0.3
- Ghidra Origin: GitHub
Thank you in advance for your guidance and assistance. ~ Josh
I also wanted to add that this issue is persistent on the current build of Ghidra 11.1 - (as of 10 JUNE 24)
On version 11.2.1 same problem, also in decompiler wrong values
A15 XREF not displayed and in decompiler wrong calculated value
Extra information, a0 register is assigned after function creation. If I select all function and then make a clear "C" and now "D" something is changed
but [A15]0x6 is wrong calculated
**************************************************************
* FUNCTION *
**************************************************************
undefined FUN_802144f2()
undefined <UNASSIGNED> <RETURN>
FUN_802144f2 XREF[1]: thunk_FUN_802144f2:80533f56(T),
thunk_FUN_802144f2:80533f56(j)
802144f2 40 5f mov.aa a15,a5
802144f4 40 6c mov.aa a12,a6
802144f6 91 10 00 d7 movh.a a13,#0x7001
802144fa d9 dd 38 b0 lea a13,[a13]0x2f8
802144fe 54 cf ld.w d15,[a12]
80214500 74 df st.w [a13]=>DAT_700102f8,d15
80214502 91 10 00 e7 movh.a a14,#0x7001
80214506 d9 ee 30 c0 lea a14,[a14]0x330
8021450a 40 e5 mov.aa a5,a14
8021450c 40 d6 mov.aa a6,a13
8021450e 6d 18 ed fe call FUN_805342e8 undefined FUN_805342e8()
80214512 02 2f mov d15,d2
80214514 54 d4 ld.w d4,[a13]=>DAT_700102f8
80214516 74 c4 st.w [a12],d4
80214518 40 f4 mov.aa a4,a15
8021451a 40 e5 mov.aa a5,a14
8021451c ed c0 80 03 calla memcpy? undefined memcpy?()
80214520 82 04 mov d4,#0x0
80214522 74 d4 st.w [a13]=>DAT_700102f8,d4
80214524 3b 00 04 50 mov d5,#0x40
80214528 40 e4 mov.aa a4,a14
8021452a ed c0 e8 02 calla memset? undefined memset?()
8021452e 02 f2 mov d2,d15
80214530 00 90 ret
Is this the same problem?
80214502 91 10 00 e7 movh.a a14,#0x7001
80214506 d9 ee 30 c0 lea a14,[a14]0x330
8021450a 40 e5 mov.aa a5,a14
I'm missing an XREF to 0x70010330
Extra information, a0 register is assigned after function creation. If I select all function and then make a clear "C" and now "D" something is changed
but [A15]0x6 is wrong calculated
What should the value be?
Can I help on this? I'm having the same problem, xref don't show when addresses are in a4, even in simple, straightforward situation like movh.a => lea => call. Never debugged Ghidra before but I'm willing to go in, this bug is really annoying.
Here are the static registers that are not located which causes the problem above. I've attached a hex file you can analyse.
<a0>70012e80</a0>
<a1>80090710</a1>
<a8>60029180</a8>
<a9>5000d200</a9>
Here is the code the assigns it
Here is a disassembled version (not actually ram, but rom)
ram:80006af2 0d00c004 isync
ram:80006af6 91100007 movh.a a0,#0x7001
ram:80006afa d9000018 lea a0,[a0]0x7fc0 <0x70008040>
ram:80006afe 91100018 movh.a a1,#0x8001
ram:80006b02 d91110f8 lea a1,[a1]0x7c30 <0x800083d0>
ram:80006b06 91100187 movh.a a8,#0x7011
ram:80006b0a d98810ab lea a8,[a8]0x4d70 <0x7010b290>
ram:80006b0e a009 mov.a a9,#0x0
@rollsch I looked at the disassembly and decompilation for the instructions and the decompiler is getting the correct values there. How does the first set of values correspond to the second?
They are simply the static registers for that file. If ghidra could detect they are static and use them it may fix the other issues above.
a0, a1, a8 and a9 are listed as both global and unaffected, and I see xrefs for uses of these registers (but maybe not all). a10-a15 are only listed as unaffected in the cspec. The issue might be that we need to mark the address registers as global, although I wouldn't expect that to matter in cases where you have a memory read immediately after loading the register. I also wouldn't expect an xref on a mov.aa instruction since it's moving data from one register to another - the instruction isn't treating that data as a reference, it's just a register-register transfer.
I'm concerned about the issue referenced above with the wrong decompiler values, but I haven't been able to generate it myself. @gmgunderground Do you have a sample you can provide?
At the moment I don't have that file, I worked on It at my customer facory. If I will work on a similar file and find again the problem I will try to post it here