Converting addresses relative to register to fixed addresses

[joelreymont]

I have a processor architecture (AndeStar / NDS32) that has a bunch of instructions operating off of a register.

Say the register is GP and the instruction are LWI.GP. The instruction takes an offset and loads a value from GP + offset.

It's described thusly

This instruction loads a 32-bit word from the memory into the general register Rt.
The memory address is specified by the implied GP register (R29) plus a sign-extended (imm17s
<< 2) value.

Here's an example disassembly

                      LAB_004406c0                          XREF[1]:  0044c474(*)  
     004406c0 3c 0d       lwi.gp   a0,[+ -0x305c]
             f3 e9

and the corresponding decompilation

  undefined4 uVar1;
  int unaff_gp;
  
  if (*(int *)(unaff_gp + -0x305c) == 0) {

Note how Ghidra creates a local unaff_gp variable, to be used as unaff_gp + -0x305c. This is useless and should be improved by adding the offset to the contents of GP and using that calculated address instead.

The address can be calculated by tracking modifications to the GP register, e.g. the following stores 0x450 into the high 16-bit portion of the GP register (i.e. 0x450 << 12) and then adds 0x428 to it

     00440042 47 d0       sethi    gp,0x450
             04 50
     00440046 59 de       ori      gp,gp,0x428
             84 28

Is there a way to keep track of modifications to the GP register in Sleigh and use fixed addresses in LWI.GP as opposed to relative ones?

[joelreymont]

The weird bit is that the lwi.gp above is expanded into P-CODE that seem to take the value of GP into account

                             LAB_004406c0                                    XREF[1]:     0044c474(*)  
        004406c0 3c 0d f3 e9     lwi.gp     a0,[+ -0x305c]
                                                      $U8600:4 = INT_ADD gp, 0xffffcfa4:4
                                                      a0 = LOAD ram($U8600:4)

Why is this not coming across to the decompilation listing, though?

The value of GP should be

❯ lldb
(lldb) p/x (0x450 << 12) + 0x428
(int) 0x00450428

and the value assigned to a0 above is then

(lldb) p/x 0x00450428 - 0x305c
(int) 0x0044d3cc

which should point to one of the strings defined in the binary I'm reversing.

How do I make P-Code do these calculations for me so that I see the actual string in the decompilation listing and not the relative address?