Improving the Decompiler output

[Nemoumbra]

Long story short, is there a way to turn
*(int *)(*(int *)(param_1 + 0xa4) + 0xd8) = *(int *)(*(int *)(param_1 + 0xa4) + 0xd8) + 4; into
*(int *)(*(int *)(param_1 + 0xa4) + 0xd8) += 4;? For some reason the decompiler sometimes substitutes these huge expressions into smaller ones like A = A + 4 which are equivalent to A += 4. This form is easier to understand as by default we can't assume the things on the RHS and LHS are the same. It means we have to look twice as hard into the expressions.

I also don't get how the code like this manages to evade the reachability algorithm:

  if (iVar5 == 0) {
    iVar5 = 0;
  }
  else {
    if (iVar5 == 0) {
      iVar5 = 0;
    }
    iVar5 = *(int *)(iVar5 + 0x2c8);
    if (iVar5 == 0) {
      iVar5 = 0;
    }
  }

Maybe I don't understand something, but if the local variable is not zero in the "else" branch, the first "if" there will fail all the time and we can treat the assignment as a typical unreachable code. Well, in our case it also doesn't have any side-effects (basically useless).
This whole code is equivalent to

  if (iVar5 != 0) {
    iVar5 = *(int *)(iVar5 + 0x2c8);
  }

What else... I guess I'm also dissatisfied with one of the newest additions to the Decompiler: a max number of entries per jumptable that can be recovered. For some reason despite the fact that the value is pretty big I'm still getting errors like this one:

Now please have a look at the actual address there:

I don't understand why this wasn't converted into a jumptable with a switch-case. The only hypothesis I have is that Ghidra somehow noticed (!!silently!!) that the value of iVar1 can be bigger than the table's size and assumed that the table's significantly bigger than what it is (> 1024). I have no idea how to prove or disprove that without debugging Ghidra which is 💀 .

No matter what the answer to this question is, I'd like to know how I'm supposed to fix this if I'm absolutely sure it's a switch-case? I want Ghidra to make me a switch-case and format the table like this:

[Nemoumbra]

I would like to give this discussion an upvote, because I've got some new questions, but I'd like to deal with these first.

[LukeSerne]

You raised several issues in your opening post. To make everything easier to follow, I split my answer in 3 parts, one for each of your questions.

---

For some reason the decompiler sometimes substitutes these huge expressions into smaller ones like A = A + 4 which are equivalent to A += 4. [...]

It's a known issue that the decompiler sometimes (regularly?) misses such situations, reported as #5601. @RootCubed posted a patch that seems to work fine. The issue has also been marked internal, so I'm hopeful this situation will improve soon. You should try applying the patch in the issue thread and see if that works for you. Any further comments relating to this should probably go in that thread as well.

---

I also don't get how the code like this manages to evade the reachability algorithm: [...]

I'm not sure either, and I couldn't find any issues or PRs that discuss this. Maybe you could share the "debug function decompilation" xml file for the function containing this structure? Additionally, you could create a separate issue for this.

---

[...] a max number of entries per jumptable that can be recovered. For some reason despite the fact that the value is pretty big I'm still getting errors like this one: [...]

Ghidra's jumptable recovery is not as good as it could be (as discussed in #2628). It could very well be that, in your case, the decompiler doesn't realise the index into the jumptable is constrained to be less than 1024. I recently submitted a PR (#6070) that might improve your decompiler output (if iVar1 is the result of a % operation). It'd be helpful if you could share the function that caused the decompiler to not identify the jumptable properly.

You could try using the SwitchOverride.java script to manually tell the decompiler about the jumptable, but that doesn't always work.

[astrelsky]

It's a known issue that the decompiler sometimes (regularly?) misses such situations, reported as #5601. @RootCubed posted a patch that seems to work fine. The issue has also been marked internal, so I'm hopeful this situation will improve soon. You should try applying the patch in the issue thread and see if that works for you. Any further comments relating to this should probably go in that thread as well.

(Always?)