How do I list the symbols in a .so file

Question

How do I list the symbols being exported from a .so file? If possible, I'd also like to know their source (e.g. if they are pulled in from a static library).

I'm using gcc 4.0.2, if that makes a difference.

Walcott

The platform makes a difference. Apple provides a GCC 4.0, but its nm does not respond to some options, like -D and -g (IIRC). – Copyhold

This prints nothing on Mac OS. – Turmel

@Copyhold because that's BSD nm, not GNU nm. – Lengthen

Answer 1

The standard tool for listing symbols is nm, you can use it simply like this:

nm -gD yourLib.so

If you want to see symbols of a C++ library, add the "-C" option which demangle the symbols (it's far more readable demangled).

nm -gDC yourLib.so

If your .so file is in elf format, you have two options:

Either objdump (-C is also useful for demangling C++):

$ objdump -TC libz.so

libz.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000002010 l    d  .init  0000000000000000              .init
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __errno_location
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable

Or use readelf:

$ readelf -Ws libz.so
Symbol table '.dynsym' contains 112 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000002010     0 SECTION LOCAL  DEFAULT   10
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND free@GLIBC_2.2.5 (14)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.2.5 (14)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable

Yungyunick

This doesn't always work with .so files, though, and so you may have to use the "readelf" solution mentioned in another answer. – Garik

Great answer - but I don't get the function signatures from nm, objdump or readelf. Do you know how I can get the function signature (parameters) as well? – Hypothec

Note that OS X versions of nm are missing the '-C' option for demangling symbols. c++filt can be used instead. Example script here: v8.googlecode.com/svn/branches/bleeding_edge/tools/mac-nm nm -g /usr/lib/libstdc++.6.dylib | c++filt -p -i – Malapropism

Note that readelf -Ws will show you all symbols, and nm -g shows only the externally visible symbols. This may be confusing if you are examining multiple symbol files and start interchanging your commands. – Warrington

I would also add objectdump -TC to the list. In contrary to readelf -Ws, it doesn't show the mangled names. – Wily

For those searching for what the numbers in parentheses at the end of each line mean, see this description. – Kremer

@BrooksMoses For .so files you may need to add --dynamic to nm command line. – Trigonous

Much like readelf, objdump needs the -W flag or it might truncate the symbol but unlike readelf, objdump can demangle the symbols without an external tool. – Simp

nm -g mylib.so gave nm: mylib.so: no symbols. For reference, unix.stackexchange.com/questions/282616/… – Baht

This generally doesn't work for .so files on Linux -- you need to ad -D or --dynamic – Ashia

Answer 2

If your .so file is in elf format, you can use readelf program to extract symbol information from the binary. This command will give you the symbol table:

readelf -Ws /usr/lib/libexample.so

You only should extract those that are defined in this .so file, not in the libraries referenced by it. Seventh column should contain a number in this case. You can extract it by using a simple regex:

readelf -Ws /usr/lib/libstdc++.so.6 | grep '^\([[:space:]]\+[^[:space:]]\+\)\{6\}[[:space:]]\+[[:digit:]]\+'

or, as proposed by Caspin,:

readelf -Ws /usr/lib/libstdc++.so.6 | awk '{print $8}';

Emissive

readelf -Ws /usr/lib/libstdc++.so.6 | awk '{print $8}'; regexes are awesome but sometimes a little awk goes a long way. – Mahratta

Answer 3

objdump -TC /usr/lib/libexample.so

Vanadinite

Answer 4

For shared libraries libNAME.so the -D switch was necessary to see symbols in my Linux

nm -D libNAME.so

and for static library as reported by others

nm -g libNAME.a

Valentinvalentina

Answer 5

I kept wondering why -fvisibility=hidden and #pragma GCC visibility did not seem to have any influence, as all the symbols were always visible with nm - until I found this post that pointed me to readelf and objdump, which made me realize that there seem to actually be two symbol tables:

• The one you can list with nm
• The one you can list with readelf and objdump

I think the former contains debugging symbols that can be stripped with strip or the -s switch that you can give to the linker or the install command. And even if nm does not list anything anymore, your exported symbols are still exported because they are in the ELF "dynamic symbol table", which is the latter.

Marinmarina

Thank you! This explains why sometimes "nm" doesn't show any symbols for .so files. – Garik

nm -D - lets you list the dynamic symbol table – Simaroubaceous

Answer 6

For C++ .so files, the ultimate nm command is nm --demangle --dynamic --defined-only --extern-only <my.so>

# nm --demangle --dynamic --defined-only --extern-only /usr/lib64/libqpid-proton-cpp.so | grep work | grep add
0000000000049500 T proton::work_queue::add(proton::internal::v03::work)
0000000000049580 T proton::work_queue::add(proton::void_function0&)
000000000002e7b0 W proton::work_queue::impl::add_void(proton::internal::v03::work)
000000000002b1f0 T proton::container::impl::add_work_queue()
000000000002dc50 T proton::container::impl::container_work_queue::add(proton::internal::v03::work)
000000000002db60 T proton::container::impl::connection_work_queue::add(proton::internal::v03::work)

source: https://stackoverflow.com/a/43257338

Trigonous

No way to see the symbol version though, isn't it? – Sacrilegious

@Treviño nm has --with-symbol-versions on my system. I tried it with glibc.so, but the output was the same with it or without it... more investigation needed. eidt: I forgot to use also --dynamic. With that, it works. I get e.g. iswupper without and iswupper@@GLIBC_2.2.5 with, in the output. – Trigonous

Answer 7

For Android .so files, the NDK toolchain comes with the required tools mentioned in the other answers: readelf, objdump and nm.

Otho

Answer 8

You can use the nm -g tool from the binutils toolchain. However, their source is not always readily available. and I'm not actually even sure that this information can always be retrieved. Perhaps objcopy reveals further information.

/EDIT: The tool's name is of course nm. The flag -g is used to show only exported symbols.

Obedient

Answer 9

Try adding -l to the nm flags in order to get the source of each symbol. If the library is compiled with debugging info (gcc -g) this should be the source file and line number. As Konrad said, the object file / static library is probably unknown at this point.

Sandry

Answer 10

nm -g list the extern variable, which is not necessary exported symbol. Any non-static file scope variable(in C) are all extern variable.

nm -D will list the symbol in the dynamic table, which you can find it's address by dlsym.

nm --version

GNU nm 2.17.50.0.6-12.el5 20061020

Daberath

Answer 11

If you just want to know if there are symbols present you can use

objdump -h /path/to/object

or to list the debug info

objdump -g /path/to/object

Obligate