incosistency between return types in disassembly/function signature editor vs decompile view

[orangecms]

I am sometimes seeing that the decompile view shows

void foo(void)
{
  /* ... */
}

and yet, in another function calling it, I would get something like

  iVar1 = foo();
  iVar2 = *(int *)(iVar1 + 0x800); // looks weird; iVar1 here was really a function argument

• leaving me puzzled; why the assignment from void?

I then noticed that in the disassembly view in the function signature editor, I would see the return type undefined, and would need to adjust it. Having done so, the calling function correctly reads

  r16_to_stack();
  iVar1 = *(int *)(param_1 + 0x800);

I checked existing issues from the last ~2 years, but couldn't see a similar bug report.
I am on 52aed0a plus the changes in #3006 and I'm analyzing an ARCompact binary that I cannot share for legal reasons.
See https://github.com/orangecms/ghidra/releases/tag/Ghidra_12.1.2-2_ARCompact_build

[pelrun]

Did you commit the function signature of the called function, or just assumed that when the decompiler showed a return type that it was then visible to the rest of the project?

The decompiler is only given the instructions of the current function it's working on, and the defined types of the references. So there is no reason to expect it'll infer the same types for a function when it can only see the caller instructions versus the callee instructions and the callee signature is not fully defined. The caller decompiler instance doesn't know anything that the callee decompiler instance inferred unless you've explicitly propagated that information out.

The type shown in the function signature editor is the ground truth as far as the whole project is concerned, so if there are undefined types in there then the different views are free to infer different things.

[orangecms]

Oh now I understand - I was indeed expecting the decompiler to be consistent with the view of the project etc.

Is it that I need to manually commit all the signatures for all the functions?
Or does it just mean in the case I see undefined that Ghidra couldn't be sure and left it to me to commit or adjust the singature?

[pelrun]

expecting the decompiler to be consistent with the view of the project

It is consistent - it's just not automatically pushing it's inferences into the project db, so separate decompilation instances aren't consistent with each other. You don't generally want that, as it'll end up erasing things you already committed manually (yes, most of your time working with a project will be spent manually committing function and data type definitions), and it can always re-infer everything as needed.

Committing large scale automated changes are what the analyzers are for - either via the auto-analysis step on project creation to pre-populate the db (when there's nothing to overwrite), or if you explicitly invoke them at some point afterwards. Decompiler Parameter ID can perform automated signature extraction from decompilation, but it's really slow, so it's disabled by default - after all, it decompiles every function in the binary!