S
sps
Hi All
In an attempt to learn more about ELF files (in particular how the GOT
and PLT work), I compiled a very simple C module as below
int num1 = 32;
extern int num2;
void print1()
{
printf("%d",num1);
printf("%d",num2);
}
void print2()
{
print1();
}
I then compiled it into a shared object (.so) file
gcc -c -fPIC print.c
gcc -shared -o libprint.so print.o
Using readelf and objdump, I examined the contents of the file.
readelf -a libprint.so
objdump -d libprint.so
I have mostly figured it out, but there are a couple of points that I
need clarified
a) Why are data objects and functions defined within the code module
indirectly accessed through the GOT. For example, the call to print1
is routed through the PLT. Why do this when you already know where
print1 is relative to the calling point? Is it just convenient to lump
everything in the GOT, or can these definitions be overriden?
b) There are two "mystery variables" which occur as the first and
second DWORD in the .data section. They have a RELATIVE relocation
applied to them. Because RELATIVE relocations do not relocate a
symbol, I don't know what these variables do? And in general, when do
use RELATIVE relocations. I understand that you are just adding the
load address to the location, but what code semantics create this
relocation?
c) Why are there two entries in the GOT for __cxa_finalize. They seem
to be identical, except that one is declared GLOB_DAT and the other
JMP_SLOT. The same occurs for __Jv_RegisterClasses.
d) What is the initial stack size of a process in Linux?
e) When the dynamic linker is called when a function is to be resolved
(lazy linkage), before it jumps to the DL, it pushes two values on the
stack: the first identifies the symbol to be resolved, and the second
identifies the calling module. How does this first value pushed map to
the symbol? It doesn't seem to be the symbol index in dynsym, and I
see no other relation to anything else?
f) Will a loader/dynamic linker only ever see GLOB_DAT, JMP_SLOT, COPY
and RELATIVE relocations? I assume the other relocation types only
apply to .o files. IS this correct? And if not, with what program
semantics would these other relocations appear?
Thanks for your answers.
In an attempt to learn more about ELF files (in particular how the GOT
and PLT work), I compiled a very simple C module as below
int num1 = 32;
extern int num2;
void print1()
{
printf("%d",num1);
printf("%d",num2);
}
void print2()
{
print1();
}
I then compiled it into a shared object (.so) file
gcc -c -fPIC print.c
gcc -shared -o libprint.so print.o
Using readelf and objdump, I examined the contents of the file.
readelf -a libprint.so
objdump -d libprint.so
I have mostly figured it out, but there are a couple of points that I
need clarified
a) Why are data objects and functions defined within the code module
indirectly accessed through the GOT. For example, the call to print1
is routed through the PLT. Why do this when you already know where
print1 is relative to the calling point? Is it just convenient to lump
everything in the GOT, or can these definitions be overriden?
b) There are two "mystery variables" which occur as the first and
second DWORD in the .data section. They have a RELATIVE relocation
applied to them. Because RELATIVE relocations do not relocate a
symbol, I don't know what these variables do? And in general, when do
use RELATIVE relocations. I understand that you are just adding the
load address to the location, but what code semantics create this
relocation?
c) Why are there two entries in the GOT for __cxa_finalize. They seem
to be identical, except that one is declared GLOB_DAT and the other
JMP_SLOT. The same occurs for __Jv_RegisterClasses.
d) What is the initial stack size of a process in Linux?
e) When the dynamic linker is called when a function is to be resolved
(lazy linkage), before it jumps to the DL, it pushes two values on the
stack: the first identifies the symbol to be resolved, and the second
identifies the calling module. How does this first value pushed map to
the symbol? It doesn't seem to be the symbol index in dynsym, and I
see no other relation to anything else?
f) Will a loader/dynamic linker only ever see GLOB_DAT, JMP_SLOT, COPY
and RELATIVE relocations? I assume the other relocation types only
apply to .o files. IS this correct? And if not, with what program
semantics would these other relocations appear?
Thanks for your answers.