How to get stack args to be properly recognized by decompiler?

[marcushall42]

I'm working on the Xtensa processor and when function arguments spill over to the stack, it seems that much of ghidra handles it properly, but something is feeding wrong info to the decompiler somehow. I'm looking for the proper magic to make everything work as it should (I'm sure I'm just missing something).

First off, the Xtensa passes the first 6 arguments in a2, a3, a4, a5, a6, a7, and any subsequent arguments on the stack (a1 is the stack pointer). This function is stuffing the 7 arguments into a structure and setting the rest to 0x10. The disassembly looks like:

---

                         *                          FUNCTION                          *

---

                         undefined4 * __stdcall FUN_000a2f94(undefined4 * param_1
         undefined4 *      a2:4           <RETURN>
         undefined4 *      a2:4           param_1
         undefined4        a3:4           param_2
         undefined4        a4:4           param_3
         undefined4        a5:4           param_4
         undefined4        a6:4           param_5
         undefined4        a7:4           param_6
         undefined         Stack[0x0]:4   param_7
         undefined4        Stack[-0xe0]:4 uStack224

                         FUN_000a2f94                                    XREF[1]:     constructClassInstances:000a0975
    000a2f94 36 41 00        entry      a1,0x20
    000a2f97 79 42           s32i.n     a7,a2,0x10
    000a2f99 39 02           s32i.n     a3,a2,0x0
    000a2f9b 49 12           s32i.n     a4,a2,0x4
    000a2f9d 59 22           s32i.n     a5,a2,0x8
    000a2f9f 69 32           s32i.n     a6,a2,0xc
    000a2fa1 a2 c2 20        addi       a10,a2,0x20
    000a2fa4 1c 0b           movi.n     a11,0x10
    000a2fa6 c2 a0 a0        movi       a12,0xa0
    000a2fa9 88 81           l32i.n     a8,a1,0x20
    000a2fab 89 52           s32i.n     a8,a2,0x14
    000a2fad e5 08 07        call8      memset                                           undefined memset()
    000a2fb0 1d f0           retw.n

The entry for param_7 was not automatically discovered. I added that with the decompiler's edit function signature and hit '+' to add an additional parameter. That part of ghidra understood the spill onto the stack and added param_7 at address 0 on the stack frame (from a1 as we entered the function). The "entry" instruction at a2f94 subtracts 0x20 from the stack to build the local frame. The l32i.n at a2fa9 loads a8 from a1+0x20, which skips over the stack frame to get to the argument properly.

The decompiler produces this:

undefined4 *
FUN_000a2f94(undefined4 *param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
undefined4 param_5,undefined4 param_6,undefined4 param_7)

{
undefined4 uStack224;

param_1[4] = param_6;
*param_1 = param_2;
param_1[1] = param_3;
param_1[2] = param_4;
param_1[3] = param_5;
param_1[5] = uStack224;
memset(param_1 + 8,0x10,0xa0);
return param_1;
}

which is treating param_7 as a local variable uStack224, which has a stack offset of -0xe0. That's 0x20 - 0x100, which seems like it might be significant...

In my .cspec file, after declaring a2-a7 as possible args, the stack is specified with:

   <pentry minsize="1" maxsize="500" align="4">
      <addr offset="0" space="stack"/>
    </pentry>

Any suggestions what I should look into to try to understand why the decompiler thinks that stack arguments are local variables?

[marcushall42]

I did discover that the PcodeOps generated for the entry instruction was poorly crafted. Instead of just subtracting a constant from the stack pointer, it was shifting the bitfield from the instruction and zero extending that, then subtracting the result. So, it seems that the stack analysis didn't fold constants together (unsurprising) and gave up trying to determine what the current stack offset was, so it couldn't determine when a stack reference was really accessing a register.
I have improved my sleigh so that now the "entry" instruction produces PcodeOp to directly subtract a constant from the stack pointer and now the decompiler understands the stack argument references.