我有一个例子，某个函数在堆栈上分配/使用一个404字节的临时结构进行内部计算(该函数是自包含的，并在该数据结构中搅乱数据(。从概念上讲，相应的结构似乎由一些32位计数器组成，后面跟着一个int[15]和一个byte[80]数组，然后是一个可能实际使用也可能实际不使用的区域。表中生成的一些数据似乎表示该函数再次用于在临时结构中导航的偏移量。
不幸的是，Ghidra的反编译器在试图理解函数时弄得一团糟：特别是它创建了单独的"；本地"int vars(然后使用指向该var的指针(，它应该是指向函数原始数据结构的指针(例如，指向其中一个数组(。
undefined4 local_17f;
...
dest= &local_17f;
for (i = 0xf; i != 0; i = i + -1) {
*dest = 0;
dest = dest + 1;
}
Ghidra似乎不理解在这一点上实际使用的是基于阵列的数据访问。Ghirda的反编译器随后还生成一个本地auStack316[316]变量，不幸的是，该变量似乎只覆盖了原始ASM代码使用的相应本地数据结构的一部分(至少Ghidra确实注意到使用了临时内存缓冲区(。因此，反编译的代码基本上使用了两个重叠(且已损坏(的阴影数据结构，这两个结构应该正确地只是同一块内存。
有没有办法让Ghidra的反编译器使用函数分配的完整404字节块作为auStack404，从而绕过Ghidra有缺陷的解释逻辑，真正保留ASM代码的原始功能？
我想我找到了一些东西。。在"；上市"查看使用的局部变量布局显示为函数标题下的注释。似乎通过右键单击该评论中相应的本地var行；设置数据类型"；可以应用于相应的局部变量。啊，然后就是我一直在"；函数/"；编辑堆栈帧"：-(