Non-existent edges inserted after functions calls that never return

[CAFxX]

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:

1. Open a Go binary
2. Open graph
3. Find a function that contains multiple _runtime.panic* function invocations
4. 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

[karliss]

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.

[CAFxX]

Thanks. Would it be acceptable to teach rizin about which go functions don't return?

[ret2libc]

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?

[XVilka]

@ret2libc yes, the idea is good. See rz_type_db_init() function.