Proper handling of RISC-V memory accesses via offsets from global pointer

[basilhussain]

I am attempting to reverse engineer some RISC-V microcontroller code, but there is one particular aspect related to its handling of code using the global pointer (gp) register that is making understanding the code more difficult and tedious than it probably should be. I am wondering if there is a way to make Ghidra decompile the code into something more understandable.

In this particular code, the gp register is initialised early on (in reset vector handler) with a value equal to the end of RAM, 0x20000800. Thereafter, most accesses to static/global variables in the code are made via offset from gp. (I believe this is probably because the code was compiled using GCC with the --relax option.)

For example:

sb zero,-0x7f2(gp)          ; actual addr = 0x2000000e

Ghidra is only able to decompile this as:

*(undefined *)(gp + -0x7f2) = 0;

Another example:

addi s0,gp,-0x7f3           ; actual addr = 0x2000000d

pbVar7 = (byte *)(gp + -0x7f3);

This is not particularly helpful, as I'm having to manually translate these into the actual memory addresses that are being accessed, and keep track of everything separately. It also doesn't help assigning a label and data type to these memory locations, as accesses this way won't use those attributes.

Ghidra obviously knows how to translate RAM accesses that are relative to an address in another register, because it does this successfully for other code not involving gp:

lui a3,0x20000
addi a3=>DAT_20000001,a3,0x1
c.lbu a2,0x0(a3=>DAT_20000001)
c.add a2,a4
andi a2,a2,0xff

uVar19 = DAT_20000001 + uVar20 & 0xff;

Is the problem because Ghidra doesn't know what the value of gp is at any given point?

Is there any way to turn the gp-using code into something more sensible?

[eshattow]

Similar experience, Ghidra does not pick up on the first lot of instructions in BootROM including where gp is set. I can use shortcut d to disassemble in-context for those early instructions but Ghidra does not use that context for later function decompile output. It's quite tedious to track this manually as mentioned above.

[eshattow]

Is the problem because Ghidra doesn't know what the value of gp is at any given point?

Is there any way to turn the gp-using code into something more sensible?

Workaround:

Go to the address of the instruction just after gp is set, then menu Select -> Bytes... (to address) and enter the last address of .text section. Now context-menu Set Register Values... (Control-R) in the disassembly output listing and set the value of gp which you have computed.

This also demands that you figure out the value. Is there not any better way in Ghidra to do this?

[basilhussain]

Manually setting the register value of gp is indeed the workaround which I ended up finding.

@eshattow It should be noted that your suggested procedure isn't quite suitable when dealing with embedded microcontroller code. There, you typically have an IRQ vector table at the beginning of the .text (i.e. flash memory) section, which jumps to a reset handler, within which gp is set once. However, the reset handler is typically at the end of the .text section, so selecting everything forward of the gp-setting code won't help. Basically, you need to select everything in .text and then set the register value.

Figuring out the gp value manually isn't actually that hard. For example, for a pair of instructions that sets gp:

000007ee 97 01 00 20     auipc      gp,0x20000
000007f2 93 81 21 01     addi       gp,gp,0x12

1. Take the immediate value from the auipc instruction (0x20000) and left shift it by 12 bits (giving 0x20000000).
2. Add the address (i.e. program counter, 'pc') of the auipc instruction (0x7ee → 0x200007ee).
3. Add the immediate value from the addi instruction (0x12 → 0x20000800).

[eshattow]

There's also the method of Ghidra Debugger and inspect the value of register gp to determine its value at some breakpoint. Would that work for your situation?

[basilhussain]

Perhaps. But not when you have only a firmware binary image and not the hardware it runs on. 😉

[eshattow]

Perhaps. But not when you have only a firmware binary image and not the hardware it runs on. 😉

Ghidra Debugger ran on my amd64 host with no RISC-V hardware attached. Frustratingly it does not seem to obey breakpoints, but you can step through the instructions or just let it run awhile and pause it to view the state of the registers (including gp).