#c #types
#c #типы
Вопрос:
Позвольте мне сначала попытаться дать некоторую информацию. Я работаю над каким-то проектом с некоторым микроконтроллером (AVR), к которому я получаю доступ через некоторый интерфейс (UART). Я выполняю прямую запись в его глобальные переменные, а также могу напрямую выполнять функции (записывать аргументы, запускать выполнение, считывать возвращаемые значения).
Код AVR на C скомпилирован с помощью набора инструментов GCC. Компьютер, который взаимодействует с ним, выполняет код python. На данный момент я легко импортировал информацию об адресе и размере в python, проанализировав вывод ‘objdump -x’. Теперь, что значительно повысило бы мою разработку, так это информация о типах символов (типы и размеры элементов structs, значения enums, аргументы функций и возвращаемые значения, …).
Почему-то это казалось обычным делом, которое люди делают ежедневно, и я наивно ожидал готовых инструментов python при запуске. Ну, не так просто. К настоящему времени я потратил много часов на изучение различных способов достижения этой цели. Одним из подходов было бы просто проанализировать код C (используя, например, pycparser). Но, похоже, мне пришлось бы, по крайней мере, «предварительно проанализировать» код, чтобы исключить различные неподдерживаемые конструкции и различные проблемы с упорядочением и так далее. Кроме того, теоретически проблема заключалась бы в том, что компилятор выполнял бы некоторые оптимизации, такие как переупорядочение структуры или перечисления и так далее. Я также изучал различные варианты gcc, gdb и objdump, чтобы получить такую информацию. Потратил некоторое время на поиск инструментов для извлечения информации из различных форматов отладки (dwarf, stabs). Самое близкое, что я получаю до сих пор, — это сброс отладочной информации stabs с помощью опции objdump -g. Это выводит C-подобную информацию, которую я затем проанализировал бы с помощью pycparser или самостоятельно.
Но прежде чем я потратил на это свое время, я решил задать здесь вопрос, сильно надеясь, что кто-нибудь поразит меня, возможно, совершенно другим подходом, о котором я просто не подумал.
Комментарии:
1. Насколько мне известно, компилятору не разрешено
struct
переупорядочивать so, поскольку это потенциально может нарушить совместимость двоичных файлов. (Иenum
переупорядочение не имеет смысла. Что бы вы изменили порядок?)2. Верно. Насколько я знаю, это не разрешено стандартом. Но, как и в моем случае, когда двоичная переносимость на самом деле не имеет значения, даже переупорядочение может иметь смысл. Например. компилятор может присвоить 0 наиболее часто используемому значению enum . Я не верю, что какой-либо компилятор действительно делает что-то подобное. Просто хотел отметить, что я предпочитаю подход после компиляции. Но любое готовое решение было бы лучше, чем кодировать это самостоятельно.
Ответ №1:
Существует довольно хороший инструмент под названием c2ph, который сбрасывает анализируемое описание типов и размеров (используя отладочную информацию в качестве источника)
Комментарии:
1. Это кажется хорошим решением, по крайней мере, для части моей проблемы. Но это выдает мне ошибку независимо от того, пытаюсь ли я использовать файл * .s или * .c. Вот ошибка, если она имеет какое-либо значение: ошибка в массиве: (0,71) = ar(0,72) = r(0,72);0;-1;;0;22;(0,11),0,184;; в _jmp_buf:T(0,70)=s23_jb:(0,71)=ar(0,72)=r(0,72);0;-1;;0;22;(0,11),0,184;; в /usr/bin/pstruct строка 998, <> строка 65.
Ответ №2:
Чтобы ответить самому себе … это то, что я нашел:
http://code.google.com/p/pydevtools/
На самом деле я знал об этом раньше, но сначала это не сработало для меня. Итак, в основном я сделал его совместимым с Python 3 и также внес несколько других исправлений / изменений — здесь вы можете получить все это:
http://code.google.com/p/pydevtools/source/checkout
На самом деле есть еще какой-то код, который фактически использует этот модуль, но он еще не завершен. Я, вероятно, добавлю его, когда закончу.