How can I specify instruction pattern simplifications?

[Thodoris1999]

Compilers often use a series of instructions to accomplish high-level operations, which often called instruction idioms or patterns. PowerPC for example, has an entire guide for compiler writers on how to implement common operations on their architecture https://cr.yp.to/2005-590/powerpc-cwg.pdf

I notice that ghidra often has a hard time understanding these instruction patterns. For example I would want the pattern (Figure 3-52)

# FR2 = 0x4330000080000000
addis R0,R0,0x4330 # R0 = 0x43300000
stw R0,disp(R1) # store upper half
xoris R3,R3,0x8000 # flip sign bit
stw R3,disp+4(R1) # store lower half
lfd FR1,disp(R1) # float load double of value
fsub FR1,FR1,FR2 # subtract 0x4330000080000000

(and ideally any equivalent data flow) to create a single INT2FLOAT pcode that converts R3 to FR1 (provided that FR2=0x4330000080000000). Instead, ghidra produces something along the lines of

((float)((double)CONCAT44(0x43300000,uVar3 ^ 0x80000000) - 4503601774854144.0)

I am new to ghidra, so what would be an appropriate way to implement this?

[astrelsky]

What you would need to do is lie down, try not to cry and then cry a lot. The only way to do this is to add a decompiler rule specifically for it. This requires modification of the decompiler native code and since the decompiler is not extendable at runtime in any way, there is no way for you to provide the changes to others without providing ghidra in its entirety. You could open a pull request and wait forever (decompiler changes are almost never even reviewed). Something very processor specifically would be unlikely to be accepted either.

I know this is definitely what nobody wants to hear but I'm just calling it how I see it.

[Thodoris1999]

Thanks,

A bit of a pity but not too awful I guess. It seems simple if I follow the same procedure as here.

What bums me more is that to my new-to-ghidra self there does not seem to exist an easy way to debug these rules. In case you've worked with those internals, do you know a good way to log info about the AST at the decompiler cpp code?

[astrelsky]

I'm not sure. There is a separate decompiler debug build for debugging but I don't know anything about the AST. Maybe @Pokechu22 would know though.

[Pokechu22]

Yeah, unfortunately, I'm not aware of a way of debugging the rules either; #2810 was done by a lot of experimentation and seeing what worked.

For what it's worth, the issue you're running into is at #2850, though it seems like there's a related issue at #4586.

[LukeSerne]

First of all, sorry for the late response.

While working with Ghidra's decompiler output, I also noticed that it's often quite unclear how a function's decompiled representation came to be. Additionally, writing the simplification rules used by the decompiler is quite verbose, which also makes it harder to understand what a rule is doing. To alleviate this, I started work on 2 tools that I have already found quite helpful. I'm linking them here, hoping they might assist you in understanding and improving the behaviour of Ghidra's decompiler.

1. RuleChef, which can translate a high-level description of a simplification rule into the C++ code that implements this rule. This tools enables you to write declarative rules like the one below, and let the tool generate the C++ code, which should save time and bugs. While it's currently quite limited in the types of constraints (and thus rules) it allows and the C++ code that it generates, I intend to remove or reduce these limitations in the future.

SignBitExtract:
    INT_RIGHT(x, |x| * 8 - 1) :- {
        x = INT_OR(y, INT_MULT(y, -1:|y|))
    }
    => INT_ZEXT(INT_NOTEQUAL(y, 0:|y|))

2. DecompVis, which is a UI-program that draws the data flow graph of a specific function that is decompiled by Ghidra. It not only shows the state of the data flow graph, but it also shows the state after every simplification rule that was applied, as well as the name of the simplification rule that was applied. This allows you to "debug" function decompilation, and find out what rules caused a wrong output. Additionally, you can use it to find out why a rule was applied that you did not expect. A screenshot of the program is shown below.
   
   Under the hood, this program uses a debug build of the decompiler (decomp_dbg), together with the trace address command which prints some sort of diff after each application of a simplification rule. The rest of the program parses that output and attempts to display it in a user-friendly way.

While I've already used both tools, and they have been of help to me, they are still in development. As such, don't hesitate to create issues on their repo's if you are using the programs and you find any bugs / anything that could be improved.

[Thodoris1999]

Awesome work! This is extremely helpful