cutter
cutter copied to clipboard
Non-existent edges inserted after functions calls that never return
Environment information
- Operating System: osx 12.2
- Cutter version: 2.0.5
- Obtained from:
- [ ] Built from source
- [x] Downloaded release from Cutter website or GitHub
- [ ] Distribution repository
- File format: mach064
- Arch: x86
- Type:
Describe the bug
In the graph, radare draws edges after functions that never return (all the _runtime.panic*
functions are inserted automatically by the Go compiler, and they never return - as they trigger a panic).
By itself this is not a huge deal, but because of that non-existent edge the resulting layout is pretty mangled, as all of these blocks get bundled together just because they are contiguous in the source binary.
It would be instead much clearer/better if that non-existent fallthrough edge was not added, as this would allow the layout to move each block closer to the single location where the control flow can actually originate from.
To Reproduce
Steps to reproduce the behavior:
- Open a Go binary
- Open graph
- Find a function that contains multiple
_runtime.panic*
function invocations - Notice the problem described above
Expected behavior
See above
Since it is unlikely that radare will actually be able to infer from code analysis whether a function call can return or not, it is probably going to be required to have a "registry" of functions that are known to never return. Such a registry may obviously be useful beyond Go binaries.
Screenshots
See above
Additional context
Just did a quick test with c++ executable using "exit". There where no edges after exit calls. So the edges don't get inserted if rizin knows that function doesn't return. You can manually mark function as no return using tn
command.
Thanks. Would it be acceptable to teach rizin about which go functions don't return?
Please note we also have a bug at https://github.com/rizinorg/rizin/issues/2725 where some no-return information is not propagated correctly.
@XVilka I noticed that we can load different kind of information about functions/types based on os, arch, bits, etc. but we do not have any way to load things based on the language being detected. Would it be a good feature request to have? If we have such thing, one could drop a file in share/types/functions-golang.sdb and they would be automatically loaded whenever you load a golang binary. WDYT?
@ret2libc yes, the idea is good. See rz_type_db_init()
function.