You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Using sized pointers, say ScriptHandler *32 in a 16-bit app to establish a far pointer, simple arithmetic used to index the array of those objects fails to use the base object size and consequently doesn't recognise the calculation as the index. Something like
turns into *(int *)&pThis->lpScrptHldr_0x16 = *(int *)&pThis->lpScrptHldr_0x16 + iVar4 * -0x402;
instead of (if the pointer is sized 16 - the native pointer size) pThis->lpScrptHldr_0x16 = pThis->lpScrptHldr_0x16 + -iVar4;
admittedly not perfect, but better!
Expected behavior
Array index calculations should only use the pointer size when pointer-to-pointer... (and the index level is NOT at the lowest dereferencing point) is being sought otherwise use its base type size.
Screenshots
See bug description.
Attachments
None.
Environment (please complete the following information):
OS: Windows 11
Java Version: Temurin-21.0.3+9
Ghidra Version: 11.2-DEV
Ghidra Origin: locally built (based upon commit 34ba255)
Additional context
None.
The text was updated successfully, but these errors were encountered:
I recently upgraded a lot of images and I think it's also generally broken right now for a lot of this kind of access. I've noticed a lot of arrays cast as int and then indeed, losing type information (ppc,mips,sparc)
I recently upgraded a lot of images and I think it's also generally broken right now for a lot of this kind of access. I've noticed a lot of arrays cast as int and then indeed, losing type information (ppc,mips,sparc)
I recently upgraded a lot of images and I think it's also generally broken right now for a lot of this kind of access. I've noticed a lot of arrays cast as int and then indeed, losing type information (ppc,mips,sparc)
Hopefully fixed by either #6718 or #6722
I haven't updated to include those yet!
No dice! Tried both fixes together and independently to no effect.
I believe the 2 sizes of pointers is what really needs fixing for my issues. E.g. if a structure contains a pointer and that pointer stores the segment and offset that turns it into a 4-byte pointer which then interferes with Ghidra's internals as they cannot cope with 2 sizes! Is there any hope for that to be investigated?
Maybe the 2 screenshots below illustrate the situation. In the first, pFld0x2->field4_0xa is defined as a pointer of size 32-bits and the second uses the default size (as per cspec (16-bit)).
Describe the bug
Using sized pointers, say
ScriptHandler *32
in a 16-bit app to establish afar
pointer, simple arithmetic used to index the array of those objects fails to use the base object size and consequently doesn't recognise the calculation as the index. Something liketurns into
*(int *)&pThis->lpScrptHldr_0x16 = *(int *)&pThis->lpScrptHldr_0x16 + iVar4 * -0x402;
instead of (if the pointer is sized 16 - the native pointer size)
pThis->lpScrptHldr_0x16 = pThis->lpScrptHldr_0x16 + -iVar4;
admittedly not perfect, but better!
Expected behavior
Array index calculations should only use the pointer size when pointer-to-pointer... (and the index level is NOT at the lowest dereferencing point) is being sought otherwise use its base type size.
Screenshots
See bug description.
Attachments
None.
Environment (please complete the following information):
Additional context
None.
The text was updated successfully, but these errors were encountered: