Сообщение Re[4]: linux. Как определить, что "дёргает" функцию? от 06.09.2014 2:53
Изменено 06.09.2014 2:58 zaufi
Здравствуйте, 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? как он вообще собрался в таком случае... как правило это результат криворукостьи вендора или маинтэйнера или дистромэйкера (что реже)
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? как он вообще собрался в таком случае... как правило это результат криворукостьи вендора или маинтэйнера или дистромэйкера (что реже)
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 маинтэйнера) или дистромэйкера (что реже)
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 маинтэйнера) или дистромэйкера (что реже)