What does "symbol value" from nm command mean?
nm shows the values of symbols. Some symbols in a library or object file may show up as zero simply because they haven't been given a value yet. They'll get their actual value at link time.
Some symbols are code symbols, some are data, etc. Before linking the symbol value is often the offset in the section it resides in,
The hex numeral is the memory offset into the object files where the symbol can be found. It's literally the number of bytes into the object code.
That value is used by the linker to locate and make a copy of the symbol's value. You can see generally how it's laid out if you add the -S
option to nm
, which will show you the size of the value for each symbol.
Here's a snippet of code I wrote in C:
#include
#include
void foo();
int main(int argc, char* argv[]) {
foo();
}
void foo() {
printf("Foo bar baz!");
}
I ran gcc -c foo.c
on that code. Here is what nm foo.o
showed:
000000000000001b T foo 0000000000000000 T main U printf
For this example I am running Ubuntu Linux 64-bit; that is why the 8 digit hex you see is 16 digit here. :-)
The hex digit you see is the address of the code in question within the object file relative to the beginning of the .text.
section. (assuming we address sections of the object file beginning at 0x0). If you run objdump -td foo.o
, you'll see the following in the output:
Disassembly of section .text: 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 83 ec 10 sub $0x10,%rsp 8: 89 7d fc mov %edi,-0x4(%rbp) b: 48 89 75 f0 mov %rsi,-0x10(%rbp) f: b8 00 00 00 00 mov $0x0,%eax 14: e8 00 00 00 00 callq 19 19: c9 leaveq 1a: c3 retq 000000000000001b : 1b: 55 push %rbp 1c: 48 89 e5 mov %rsp,%rbp 1f: b8 00 00 00 00 mov $0x0,%eax 24: 48 89 c7 mov %rax,%rdi 27: b8 00 00 00 00 mov $0x0,%eax 2c: e8 00 00 00 00 callq 31 31: c9 leaveq 32: c3 retq
Notice that these two symbols line right up with the entries we saw in the symbol table from nm
. Bare in mind, these addresses may change if you link this object file to other object files. Also, bare in mind that callq
at 0x2c will change when you link this file to whatever libc your system provides, since that is currently an incomplete call to printf (it doesn't know where it is right now).
As for your mylib.a
, there is more going on here. The file you have is an archive; it contains multiple object files, each one of which with it's own text segment. As an example, here is part of an nm against /usr/lib/libm.a on my box here
e_sinh.o: 0000000000000000 r .LC0 0000000000000008 r .LC1 0000000000000010 r .LC2 0000000000000018 r .LC3 0000000000000000 r .LC4 U __expm1 U __ieee754_exp 0000000000000000 T __ieee754_sinh e_sqrt.o: 0000000000000000 T __ieee754_sqrt e_gamma_r.o: 0000000000000000 r .LC0 U __ieee754_exp 0000000000000000 T __ieee754_gamma_r U __ieee754_lgamma_r U __rint
You'll see that multiple text segment entries -- indicated by the T in the second column rest at address 0x0, but each individual file has only one text segment symbol at 0x0.
As for individual files having multiple symbols resting at the same address, it seems like it would be possible perhaps. After all, it is just an entry in a table used to determine the location and size of a chunk of data. But I don't know for certain. I have never seen multiple symbols referencing the same part of a section before. Anyone with more knowledge on this than me can chime in. :-)
Hope this helps some.