Function prototypes given by Ghidra is not consistent

Question

This is a follow up question to the question I posted over here. According to the answer, I was able to get all the function prototypes from the binary. However, the problem I am having is most of the function signatures I am getting does not have parameters while the actual decompiled version of the same function (with the use of decompile script which is already provided by Ghidra) have parameters.

For example, I have a function signature as undefined HAL_TIMEx_OnePulseN_Stop_IT(void) that was given by the above linked answer, while in the decompiled file (taken from running the ghidra provided Decompile.java script) I have it's signature as undefined4 HAL_TIMEx_OnePulseN_Stop_IT(uint **param_1,uint param_2) which I believe to be more accurate as I cross-checked with the actual source of the binary.

What would be the reason for such an inconsistency? Is there anyway that I could get the function parameters in the form of decompiled version? I was trying to use DecompInterface but I could not figure out the way to extract the prototypes as if they were in decompiled version. Sorry I am a beginner and just started to work with Ghidra. Thank you for your time.

Answer 1

So, I found out the reason. By default when the ghidra asks for options when we load the binary, Decompiler Parameter ID option is disabled. Once you enable it, you will have the function parameters correctly. It will take longer time to make the analysis once this option is enabled.

Answer 2

You noted that Decompiler Parameter ID fixes the discrepancy, but I suspect that the relevant logic is the one behind the context menu action Commit Params/Return.

The Ghidra Advanced Class slides state:

Decompiler Parameter ID

The Decompiler Parameter ID Analyzer (Analysis → One Shot → Decompiler Parameter ID) uses the decompiler and an exploration of the call tree to determine parameter, return type, and calling convention information about functions in a program. This analyzer can be quite useful when you have some rich type information, such as known types from library calls. However, if you run this analyzer too early or before fixing problems, you can end up propagating bad information all over the program.

Note: this analyzer will commit the signature of each function.

(emphasis mine)