Гидра использует нечетные имена полей, например "._0_4_", для представления нестандартного размера доступа при декомпиляции C - PullRequest
Новая
       93

Гидра использует нечетные имена полей, например "._0_4_", для представления нестандартного размера доступа при декомпиляции C

3 голосов
/ 20 апреля 2020

Я использовал Ghidra для декомпиляции некоторых файлов библиотеки .o, изначально скомпилированных для ARMv7, для которых у меня есть файлы заголовков для некоторых функций и структур.

Допустим, структура имеет несколько однобайтовых члены "char": 

struct myStruct {
   char memberA;
   char memberB;
   char memberC;
   char memberD;
} structInstance;

Где ассемблерный код, предположительно путем оптимизации компилятора при его сборке, обрезает угол и получает доступ к целому 32-битному слову из символов в одном go, тогда декомпилированный код C будет представлять это как: 

structInstance._0_4_

Первый di git (0) является смещением байта, с которого начинается, а второй di git ( 4) количество обращающихся байтов.

Однако, насколько я могу судить, это нестандартно и не будет перекомпилироваться - по крайней мере, не в G CC, и я не могу на самом деле найти любую ссылку на эту запись в любом месте.

Есть ли способ, которым Ghidra может быть настроен вместо этого, чтобы генерировать декомпилированный код, который на самом деле будет действительным - то есть 

*(uint32_t)&structInstance.memberA
...