Ghidra: Renaming __fastcall/__thiscall function input parameter in decompiler window makes assembly window hard to read

[dennisbabkin]

Bug

Rename a function input variable/parameter in the decompiler window. Then if that variable translates to a CPU register in the assembly code (or to a local stack memory chunk) the assembly window (incorrectly) assumes that any further references to that same register or local stack memory location should be named that as well. This makes assembly code hard to read.

To Reproduce

Follow this screenshot:

Expected behavior

1. Either keep registers unchanged in the assembly window, or provide an option to turn off the substitution with variable names from the decompiler window.

2. Do like it's already done in some opcodes. For instance, the line at address 71a879ff above has: LEA EAX=>local_44,[EBP + -0x40] (OK, I'm neglecting here the silliness of + -0x40) but the EAX=>local_44 although not being a valid assembly code, is quite readable. So why not do the same with PUSH ECX=>hWnd at address 71a87a0a below it.

   Although the PUSH ECX at the bottom (at address 71a87a2f), and the following XOR ECX, EBP should not include hWnd in any way because it has nothing to do with it.

3. Better yet, use the comment on the right of the assembly opcode instead, as such: PUSH ECX ; hWnd.

4. Or, provide an option in settings to let the user select which behavior (that I listed above) they prefer. (Unless such option already exists?)

Environment

• OS: Windows 10 v.1803
• Java Version: 11 (I think. I swear Java is the most annoying thing. None of these worked.)
• Ghidra Version: 9.0.2

[emteere]

There is an option to control turn off this behavior in Edit->ToolOptions->ListingFields->OperandField.

Turn off Markup Inferred Variable References (I think).

There are issues with the current markup mechanism, as mentioned in other entered issues, that are being considered for an alternate algorithm and markup display. Thanks for the suggestions for changes.

[dennisbabkin]

@emteere Oh, thank you. Turning that option off (for now) makes it so much easier to read the assembly window.

... are being considered for an alternate algorithm and markup display ...

If so, having played with the decompiler window in Ghidra, may I suggest another issue with renaming local variables (that is hopefully considered in an alternative algo.)

In a sufficiently large function, the original compiler might have been reusing the local stack memory to store different variables. For instance, earlier on it may have used 4 bytes in stack memory (for x86 code) to store a pointer to the RECT struct, while further down the code it may have stored an int in the same stack memory address. This makes it very confusing when custom-typing the first local variable as RECT * which is further on used as an int.

So suggestion for a new implementation _(and I understand that it would require a substantial overwrite of the current implementation)_ would be to allow users to define a scope (from within a function) for a custom local variable to be used in. Possibly by letting users select a section of code with the mouse and then by invoking a context menu with a right-click. This way, it should be possible to assign multiple local variable names and custom types to the same memory address in stack.