[MIPS] CBRANCH that are always true should be treated like BRANCH

This is using ghidra version 9.1.2.

When compiling PIC code for MIPS, the compiler will emit bgez zero, label (which disassembles into the pseudo-instruction b label), and bal function. When in ghidra, the former isn’t properly processed:

• b label is being disassembled as bgez zero, label instead of its pseudo-form.
• the analyzer still sees it as a CONDITIONAL_JUMP, instead of a BRANCH, which confuses the analysis flow, and produces a bunch of errors in the decompiler:

A good minimal reproduction case for this would be the attached file: mips-infinite-loop.gz

You can see the problems in this screenshot:

What’s wrong in this picture:

• Instruction at 00000000 is considered “CONDITIONAL_JUMP” as instruction flow.
• The decompiler complains that it had to remove unreachable block.

Loading this test files is simply done using the MIPS:LE:32:default:default language:

[mumbel]

yeah, totally agree with you there and based on your examples for the CBRANCH.

huh, I must be going crazy (maybe it was the first binary you linked) I could have sworn the CBRANCH had a 1 in the pcode op, but these are variables. You might edit your issue title as something along the lines of CBRANCH that are always true should be treated like BRANCH

[TellowKrinkle]

Ran into this issue as well with a processor definition that was missing the beq zero, zero → b entry: https://github.com/beardypig/ghidra-emotionengine/pull/47

Always-true conditional branches also seem to make the decompiler reluctant to move code past them, leading to unnecessarily complicated decompiler output