Comment puis-je savoir quels sont les symboles exportés d'un objet partagé?

Question

J'ai un objet partagé (dll). Comment puis-je savoir quels sont les symboles exportés?

Answer 1

Avez-vous un "objet partagé" (généralement une bibliothèque partagée sous AIX), une bibliothèque partagée UNIX ou une DLL Windows? Ce sont toutes des choses différentes, et votre question les tous :-(confond

• Pour un objet AIX partagé, utilisez dump -Tv /path/to/foo.o.
• Pour une bibliothèque partagée ELF, utilisez readelf -Ws /path/to/libfoo.so, ou (si vous avez nm GNU) nm -D /path/to/libfoo.so.
• Pour une bibliothèque partagée UNIX non-ELF, s'il vous plaît indiquer qui UNIX vous intéresse.
• Pour une DLL Windows, utilisez dumpbin /EXPORTS foo.dll.

Answer 2

voir man nm

GNU nm liste les symboles des fichiers objets objFile .... Si aucun objet fichiers sont comme arguments, nm suppose que le fichier a.out.

Answer 3

Habituellement, vous auriez également un fichier d'en-tête que vous incluez dans votre code pour accéder aux symboles.

Answer 4

objdump est un autre bon sur linux.

Answer 5

Vérification de * nix nm. Sur Windows, utilisez le programme Dependency Walker

Answer 6

Utilisation: nm --demangle <libname>.so

Answer 7

S'il est un fichier DLL Windows et votre système d'exploitation est Linux puis utilisez winedump:

$ winedump -j export pcre.dll 

Contents of pcre.dll: 229888 bytes 

Exports table: 

    Name:   pcre.dll 
    Characteristics: 00000000 
    TimeDateStamp: 53BBA519 Tue Jul 8 10:00:25 2014 
    Version:   0.00 
    Ordinal base: 1 
    # of functions: 31 
    # of Names:  31 
Addresses of functions: 000375C8 
Addresses of name ordinals: 000376C0 
Addresses of names: 00037644 

    Entry Pt Ordn Name 
    0001FDA0  1 pcre_assign_jit_stack 
    000380B8  2 pcre_callout 
    00009030  3 pcre_compile 
... 

Answer 8

La façon multiplateformes (croix non seulement -plateforme elle-même, mais travaille également, à tout le moins, à la fois avec *.so et *.dll) utilise reverse-engineering framework radare2. Par exemple:

$ rabin2 -s glew32.dll | head -n 5 
[Symbols] 
vaddr=0x62afda8d paddr=0x0005ba8d ord=000 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_multisample 
vaddr=0x62afda8e paddr=0x0005ba8e ord=001 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_tbuffer 
vaddr=0x62afda8f paddr=0x0005ba8f ord=002 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_texture_compression_FXT1 
vaddr=0x62afdab8 paddr=0x0005bab8 ord=003 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_AMD_blend_minmax_factor 

En prime, rabin2 reconnaît le mutiler nom de C, par exemple (et aussi avec le fichier .so):

$ rabin2 -s /usr/lib/libabw-0.1.so.1.0.1 | head -n 5 
[Symbols] 
vaddr=0x00027590 paddr=0x00027590 ord=124 fwd=NONE sz=430 bind=GLOBAL type=FUNC name=libabw::AbiDocument::isFileFormatSupported 
vaddr=0x0000a730 paddr=0x0000a730 ord=125 fwd=NONE sz=58 bind=UNKNOWN type=FUNC name=boost::exception::~exception 
vaddr=0x00232680 paddr=0x00032680 ord=126 fwd=NONE sz=16 bind=UNKNOWN type=OBJECT name=typeinfoforboost::exception_detail::clone_base 
vaddr=0x00027740 paddr=0x00027740 ord=127 fwd=NONE sz=235 bind=GLOBAL type=FUNC name=libabw::AbiDocument::parse 

fonctionne avec les fichiers objet aussi:

$ g++ test.cpp -c -o a.o 
$ rabin2 -s a.o | head -n 5 
Warning: Cannot initialize program headers 
Warning: Cannot initialize dynamic strings 
Warning: Cannot initialize dynamic section 
[Symbols] 
vaddr=0x08000149 paddr=0x00000149 ord=006 fwd=NONE sz=1 bind=LOCAL type=OBJECT name=std::piecewise_construct 
vaddr=0x08000149 paddr=0x00000149 ord=007 fwd=NONE sz=1 bind=LOCAL type=OBJECT name=std::__ioinit 
vaddr=0x080000eb paddr=0x000000eb ord=017 fwd=NONE sz=73 bind=LOCAL type=FUNC name=__static_initialization_and_destruction_0 
vaddr=0x08000134 paddr=0x00000134 ord=018 fwd=NONE sz=21 bind=LOCAL type=FUNC name=_GLOBAL__sub_I__Z4funcP6Animal