Come fa execve chiamare dinamica linker/loader (LD-linux.so.2)

Question

ho usato gcc per compilare e collegare il più fondamentale del programma C, test.c:

int 
main() { 
} 

Come previsto, l'uscita è un eseguibile collegato dinamicamente:

$ file test 
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses  shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x0f806c099f74132a158d98aebde4639ae0998971, not stripped 

strace esecuzione dà il seguente risultato:

$ strace -f ./test 
execve("./test", ["./test"], [/* 31 vars */]) = 0 
brk(0)         = 0x248d000 
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory) 
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f77eeb27000 
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory) 
open("/etc/ld.so.cache", O_RDONLY)  = 3 
fstat(3, {st_mode=S_IFREG|0644, st_size=109292, ...}) = 0 
mmap(NULL, 109292, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f77eeb0c000 
close(3)        = 0 
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory) 
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\357\1\0\0\0\0\0"..., 832) = 832 
fstat(3, {st_mode=S_IFREG|0755, st_size=1595408, ...}) = 0 
mmap(NULL, 3709016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f77ee580000 
mprotect(0x7f77ee700000, 2097152, PROT_NONE) = 0 
mmap(0x7f77ee900000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x180000) = 0x7f77ee900000 
mmap(0x7f77ee905000, 18520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f77ee905000 
close(3)        = 0 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f77eeb0b000 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f77eeb0a000 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f77eeb09000 
arch_prctl(ARCH_SET_FS, 0x7f77eeb0a700) = 0 
mprotect(0x7f77ee900000, 16384, PROT_READ) = 0 
mprotect(0x7f77eeb29000, 4096, PROT_READ) = 0 
munmap(0x7f77eeb0c000, 109292)   = 0 
exit_group(-292524312)     = ? 

mi aspettavo di vedere s "/lib64/ld-linux.so.2" omewhere nell'output strace in quanto secondo il manuale execve:

Se l'eseguibile è un eseguibile ELF collegato dinamicamente, l'interprete chiamato in> segmento PT_INTERP viene utilizzato per caricare le librerie condivise necessarie. Questo interprete> è in genere /lib/ld-linux.so.2 per binari linkati con glibc 2

La mia ipotesi è che il/loader (/lib64/ld-linux.so.2) chiamata linker è parte di execve. Qualcuno può confermare?

Answer 1

La mia ipotesi è che la chiamata linker/loader (/lib64/ld-linux.so.2) sia parte di execve.

Questo è un po 'corretto.

Il kernel esamina prima i segmenti eseguibili principali e mmap li nella nuova "shell di processo".

Quando si scopre che l'eseguibile ha PT_INTERP segmento, mmap s che i segmenti del file pure, e passa il controllo al esso.

Così, in "ritorno" da execve() in modalità utente, l'interprete (in genere /lib64/ld-linux-x86-64.so.2 su Linux/x86_64) è già mappato e in esecuzione. È quindi compito di quell'interprete trasferirsi, a mmap il resto delle librerie condivise richieste, inizializzarle e infine trasferire il controllo all'eseguibile principale.

Se si desidera ulteriori dettagli, avviare here.