ltrace: не удалось найти .dynsym или .dynstr в & quot; library.so & quot;
Я пытался использовать Ltrace. Я попытался использовать следующую команду для профилирования файла library.so, который используется программой sampleapp, ltrace -c -T --library=library.so --output=out.txt ./SampleApp, Но это показывает вышеуказанную ошибку. Но library.so — это отладочная сборка. Таким образом, таблица символов должна быть там. Я пытался проверить это с objdump --source library.so | grep CreateSocket(), Он возвращает коды, которые используют эту функцию CreateSocket (). Это означает, что он содержит таблицу символов. Чем вызвана эта ошибка?
Связанный пост: измерять загрузку ЦП в секунду динамически связанной библиотеки
Решение
Это зависит от того, как исполняемый файл SampleApp был создан. Вы увидите эту ошибку, если она была статически связана. ltrace работает только для динамически связанных приложений.
Вы можете запустить ldd SampleApp показать зависимости общего объекта. Он был динамически связан и имеет зависимость от libc, вывод ldd будет содержать такую строку:
libc.so.6 => /usr/lib/libc.so.6 (0x00007fb24ac53000)
В этом случае вы можете использовать опцию ltrace --library=libc.so.6 и это должно работать. Тем не мение, --library=libc.so не будет соответствовать (вы не получите сообщение об ошибке, но вызов библиотеки не будет найден).
Когда статически связаны, ldd SampleApp вместо этого покажет этот вывод:
not a dynamic executable
Мое предположение, что это из-за статического связывания может быть неправильным. Важным моментом, однако, является то, что если ltrace показывает эту ошибку, диагностику нужно начинать с самого исполняемого файла (двоичного файла) и способа его создания (параметры компоновщика), а не с общей библиотеки.
Вопрос Как работает ltrace (инструмент трассировки библиотеки)? есть некоторые хорошие ссылки, чтобы понять больше о внутренностях ltrace.
Другие решения