Ghidra: Decompiler bug on function calls

[Dan-PC]

Hi.
I've noticed that decompiler sometimes doesn't realize that "call" instruction in assembly pushes return address onto stack and thinks that it's a variable being pushed.

I have no idea why it happens only sometimes. Here's debug info from this function:
bug.txt
I didn't find other issues like that in here.

[metal-crow]

I'm also experiencing this issue. The attached function has numerous decompiled if statements which include setting a stack variable to the next execution address, even without any corresponding assembly instructions. It may be related to how Ghidra views virtual function calls, since in both mine and Dan's example that is always present along with the bug,

debug.txt

[saruman9]

I think, that the issue related to #264, #911 and maybe #1472. @emteere, what do you think about it? Could you tell us in which direction we need to dig in order to solve the issue? Many binary files compiled for x86_64 by gcc use only RSP, for this reason I cannot use the decompiler (see Fig. 1).

Fig. 1. Bash's main function for Linux x86_64 with many wrong calls (return address is pushed onto the stack manually)

[ccarpenter04]

This bug (as it relates to the RSP register) and GCC choosing to use it so much when targeting x86_64 resulted in me analyzing a relatively large function incorrectly. Are additional examples needed or do the existing examples illustrate the problem in enough detail?

[saruman9]

I created the PR, that fixes my problem. Test it please.

@Dan-PC, I don't fix your problem. Could you upload whole binary file?

[Dan-PC]

@saruman9 I don't think I can upload it here, it should be against github's TOS