NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
52.19k stars 5.91k forks source link

Decompiler still has some array-struct iteration troubles #2464

Open magcius opened 4 years ago

magcius commented 4 years ago

Describe the bug PPC / Gekko. I have a pointer to an array of 0xd0-sized structures (MogucchiHillPiece). There is a loop that starts a counter (iVar5) at 0 and increments by 0xd0. Sometimes Ghidra is able to figure this out, but most frequently, it produces difficult-but-not-impossible code that's something like (MogucchiHillPiece*)((int)&(pArray + iVar5)). Not super important, but since array improvements were mentioned in the 9.2 release notes, I figured I'd file it.

To Reproduce Ghidra DB available on request.

Expected behavior Better code generation, maybe something like this->mpPieces[iVar5 / 0xd0]->mpParentActor = this;. Maybe the invention of a macro, e.g. this->mpPieces[INDEX(iVar5)] ? Basically, something slightly more readable than the int-and-cast-fest that currently exists.

Screenshots image

Environment (please complete the following information):

m-7761 commented 3 years ago

In my case if there's any arrays in the structures Ghidra (bizarrely) wants to add the offset to the first array and then subtract the array's member offset (none of this is in the disassembly) to get back to the front of the structure. What beats all is to get to the array member it goes through a pointer (the owner) which is the array being iterated and is typed to the iteration size.

To make matters worse if I retype the iterator variable to match the data structure's type Ghidra will cast to its type instead of taking the straight offset, and then it will generate a new variable of the wrong type for all subsequent uses of that variable, so it's hopeless to retype.