где-то очень неявно у меня дёргается библиотечная функция
т.е. в коде вызова этой функции 100% нет. Видимо какая-то фукнция вызывает библиотечный вызов, вызывающий его или что-то более хитрое. Проблема в том, что линкер в силу настроек не может её увидеть и выдаёт undefined symbol.
функция глубоко зарыта в код линуха, в типовых хедерах её просто нет.
нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
Здравствуйте, Molchalnik, Вы писали:
M>где-то очень неявно у меня дёргается библиотечная функция M>нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
gdb. Подключаешься к работающему процессу, ставишь точку останова куда надо, и вперед, до победного.
Здравствуйте, jazzer, Вы писали:
J>gdb. Подключаешься к работающему процессу
аэм... так ведь не компилится? Линкер стопорится с ошибкой "функция (объектник такой-то) undefined "
З.Ы. свою проблему ценой больших временных потерь я решил, функцию дёргал жсс по умолчанию из-за того, что в коде у статически заданного объекта был деструктор. Достаточно убрать статическое создание объекта на динамическое или деструктор заменить функцией Destruct(), и всё Ок. Но ответ всё равно интересен. Для образования.
Здравствуйте, Molchalnik, Вы писали:
M>где-то очень неявно у меня дёргается библиотечная функция
M>т.е. в коде вызова этой функции 100% нет. Видимо какая-то фукнция вызывает библиотечный вызов, вызывающий его или что-то более хитрое. Проблема в том, что линкер в силу настроек не может её увидеть и выдаёт undefined symbol.
M>функция глубоко зарыта в код линуха, в типовых хедерах её просто нет.
M>нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
попробуй nm по модулям, а потом objdump -DC foo.o и поглядеть.
Re[4]: linux. Как определить, что "дёргает" функцию?
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Molchalnik, Вы писали:
M>>Для образования.
L>Емнип, strace если бы не спас, то мог бы сильно помочь, как минимум
strace показал бы syscallы, а не "библиотечные" функции (только если они приводят к вызову syscall'a: такие как connect, read, write, open, …).
для отслеживания библиотечных функций экспортируемых динамическими библами есть ltrace.
но и он, разумеется не поможет, если "функция" (зарытая глубоко-приглубоко в "код линукса" (кстати где это? %)) не экспортируется или вообще в коде линукса является inline'ом...
100% поможет gdb, как уже написал уважаемый jazzer, но ТС оказывается говорил о проблеме с компиляцией (точнее линковкой).
в таком случае нужно смотреть что за объектник пытается ее дергать, а потом препроцесснуть соответствующий translation unit и погрепать.
но может так получиться, что undefined function находится в какой-либо "чужой" библиотеке (.so или .a (что еще хуже)) -- в таком случае разборки уже нужно проводить с тем пакетом, который предоставляет "коцанную" библу -- с какого перепуга спрашивается она там undefined? как он вообще собрался в таком случае... как правило это результат криворукостьи вендора (package маинтэйнера) или дистромэйкера (что реже)
Здравствуйте, monah_tuk, Вы писали:
_>Здравствуйте, Molchalnik, Вы писали:
M>>где-то очень неявно у меня дёргается библиотечная функция
M>>т.е. в коде вызова этой функции 100% нет. Видимо какая-то фукнция вызывает библиотечный вызов, вызывающий его или что-то более хитрое. Проблема в том, что линкер в силу настроек не может её увидеть и выдаёт undefined symbol.
M>>функция глубоко зарыта в код линуха, в типовых хедерах её просто нет.
M>>нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
_>попробуй nm по модулям, а потом objdump -DC foo.o и поглядеть.
ну увидит он там в лучшем случае 'U _bar' и дальше? ) -- это и так было понятно... у ТС "не линкуется" же %)
в худшем случае undefined находится в "чужой" библе... что вообще obdump'ом не диагностируется никак...
Re[3]: linux. Как определить, что "дёргает" функцию?
Здравствуйте, zaufi, Вы писали:
M>>>нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
_>>попробуй nm по модулям, а потом objdump -DC foo.o и поглядеть.
Z>ну увидит он там в лучшем случае 'U _bar' и дальше? ) -- это и так было понятно... у ТС "не линкуется" же %) Z>в худшем случае undefined находится в "чужой" библе... что вообще obdump'ом не диагностируется никак...
Препроцессор, посоветованный вами в предыдущем посте тоже ничего не даст, ибо, чует моё сердце, это что-то уже сгенерированное компилятором. Моя же рекомендация выглядит так: найти при помощи nm этот самый _bar, дальше дизассеблирование, при наличии отладочного кода, вдумчивое изучение результата. Да, если этот вызов по факту окажется где-то снаружи — ничего хорошего не выйдет.
Ещё недурственно было бы получить от автора, что это вообще за символ и была ли попытка собрать минимальный пример, на котором эта бага воспроизводится. Возможно просто гугл по этому выхлопу поможет найти причину.
Здравствуйте, Molchalnik, Вы писали:
M>нужен инструмент, который позволит увидеть, что "дёргает" эту функцию.
Напиши свой либ, экспортирующий эту функцию, а в её реализации поставь точку останова в отладчик, собери так и запусти это всё под отладчиком...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
У Я. была неплохой доклад на тему поиска похожих вещей. Возможно тем, кто в теме, будет немного и поверхностно, но мне очень понравилось.
Не знаю, насколько будет полезено, но вдруг: C++: препроцессор, компилятор, компоновщик
) -- это и так было понятно... у ТС "не линкуется" же %)
