how is ld-linux.so* itself linked and loaded? - linux-kernel

Question

Just by curiosity, how is the Linux dynamic linker/loader ld-linux.so* itself linked and loaded?
The above screenshot shows that file and ldd seems to give contradictory result: one says statically linked, the other says dynamically linked.
Then how is the loader itself be loaded?

Answer 1

ld-linux.so* doesn't depends any other libraries. It is runable by itself when loaded to memory.
ldd is a script, it loads the object file via the loader, and the loader checks whether the object is dynamically or statically linked, try this:
LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2
file reads the magic number or elf header to figure whether the object is dynamically or statically linked, it may output different value from ldd
IMO, ld-linux.so is static linked, because it doesn't have an .interp section which all dynamically linked object must have.

Answer 2

#Zang MingJie
Your answer helped me a lot, but the following words might confuse some people:
IMO, ld-linux.so is static linked, because it doesn't have an .interp >section which all dynamically linked object must have.
We should divide "all dynamic linked object" into two parts, one kind we called 'shared object' is generated like this:
gcc -c -o test.o test.c -fPIC
ld -o test.so test.o -shared
Another kind is called 'dynamic linked executable file' :
gcc -c -o test.o test.c -fPIC
ld -o test.so test.o
Two points are important:
1, Shared object has no '.iNTERP' segment, while Dynamic linked executable file has.
2, Linux kernel doesn't care whether an ELF file is EXEC or DYN indicated by the elf header. He searchs for the .INTERP segment firstly, if failed, He mmap() every LOAD type segment, and pass the control to eheader->e_entry, regardless he is loading a executable file or shared object.
Since ld-linux.so is a common shared object, it's not strange that she doesn't own an .INTERP segment. And it's not strange she can be run as executable . Every shared object can.
Write code like this:
void foobar(void){ while(1); }
compile it into a shared object ( using command line above ).
run it:
gdb ./test.so
You will get a process stuck in dead loop.
Use Ctrl-C to interrupt it. you will see ( need gcc's -g option )
Program received signal SIGINT, Interrupt.
foobar (void) at test.c:1
1 while(1);
(gdb)
You can go more far:
(gdb) p $eip
$1 = (void (*)()) 0x80000183 <foobar+3>
(gdb)
If you are familiar with linux kernel, you should know 0x80000000 is related the value of kernel variable 'mmap_min_addr'. Because test.so is a shared object, her load-address is zero, so kernel found a default virtual address for her, that's 0x80000000, not 0x804000.
I don't know how i got so off-topic ...