Open magcius opened 4 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.
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
Environment (please complete the following information):