How does execve call dynamic linker/loader (ld-lin

2019-01-19 04:43发布

I used gcc to compile and link the most basic C program, test.c:

int
main() {
}

As expected, the output is a dynamically linked executable:

$ 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

Running strace gives the following output:

$ 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)                  = ?

I was expecting to see "/lib64/ld-linux.so.2" somewhere in the strace output since according to the execve manual:

If the executable is a dynamically linked ELF executable, the interpreter named in >the PT_INTERP segment is used to load the needed shared libraries. This interpreter >is typically /lib/ld-linux.so.2 for binaries linked with glibc 2

My guess is that the linker/loader (/lib64/ld-linux.so.2) call is part of execve. Can someone confirm?

1条回答
Fickle 薄情
2楼-- · 2019-01-19 05:11

My guess is that the linker/loader (/lib64/ld-linux.so.2) call is part of execve.

This is somewhat correct.

The kernel first looks at the main executable segments, and mmaps them into the new "process shell".

When it discovers that the executable has PT_INTERP segment, it mmaps that file's segments as well, and passes control to it.

Thus, upon "return" from execve() into user-mode, the interpreter (usually /lib64/ld-linux-x86-64.so.2 on Linux/x86_64) is already mapped in and running. It is then the job of that interpreter to relocate itself, to mmap the rest of required shared libraries, initialize them, and finally transfer control to the main executable.

If you want more details, start here.

查看更多
登录 后发表回答