Clicking on assembly code on a switch statement of a function sometimes leads to an undefined function on the switch statement instead of staying in the same function

[H-A-M-G-E-R]

[ryanmkurtz]

Can you please provide a sample binary and and address where this is happening? We need something more concrete to go off of.

[H-A-M-G-E-R]

decompiling a GBA game

[ghidracadabra]

It's possible that Ghidra figured out that it should disassemble the bytes corresponding to a case of a switch statement without being able to place the resulting instructions into the body of a function (there are analyzers that look for various bit patterns to guide disassembly). The slide deck improvingDisassemblyAndDecompilation.pdf (included with the Ghidra distribution) walks through an example of manually fixing a switch statement.

[H-A-M-G-E-R]

Example:


i never want that to happen

[H-A-M-G-E-R]

I think the fix to this is #7206 (comment): regenerating switch tables.

[emteere]

Sometimes the decompilation improves in newer Ghidra versions that allow a switch stmt to recover, where it did not recover in past versions. Other times it could be because something was resolved that now allows the switch to recover.

If the decompiler is showing the switch correctly and the listing is not, then clearing the instruction and re-creating the switch with analysis should always solve the issue.

Most likely an older version of Ghidra couldn't recover the switch and the table was found by later speculative analysis like the address table analyzer.

When I see a bad switch I usually try to delete the switch instruction and re-disassemble it to diagnose the issue. If the function body is bad after that you can delete and re-create the function and it should fix up.

If that doesn't correct it, then I'll look for problematic functions, non-returning, side-effects of a function call like affecting the stack, signatures not correct, or other flow issues.

I'll close this for now if it has been fixed for you.