ghidra
ghidra copied to clipboard
Return values with custom stack storage not visible in calls in decompiler
Describe the bug Calls to functions that store return values on the stack don't show return values in the decompiler.
To Reproduce
- Open
test.o(in attachments) - Set
f2to use custom storage with param storageStack[0x4]:4andStack[0x8]:4, and return storageStack[0xc]:4 - Observe the decompilation of
f1.
Expected behavior
The decompilation of f1 should assign the return value of f2(...) to uStack4.
Screenshots
Custom storage for f2:
Decompilation of f2 (this looks fine):
Decompilation of f1 (note that the return value of f2 is not shown):

Attachments
test.zip
Contains test.o with source test.S.
Environment (please complete the following information):
- OS: Arch
- Java Version: 8.0 (1.8.0_251-b08)
- Ghidra Version: 9.1.2 and 9.2 DEV (commit eaf6ab2)
Additional context
I'm working with m68k mac syscalls (a-line instructions) that store return values on the stack like _GetResource (0xa9a0, stores return value at Stack[0x6]:4) and _Random (0xa861, stores return value at Stack[0x0]:2).
@ubuntor Coincidentally, I'm also looking at m68k mac binaries. Could you share how you're currently modeling a-traps in Ghidra?
@resistor I'm disassembling them as a custom pcodeop, then marking them up as syscalls (with name and calling convention) with a script. Incredibly messy, but gives decent results (aside from this issue).
Processor (put these in Ghidra/Processors/68000/data/languages/): https://github.com/ubuntor/m68k_mac_reversing_tools/tree/main/ghidra/processor
Script: https://github.com/ubuntor/m68k_mac_reversing_tools/blob/main/ghidra/scripts/M68kMacSyscallScript.java
Data file for script (put in Ghidra/Features/Base/data): https://github.com/ubuntor/m68k_mac_reversing_tools/blob/main/m68k_mac_syscalls
This also occurs with Go binaries on x86_64 Linux.
This also occurs when reversing Go binaries with Go 1.12 on macOS.
@ryanmkurtz, I noticed this issue doesn't have any labels or assignees. Did this issue slip through the cracks?
@chenzhuoyu Can you please provide a golang example where it's not working with the latest version of Ghidra?
@ryanmkurtz
Ghidra 10.3.1 installed via Homebrew Go 1.12.17 downloaded from https://go.dev/dl/go1.12.17.darwin-amd64.tar.gz
Repro steps:
-
Import
stackret.zip/stackretand analyze with default settings. -
Go to function
main.main, there should be a call toruntime.newobject -
Change the signature for
runtime.newobjectto this:
- The decompiler does not recognize the return value of
runtime.newobject, which should be assigned tolocal_10in this case.
Thanks, i've passed this along to @dev747368 who is our Go expert.
e9b5be17c13f19d1005bbea52e36252cd504fb63 should address the issue with results on the stack.