gdb не видит debug symbols

strip'ом бинари не чистятся?

нет, на это первым делом проверили. ни стрипа, ни -S/-s у ld

Попробуй

gcc -g -ggdb file.c

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

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

-ggdb - эффекта нет

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

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

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

-O1

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

Ты бы лучше для начала разобрался, что у тебя бинарь стрипает.

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

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

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

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

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

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

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

-Wl,--strip-all?

gdb + см. в асм. Чо тебе еще предложить то (=-

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

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

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

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

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

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

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

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

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

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

так и есть

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

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

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