크로스 컴파일 된 .so 파일에서 심볼을 검사 할 수있는 도구가 있습니까?

Question

시작시 플러그인 .so 파일을로드하는 응용 프로그램이 있습니다. dlopen()

x86 하드웨어에서 빌드 환경이 실행 중이지만 응용 프로그램이 다른 플랫폼에서 상호 컴파일되고 있습니다.

(자동 빌드 프로세스의 일부로) 실제로 .so 파일과 응용 프로그램의 조합에 해결되지 않은 기호가 없는지 확인하는 것이 좋을 것입니다. 응용 프로그램을 배포하십시오.

nm의 출력을 사용하여 테스트 기호에 스크립트를 작성하기 전에 이미이 작업을 수행하는 유틸리티를 아는 사람이 있는지 궁금합니다.

---

편집 1 : 약간의 설명을 변경 - 난 그냥 .so를의 심볼을 테스트하려고하지만, 오히려 여러 .so는 년대와 응용 프로그램 자체의 조합 아니에요 - 예. 응용 프로그램이 .so 파일을 모두로드 한 후에도 여전히 확인되지 않은 기호가 있는지 여부를 확인합니다.

nm은 답변에서 제안한 바와 같이 (누락 된 마틴 대 Lwwis와 tgamblin) 하나의 파일에서 누락 된 기호를 쉽게 식별하지만로드 된 다른 모듈 중 하나에서 해결 된 기호를 쉽게 식별하지 못합니다 .

Answer 1

크로스 nm 툴은 이상적으로 크로스 컴파일러 제품군의 일부입니다. 예를 들어, 크로스 컴파일을위한 GNU binutils를 빌드한다면 cross-objdump와 함께 cross-nm이 제공 될 것입니다.

Answer 2

ldd의 재귀 버전을 사용할 수 있습니까? 도움을받을만한 사람이 written a script 인 것 같습니다. 이것은 최소한 .so에서 정확하게 지정 되었다면 모든 의존성 라이브러리가 해결 될 수 있음을 말해줍니다. 링커 옵션을 사용하여 .so에서 모든 종속성을 참조하도록 보장 할 수 있으며 재귀 적 ldd는 확인되지 않은 기호를 보장합니다.

링커는 공유 라이브러리에서 확인할 수없는 기호를 오류로 만드는 옵션이 종종 있습니다.이 옵션을 사용하면 전혀 확인하지 않아도됩니다. GNU에서는 --no-allow-shlib-undefined를 넘겨 줄 수 있으며, .so가되면 unresolved symbols을 가지지 않는다는 것을 보장합니다. 는 GNU LD의 문서에서 : 나노 아마 가장 좋은 것을

--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. 

당신이 후 링크 검사로 갈 경우, 마틴에 동의합니다. 보통 출력물에서 'U'를 grep하여 확인되지 않은 기호를 확인하므로 쓰기가 매우 간단한 스크립트라고 생각합니다.

Answer 3

nm의 제한 사항은 포괄적 인 기호 검사기로 사용할 수 없음을 의미합니다. 특히 nm은 내 보낸 기호 만 나열합니다.

그러나 readelf은 모든 라이브러리 종속성과 함께 포괄적 인 목록을 생성합니다.

는 readelf 사용은 할 스크립트를 구축 할 수 있었다 : 사용되는 모든 라이브러리의 목록을 만들기를, 실행에 기호 목록을 작성 (또는 .so를) 미해결의 목록을 작성 symbols -이 시점에서 해결되지 않은 기호가 있으면로드 할 때 오류가 있었을 것입니다.

이렇게하면 새 라이브러리가 발견되지 않을 때까지 반복됩니다.

실행 파일 및 모든 ed .so 파일에 대해이 작업을 수행하면 런타임에 발생하는 확인되지 않은 종속성을 쉽게 확인할 수 있습니다.