How to attain better decompilation when indexing a previous array-elements fields

[Wall-AF]

I have some assembly that loads the address of an object (in an array of the same type of objects - indentifiable by an earlier loop assignment) and then proceeds to assign the sum of two fields from the previous element by using '-'ve constant offsets in the MOV and ADD instructions:

   11e0:10c6 c4 5e f8     LES        BX,SS:[BP + pHeap]
   11e0:10c9 66 26 8b     MOV        EAX,dword ptr ES:[BX + -0x4]
             47 fc
   11e0:10ce 66 26 03     ADD        EAX,dword ptr ES:[BX + -0x18]
             47 e8
   11e0:10d3 66 83 c0 0c  ADD        EAX,0xc
   11e0:10d7 66 26 89     MOV        dword ptr ES:[BX + 0x18],EAX
             47 18

resulting in

         pHeap->pOffset_0x18 =
              *(long *)&pHeap[0x924].nIdxContent_0xc +
              *(long *)((long)&pHeap[0x923].field6_0x12 + 2) + 0xc;

insted of
pHeap->nOffset_0x18 = pHeap[-1]->nOffset_0x18 + pHeap[-1]->nSize_0x4 + 0xc;

It seems the '-'ve offset is not understood correctly. (Is this something that a modification to ia.sync could solve?)

Whilst maybe expecting pHeap[-1] is a little too optimistic, shouldn't Ghidra's analysis be able to see this and possibly add an additional variable earlier keeping the previous value of pHeap prior to its next assignment?

[Wall-AF]

Maybe a better solution is for Ghidra to recognise the paradigm of using a temporary variable to hold a pointer to the current array's element that is increased by its size to move to the next one and reduce this to the standard array syntax (of the form arr[i]).

I am decompiling a 16-bit Windows suite and wonder if that has a bearing? Does this occur in better supported architectures?

[tamlin-mike]

I believe this is almost an NP-problem. I have seen (32-bit) compiler generate temporary pointers (only held in register) to the middle of a struct (that is part of an array of such structs), then use a different register to hold a pointer to either a whole struct, the same middle-of-struct only for the succeeding/preceeding entry, or to a different part of the struct (including prev/next offset).

Combine that with interleaved inc/dec of the pointers together with reading/writing struct members, or even having one register point to a different array (that have the same memory layout), and a person can spend days trying to entangle it.

While it can produce very tight and/or fast generated code (the Watcom compiler was especially good at this), it indeed can present quite a challenge when trying to rev. it.

The only, and at that only partial "solution" I have seen to this problem is how IDA allows you to manually set a struct-specific offset on a per-assembly-instruction for a specific instruction-used register, and then a prayer that Hex-Rays indeed pick it up when doing the decompilation.

But to find a generic solution, even that the problem is reasonably well understood, is not an easy task. Moreso since different compilers and even different compiler-versions not only uses different idioms, but can apply these optimizations even intermixed in the same basic block. For a decompiler to identify that one of these idioms are in use, then which one(s), and then produce plausible deompiled output is a mathematical complexity worthy of...

Hang on a minute. Math. NSA. Maybe Ghidra could solve this problem! :)

[Wall-AF]

This seems to have been fixed. Unfortunately I don't know what commit did the dirty deed!
@emteere @caheckman @ryanmkurtz can any of you enlighten me please, prior to this being closed???