Есть ли инструменты для проверки символов в кросс-скомпилированных .so файлах - PullRequest
Новая
       22

Есть ли инструменты для проверки символов в кросс-скомпилированных .so файлах

3 голосов
/ 07 ноября 2008

У меня есть приложение, которое загружает .so файлы как плагины при запуске, используя dlopen()

Среда сборки работает на оборудовании x86, но приложение кросс-компилируется для другой платформы.

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

Прежде чем написать скрипт для проверки символов, используя вывод nm, мне интересно, знает ли кто-нибудь об утилите, которая уже делает это?

edit 1: немного изменил описание - я не просто пытаюсь проверить символы в .so, а скорее в комбинации нескольких .so и самого приложения - т.е. после того, как приложение загрузило все .so, будут ли еще неразрешенные символы.

Как было предложено в ответах (спасибо Martin v. Löwis и tgamblin), nm легко идентифицирует отсутствующие символы в одном файле, но не может легко определить, какой из этих символов был разрешен в одном из других загруженных модули.

Ответы [ 3 ]

2 голосов
/ 07 ноября 2008

В идеале, кросс-нм инструмент является частью вашего кросс-компиляторного набора. Например, если вы собираете GNU binutils для кросс-компиляции, будет также предоставляться кросс-нм (вместе с кросс-objdump).

1 голос
/ 27 марта 2009

Ограничения в nm, оказалось, означали, что не было возможности использовать для полной проверки символов. В частности, nm будет отображать только экспортированные символы.

Однако readelf создаст полный список вместе со всеми зависимостями библиотеки.

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

Это повторяется до тех пор, пока не будут найдены новые библиотеки.

Если это сделано для исполняемого файла и всех файлов dlopen() ed .so, это даст хорошую проверку неразрешенных зависимостей, которые могут встретиться во время выполнения.

1 голос
/ 07 ноября 2008

Не могли бы вы использовать для этого рекурсивную версию ldd? Кто-то, кажется, написал скрипт , который может помочь. Это, по крайней мере, говорит о том, что все библиотеки зависимостей могут быть разрешены, если они были указаны в .so в первую очередь правильно. Вы можете гарантировать, что все зависимости указаны в .so с опциями компоновщика, и этот плюс рекурсивный ldd гарантирует отсутствие неразрешенных символов.

У линкеров часто есть возможность сделать неразрешенные символы в общих библиотеках ошибкой, и вы можете использовать это, чтобы вообще не проверять. Для GNU ld вы можете просто передать --no-allow-shlib-undefined, и вы гарантировано, что если он создаст .so, у него не будет неразрешенных символов. Из документации GNU: 

   --no-undefined
       Report  unresolved  symbol  references  from regular object files.
       This is done even if the linker is creating a non-symbolic shared 
       library.  The switch --[no-]allow-shlib-undefined controls the 
       behaviour for reporting  unresolved references found in shared
       libraries being linked in.

   --allow-shlib-undefined
   --no-allow-shlib-undefined
       Allows (the default) or disallows undefined symbols in shared 
       libraries.  This switch is  similar  to  --no-undefined  except
       that  it determines the behaviour when the undefined symbols are
       in a shared library rather than a regular object file.  It does 
       not affect how undefined symbols in regular object files are 
       handled.

       The reason that --allow-shlib-undefined is the default is that the 
       shared library being specified  at  link  time may  not  be  the  
       same as the one that is available at load time, so the symbols might 
       actually be resolvable at load time.  Plus there are some systems, 
       (eg BeOS) where undefined symbols in shared libraries is  normal.   
       (The kernel patches them at load time to select which function is most
       appropriate for the current architecture.  This is used for example to
       dynamically select an appropriate memset function).  Apparently it is 
       also normal for HPPA shared libraries to have undefined symbols.

Если вы собираетесь пройти проверку после ссылки, я согласен с Мартином, что, вероятно, вам лучше всего выбрать nm. Я обычно просто выбираю 'U' в выводе, чтобы проверить наличие неразрешенных символов, так что я думаю, что написать довольно простой сценарий.

...