gcc сказать регистру, скомпилированному из какой переменной - PullRequest
Новая
       54

gcc сказать регистру, скомпилированному из какой переменной

1 голос
/ 03 февраля 2011

Мне нужно знать, из какой переменной составлен регистр двоичной инструкции в файле obj.
Вкратце: отображение из регистра в переменную для каждой инструкции

Пример: предположим, что objdump дает фрагмент файла obj в виде: 

MOV R1 5        # move 5 to register R1
SW R2 SP[-20]   # store the value of R2 to address SP-20

Как мы могли знать, что R1 хранит переменную, скажем, var1 из исходного кода? А R2 хранит var2 ?

Я искал в документации readelf , к сожалению, зря.
(Хотя это может дать мне отображение строки между источником и двоичным файлом, это не поможет мне больше)

Затем я искал некоторые варианты отладки gcc и компоновщика. Нашел полезную информацию, но они до сих пор не решили мою проблему.
Информация, которую я нашел:

  • Опция -fdump-rtl-vartrack может отслеживать все переменные и представляется полезной. Но я не нашел ожидаемый файл дампа * .vartrack при компиляции с этой опцией.
  • Опция * fdump-rtl-vartrack-uid показывает уникальный идентификатор (DECL_UID) для каждой переменной. Но я получил эту ошибку при использовании: cc1: error: нераспознанная опция командной строки "-fdump-tree-uid"
  • Option fdump-rtl-lreg выводит локальное распределение регистров, но я не понимаю, как он может подсказать мне преобразование из reg в переменную.

У кого-нибудь есть опыт или идея?

Спасибо всем!

взломать ...

Ответы [ 3 ]

0 голосов
/ 23 февраля 2011

Опция "-fverbose-asm" в GCC может немного помочь. Он аннотирует вывод компилятора именами переменных. К сожалению, имена часто являются временными значениями, придуманными компилятором, такими как «D.1234». Это все еще может помочь вам понять, что происходит.

Попробуйте скомпилировать что-нибудь простое и посмотрите: 

gcc -g -O0 -S -fverbose-asm foo.c -o foo.s

Отладчик, такой как GDB, определяет, где хранятся переменные в заданной точке вашей программы (для большинства систем), используя отладочную информацию DWARF, сгенерированную компилятором и сохраненную в объектном файле. Если ваша система использует DWARF, то readelf сделает для вас очень простую интерпретацию этой информации. Попробуйте это: 

readelf --debug-dump=info foo.o

Это явно не тривиально для декодирования. Если вы хотите попробовать, то ознакомьтесь со стандартом (ами) DWARF на http://dwarfstd.org/.

0 голосов
/ 04 июля 2019

Для этого вы можете использовать флаги: 

gcc foo.c -da -dp -fdump-tree-all-raw-lineno

Где:

-da произвести все дампы RTL

-dp аннотировать вывод ассемблера комментарием, указывающим, какой используются шаблоны и альтернативы.

-fdump-tree-all-raw-lineno Включает отображение номеров строк для операторов.

Это создаст около 167 файлов, каждый из которых означает различные этапы GIMPLE и RTL, оптимизацию и так далее. Вот простое объяснение того, что происходит:

https://www.cse.iitb.ac.in/~uday/courses/cs715-09/gcc-rtl.pdf

Самые полезные дампы: 

foo.c.227t.optimized
foo.c.229r.expand
foo.c.259r.combine
foo.c.307r.finish

и несколько других для разных целей.

0 голосов
/ 03 февраля 2011

Довольно часто компилятор создает смешанный список ассемблера / исходного кода.Он покажет исходный код, который он скомпилировал, а под ним - сгенерированный ассемблерный код.Быстрый Google дает

http://www.delorie.com/djgpp/v2faq/faq8_20.html

...