LINUX.ORG.RU

gdb не видит debug symbols


0

1

На работе столкнулся с проблемой.

Есть некая тулза на С/С++. Билдится собственным модифицированным (а может и не очень, понятия не имею) gcc. Но даже при указании опции -g в бинарник не добавляется отладочная информация.

При загрузке бинаря в gdb тот бодро пишет No debug symbols found nm и objdump - то же самое - No symbols. При этом адрес секции DEBUG - 0x0000000. зато readelf -s вываливает мне кучу символов.

Сталкивался ли кто-нибудь с похожим? Как и откуда скормить дебаг символы gdb?

-g должен передаваться и компилятору, и компоновщику - возможно, где-то потерялась опция, надо смотреть, как собирается программа.

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

компоновщику -g тоже передается. сами Makefile показать не имею физической возможности, к сожалению

marvin_yorke ★★★ ()

может, бинарнику делается strip?

anonymous ()

Еще раз, readelf -s показывает символы из заголовков elf. Посмотри с помошью readelf -S(большая), есть ли в файле .debug секции вообще, 100%, что их там нет.

frey ★★ ()

М.б. скомпилировано с жескими оптимизациями, и из-за этого debug не поддерживается?

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

а можно ли как-либо скормить то что выдает readelf -s дебаггеру? там хотя бы имена функций есть и их адреса. проблема в том, что прога многотредовая, дебаг принтауты в терминале мешаются в одну кучу от разных тредов, и где-то она ловит сегфолт. я хочу узнать, хотя бы в какой функции, а там уже можно будет разбираться

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

билд производится скриптом еби^Wэпических размеров, который писал не я и даже не кто-то из моих коллег и я понятия не имею, что там внутри. Я могу только спрашивать того, кто хоть что-то в этом скрипте понимает. Из того, что я уже узнал, по факту: - билд всегда производится с ключом -g - линковка всегда производится с ключом -g - strip явно нигде не вызывается для данного бинаря - опции -s/-S у линкера не используются

Сейчас мне не столь важно разобраться, где стрип (хотя это было бы очень неплохим бонусом), а важно хоть как-то отдебажить программу.

Помимо кода, который мне надо отдебажить, и для которого есть исходники, статически линкуются пара библиотек. О наличии в них дебаг символов я не знаю (а зря так и не посмотрел). Для одной сырцы есть, для другой - только .a файл. А теперь внимание, вопрос - если в моем объектнике есть символы, то при линковке его с объектником, в котором символов нет, мои символы останутся?

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

Конечно должны оставаться.

Хотя если у них собственные тулзы, то отменить отладку навсегда легко. Правда как тогда пользователь будет искать свои проблемы. Слабо запустить их gcc -S -g ... на простой файл чуть сложнее main() {} и показать результат для начала? Проверить что хоть он после сборки отлаживается.

Собственно в некоторых организациях тулзы автоматом собственный strip (с диким названием) пускают, который меняет и таблицу символов (если библиотека) и сам код, дабы скрыть все что можно от пытливого взгляда.

Чудес не бывает, либо не генерируются компилятором, ассемблером, либо лопает ld (нет ли там скриптика), либо доп. прога.

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

Дебагер должен показывать backtrace с именами функций даже без отладочной информации, если не показывает, то либо действительно strip, либо адреса ничему не соответствуют, такое бывает, когда, например, стек испорчен.

frey ★★ ()

Сваяй тестовую минипрогу, собери ее ручками без всяких скриптов и мейкфайлов вашей гццой и посмотри, подцепятся символы, или нет.

Еще идея есть запустить скрипт, например, под strace и посмотреть, какие бинари дергаются, погрепать наличие там strip.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от frey

бэктрейс показывается. но при сегфолте почему-то дебаггер просто пишет в консоли что-то вроде «Got SIGSEGV - Segmentation fault» и не показывает, где именно. Использую ddd в качестве фронтэнда. Здесь еще момент. Сам запуск бинаря тоже происходит через 100500 враппер-скриптов вместе с десятком других тулз, поэтому я загружаю бинарь в дебаггер, запускаю его штатно и делаю Attach to a process

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

>>без всяких скриптов и мейкфайлов не выйдет. это был один из первых вариантов, но мне его отмели, сказав, что нужно линковать какие-то спецовые либы, местоположение и правильные параметры для которых никто толком не знает.

Есть некий экзампл, который содержит в себе >>простой файл чуть сложнее main() {} и все необходимое для его билда. При попытке побилдить его, получаем то же самое, что и для проги, которую я пытаюсь отдебажить - ELF без символов. Вобщем чую, что придется самому пытаться разобрать тот билд-скрипт и всю вобще систему билда.

По крайней мере надо вытащить из него .o-файлы, которые генерит gcc и посмотреть, есть ли что-то в них. Если есть, то смотреть дальше в линоквку и пост-билд...

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

План абсолютно правильный, надо копать скрипт. Вероятность той или иной формы стрипа выше всего.

Однако, таки что мешает проверить еще и сами тулзы и собрать тест одной командой: gcc -g -o test test.c Это-то отлаживается? Бывает пока чего-то типа -gdwarf-2, -gstabs нет, то символы специфические - gdb не жрет. Некоторые предпочитают опции погорячее.

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

>>Еще раз, readelf -s показывает символы из заголовков elf. Посмотри с помошью readelf -S(большая), есть ли в файле .debug секции вообще, 100%, что их там нет.

так и есть

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

погрэпь ещё ваш «эпический» на предмет install -s

beastie ★★★★★ ()

опппа! .o-шники символов полны и дебаггером подхватываются. значит компилер их генерит. значит либо линкер рубит, либо где-то все-таки стрип... ладно, придет коллега, будем разбираться

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

все, проблема решилась. среди 6000 строк нашелся неприметный стрип. всем спасибо

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