Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

When you list the symbol table of a static library, like nm mylib.a, what does the 8 digit hex that show up next to each symbol mean? Is that the relative location of each symbol in the code?

Also, can multiple symbols have the same symbol value? Is there something wrong with a bunchof different symbols all having the symbol value of 00000000?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
553 views
Welcome To Ask or Share your Answers For Others

1 Answer

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...