Mismatch between Decompiled and Function Prototype

[jeffgennari]

Describe the bug The function prototype on the Function object is different than the function prototype on the HighFunction object.

To Reproduce Open the attached file in Ghidra and let auto analysis complete. Go to function FUN_00401030 in the disassembly window and look at the function prototype (Screenshot 1):

undefined FUN_00401030 (undefined4 param_1, undefined4 param_2, undefined4 param_3, undefined4 param_4)

Go to the same function (FUN_00401030) in the decompilation window and navigate to the same function (in the decompilation window). The function has the following prototype (Screenshot 2):

void FUN_00401030 (undefined4 param_1, undefined4 param_2, undefined4 param_3, undefined4 param_4)

Notice that the return values do not match (undefined vs. void). Further, looking at the references It would appear that the decompilation is incorrect. Screenshot 3 shows the decompilation of a function cal invokes FUN_00401030 and there is clearly a return value.

Screenshots Screenshot 1

Screenshot 2

Screenshot 3

Attachments Program demonstrating issue attached: print.exe.zip

Environment (please complete the following information):

• OS: macOS 12.6
• Java Version: Temurin-17.0.4+8 (build 17.0.4+8)
• Ghidra Version: 10.2_DEV
• Ghidra Origin: locally built from official repo

[ghidracadabra]

This is the intended behavior, although it does take a little getting used to.

In this case, the prototype on the Function object is assigned with a SourceType of DEFAULT. This indicates a relatively low confidence in the prototype, so the decompiler is free to disregard it and compute one itself, both when decompiling the function and when decompiling any caller. There is also no guarantee that two distinct call sites will be assigned the same prototype.

If you are sure of the function's prototype, you can commit it to the program database by right-clicking in the Decompiler window and selecting the Commit Params/Return action. Then the Listing, decompiled body, and all decompiled callers will use that prototype. In certain cases the function prototype will be automatically committed to the program database with a high source type (for example, if Ghidra recognizes a known library function).

There's some more information in the "Program Annotations Affecting the Decompiler" section on the Ghidra help, and the slide deck improvingDisassemblyAndDecompilation.pdf, which is included with the Ghidra distribution.

The "Decompiler Parameter ID" analyzer examines the entire call tree, attempts to determine the correct signatures, and saves them to the program database. For certain programs it is not on by default but can be run manually from the Code Browser via Analysis->One Shot