问题
My preliminary knowledge is that:
.dynamic
contains libraries that the executable needs to load.dynsym
contains external symbols such assetsockopt@GLIBC_2.0
.dynstr
contains strings of function requirements
Overall, I am a bit confused as to how these sections work together to create a binary - specifically .dynsym
and .dynstr
. So my question is two-fold. Are my statements above correct? If so, how do these three sections work together to create a binary?
回答1:
Are my statements above correct?
The .dynsym
section contains a set of fixed-length records of type Elf32_Sym
or Elf64_Sym
.
Since these are fixed length entries, they can not by themselves describe arbitrary length symbols (strings) that the binary exports or imports.
Therefore these entries don't contain the strings. Instead, they contain an offset into .dynstr
(in the .st_name
field), and the symbol name is found at this offset.
So it's not true that ".dynsym
contains setsockopt@GLIBC_2.0" and that ".dynstr
contains strings of function requirements" (whatever that last statement means).
The .dynsym
contains an Elf32_Sym
or an Elf64_sym
describing an imported symbol setsockopt
, and referencing the offset of "setsockopt"
string in the .dynstr
section.
Likewise, ".dynamic
contains libraries that the executable needs to load" is false -- the section doesn't contain any libraries.
It contains fixed length entries of Elf64_Dyn
or Elf32_Dyn
, some of which (such as ones with .d_tag == DT_NEEDED
or DT_RPATH
) may reference strings from .dynstr
via their offsets. The dynamic loader interprets these entries in certain way -- for DT_NEEDED
as "must load this other library", for DT_RPATH
as "must search these colon-separated paths", etc.
来源:https://stackoverflow.com/questions/53156275/difference-between-dynamic-dynsym-and-dynstr-in-an-elf-executable