NationalSecurityAgency
Decompiler is sometimes too aggressive resolving array indices.
Describe the bug The decompiler sometimes is too aggressive when it tries to resolve the index into an array access. When some C code is similar to " array[index - 2] = ... ", it will often decompile to "newarray[index]" where "newarray" is the address behind "array" minus 2 elements.
To Reproduce Steps to reproduce the behavior:
- Download the Ghidra database from https://github.com/DualTachyon/ghidra-private/issues/3
- Go to function MENU_Invoker1 / 0x803115c
- You can observe an array array such as "(&DAT_20009a1a)[gMenuHistoryPos] == ..."
- You can see in the disassembly at 0x8031182 that is it really gMenuTypeHistory[gMenuHistoryPos - 2].
- The - 2 can also be observed by toggling the RO icon on the top right of the Decompiler window.
Expected behavior It should really display gMenuTypeHistory[gMenuHistoryPos - 2] being accessed. This issue is present in many other variables across the project, but it is not always present in every "index - xyz" access.
Screenshots
Attachments Database available at https://github.com/DualTachyon/ghidra-private/issues/3
Environment (please complete the following information):
- OS: Windows 11
- Java Version: openjdk version "21.0.5" 2024-10-15 LTS
- Ghidra Version: 11.4.2
- Ghidra Origin: Official GitHub release
Additional context Add any other context about the problem here.
Forgot to mention, please suggest other users that might need access to my private repo. Ryan, Chris and Ghidorarex should already have access.
An additional point. If you go to 0x20009a19 and check the cross references, it will lead you to code that does gMenuTypeHistory[Pos - 3].
In the same function, you can see it has no problems doing "index - 3" in other lines. For example:
if (gMenuTree[gMenuHistoryPos - 3] == gMenuOffsetHistory[gMenuHistoryPos - 3]) {