Tricore disassembly not creating reference

[brandonros]

        8001812e 91 20 00 28     movh.a     a2,#0x8002
        80018132 d9 22 3c 48     lea        a2,[a2]-0x7ec4

should make a reference to 0x8001813C

but it is nowhere to be found

[brandonros]

@mumbel

[mumbel]

The PCODE looks correct, not sure why it wouldn't be making the xref. I'm probably not gonna be helpful here as I'm running into this as well for my PPC and MIPS work (#2961 ). The MultiInstructionMemReference.java does create the reference, and I would delete the 0x80020000 reference it inadvertently makes.

        8001812e 91 20 00 28     movh.a          a2,#0x8002
                                                      $Uf180:4 = COPY 0x8002:4
                                                      a2 = INT_LEFT $Uf180:4, 16:4
        80018132 d9 22 3c 48     lea             a2=>LAB_8001813c,[a2]-0x7ec4
                                                      $Ue580:4 = COPY 0xffff813c:4
                                                      $Uf880:4 = INT_ADD a2, $Ue580:4
                                                      a2 = COPY $Uf880:4
        80018136 30 42           add.a           a2,a4
                                                      a2 = INT_ADD a2, a4

maybe its related to a4?

[brandonros]

@mumbel so you are probably right that it's a4

here is another example:

i would say it's a very minor bug (different than the topic I opened) that

        80000320 4d 80 e0 0f     mfcr       d0,#0xfe08

decompiler isn't able to tell that this means "set d0 to PC"

a lot of bootloaders do this to figure out where they are running from "relative memory" wise

do you have any recommendation on like... "just set a register value manually"? I tried setting PC then running auto-analyze but it doesn't work how you'd expect/I might not be doing it right.

How would you handle this/is this an easy change we can make in the underlying Tricore Ghidra codebase?

[brandonros]

I guess I'm lacking the ability to override/set the "const:0xfe08" reference/it doesn't know what to do with core registers.

[brandonros]

even manually setting the a2 override then doing "analyze" on this selection, the "reference" to the function (and the automatic decompilation assumed since it is jumped to) doesn't kick off (unless I am doing something massively wrong)

[brandonros]

Not sure what this one might be. The decompiler on the right knows the base register a0 is being set to 0x700098c0 but XREF wise, it doesn't register.

[mumbel]

1640 Try with this PR applied

[gmgunderground]

I have the same issue, setting register a0 the xref is not updated

             assume a0 = 0xd0008000
                  a00089a0 d9 0f c4 59         lea                 a15,[a0]-0x62bc
             assume a0 = <UNKNOWN>

also inside decompiler

local_c = (undefined4 *)(a0 + -0x62bc);

Is there a workaround to display the absulite memory address? I'm using Ghidra 10.3.2