LINUX.ORG.RU

Извлечение отладочной информации


0

0

Есть программа на си. компилируется под AVR, но думаю это не принципиально. Собирается со всей отладочной информацией.

Необходимо как-то (жедательно из готового elf-а, но можно и из любых других файлов, создаваемых на этапе компиляции) извлечь максимум информации о переменных (имена и адреса в ОЗУ). Для структур нужно получить значения полей и их названия. Нужно это все для следующего: много устройств, под отладку все поставить нереально. Иногда случаются assert-ы. При попадании в такой assert устройство начинает выгоять дамп памяти в сом-порт. Задача по дампу восстановить значения как можно большего числа переменных в программе. Практически все данные упакованы в структуры и являются глобальными.

★★★★

Ответ на: комментарий от anonymous

Ну во-первых уже. Ничего подходящего не нашел. Во вторых, нужно делать автоматически или максимальо автоматизированно. В идеале это будет скрипт, которму на вход сваливается вывод nm, objdump, черт-его-знает-чего-еще и дамп. На выходе - человеко-читаемый отчет.

В принципе подойдет, если в gdb как-то залить образ памяти и загрузить elf, но я не нашел как его можно залить.

alexru ★★★★
() автор топика
Ответ на: комментарий от anonymous

++
я и говорю man gdb - ну, накрайняк google:gdb

anonymous
()
Ответ на: комментарий от alexru

> Иногда случаются assert-ы. При попадании в такой assert устройство начинает выгоять дамп памяти в сом-порт

дамп памяти это не core файл?

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Я не знаю формата core файла. В моем случае это будет просто 8к бинарных данных. Если gdb примет это как core (в чем я сомневаюсь, так как по моим представлениям нужно еще как минимум состояние регистров), то хорошо.

alexru ★★★★
() автор топика
Ответ на: комментарий от anonymous

>man gdb

конкретно, watch, inspect, print. Ещё можно DDD посмотреть, он умеет визуализировать структуры с указателями, графы.

anonymous
()
Ответ на: комментарий от alexru

> Я не знаю формата core файла. В моем случае это будет просто 8к бинарных данных.

Значит, придётся привести эту штуковину к формату core и пользоваться удобными инструментами (gdb и всё что на нём основано), или разбирать этот дамп вручную при помощи очередного велосипеда, на разработку которого потратив ещё X месяцев (или вы думаете, что напишете программу с почти полной функциональностью отладчика быстрее, чем за месяц?)

anonymous
()
Ответ на: комментарий от alexru

Кстати, можешь посмотреть исходники ядра Linux на предмет того, как файл /proc/kcore формируется. Это считай что дамп всей памяти машины в формате core.

anonymous
()
Ответ на: комментарий от anonymous

Core файл оказался простым elf и сделать его можно из бинарника, но появляется проблема. GDB (что логично) не подключает core файл, пока цель не поставлена под отладку. Сделать это невозмонжо. У железки нет связи с GDB (прямая отладка при помощи gdb тоже невозможна).

Так что из вариантов - либо парсит все-таки, либо писать gdb-stub минимальный, что плохо, так как места мало и по времени тоже неизвестно сколько займет.

alexru ★★★★
() автор топика
Ответ на: комментарий от alexru

Мне почему-то очень кажется, что то, что ты ищешь, уже было кем-то сделано и где-то на sourceforge лежит проект...

anonymous
()
Ответ на: комментарий от anonymous

Что-то не могу ничего найти. В принципе вся отладочная инфа лежит в в stabs фоомате, который довольно простой, но объемный и парсер за пару часов действительно не напишешь.

Может кто видел такой парсер отдельно от GDB?

alexru ★★★★
() автор топика

Не знаю как у AVR работает gcc -g, но у x86 я собираю бинарники с -g, потом стрипаю (strip(1)). Генерящиеся core нормально открываются в gdb с нестрипанными символами.

sf ★★★
()

Опция -Map,file_name.map при ликовании. Создаст file_name.map со всеми адресами секций и переменных.

Или objdump -h -S сделает .lst файл с дисасемблированием всего и вся.

kpanic ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.