non-compliant decompiler

[spein46]

Hi. I ve little problem with ghidra, works bad in one function, I ve in DIsplay listening this instruction: jalr t9=>memset

but decompiler decompile this like: (*(code *)(local_b38 + -0x70c8))(&local_900,0,0x34)

in other function same instruction is decompiled well, so I get

memset(param1, param2, param3)

I tried to re-create function, clear bytes and decompile function, re-analyze, nothing

[cmccord-dev]

I'm actually having the same problem, most of the decompiler output isn't useful but the disassembler manages to find the right functions and data pointers. I can post more info and maybe try to isolate an example if necessary.

[cmccord-dev]

Okay it seems some functions have two entry points. One of them sets up the $gp register and then flows into the second. I assume this is an optimization by the compiler (an old ido mips compiler) for functions that share the same $gp register. manually setting the gp register for the second entry fixes its output.

[spein46]

lw t9,-0x70c8(gp)=>->memset ...... jalr t9=>memset in one function decompiler, decompile this instruction flow well, so memset(param1, param2, param3 in other function with identical disassemble instrucion, decompiler: (**(code **)(local_b38 + -0x70c8))(&local_900,0,0x34) because lw instruction with gp register in disassembler in both function is the same, with pointer to memset function. Should I edit gp register?I didn 't understand how I can fix this behavior thanks

[cmccord-dev]

The decompiler seems to have trouble remembering the gp when it gets spilled to the stack before a function call.

[spein46]

this is the weird behavior

idea about it? I think the issue is in decompiler, something goes wrong, but I don t know how fix it I think trigger of issue could

be that: