Understanding strace output of an empty program c

int main(int argc, char *argv[]) { return 0; } 

Given the above C program, I get the following result with clang test.c ; strace ./a.out clang test.c ; strace ./a.out .

 execve("./a.out", ["./a.out"], [/* 36 vars */]) = 0 brk(0) = 0x1a06000 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) = 0x7f785c40f000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=78590, ...}) = 0 mmap(NULL, 78590, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f785c3fb000 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|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1840928, ...}) = 0 mmap(NULL, 3949248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f785be2a000 mprotect(0x7f785bfe5000, 2093056, PROT_NONE) = 0 mmap(0x7f785c1e4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7f785c1e4000 mmap(0x7f785c1ea000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f785c1ea000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f785c3fa000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f785c3f8000 arch_prctl(ARCH_SET_FS, 0x7f785c3f8740) = 0 mprotect(0x7f785c1e4000, 16384, PROT_READ) = 0 mprotect(0x600000, 4096, PROT_READ) = 0 mprotect(0x7f785c411000, 4096, PROT_READ) = 0 munmap(0x7f785c3fb000, 78590) = 0 exit_group(0) = ? +++ exited with 0 +++ 

Something puzzled me:

  • What does a line ending in 0x7f785c40f000 mean / do mean?
  • Why is 3949248 in mmap when libc.so is 1840928 big?
  • Where mprotect address used in mprotect ?
  • Where does mmap address come from if it's not NULL ?
  • What 4k and 8k memory are allocated by mmap right before arch_prctl ?
+5
source share
1 answer

Rather try and tell me why these exact addresses / sizes are used (and since no one answered), I thought you might like the way to find out where the values ​​came from. You can use gdb on the bootloader and stop at every system call or specific syscall. Assuming you have debuginfos installed, you can look at the code to see the values. Here is an example:

 $ gdb -q /lib64/ld-2.17.so Reading symbols from /lib64/ld-2.17.so...Reading symbols from /usr/lib/debug/lib64/ld-2.17.so.debug...done. done. (gdb) b _start Breakpoint 1 at 0x1430 (gdb) run ./a.out Starting program: /lib64/ld-2.17.so ./a.out Breakpoint 1, 0x0000555555555430 in _start () (gdb) p getpid() $1 = 18102 (gdb) !cat /proc/18102/maps 555555554000-555555575000 r-xp 00000000 ca:01 396014 /lib64/ld-2.17.so 555555775000-555555777000 rw-p 00021000 ca:01 396014 /lib64/ld-2.17.so 555555777000-555555778000 rw-p 00000000 00:00 0 [heap] 7ffff7ffb000-7ffff7ffd000 r--p 00000000 00:00 0 [vvar] 7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0 [vdso] 7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] (gdb) catch syscall mmap Catchpoint 2 (syscall 'mmap' [9]) (gdb) c Continuing. Catchpoint 2 (call to syscall mmap), 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) fin Run till exit from #0 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 Catchpoint 2 (returned from syscall mmap), 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) !cat /proc/18102/maps 00400000-00401000 r-xp 00000000 ca:01 13014 /home/ec2-user/so/e1/a.out 555555554000-555555575000 r-xp 00000000 ca:01 396014 /lib64/ld-2.17.so 555555775000-555555777000 rw-p 00021000 ca:01 396014 /lib64/ld-2.17.so 555555777000-555555778000 rw-p 00000000 00:00 0 [heap] 7ffff7ffb000-7ffff7ffd000 r--p 00000000 00:00 0 [vvar] 7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0 [vdso] 7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] (gdb) c Continuing. [...] Continuing. Catchpoint 2 (call to syscall mmap), 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) fin Run till exit from #0 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 Catchpoint 2 (returned from syscall mmap), 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) !cat /proc/18102/maps 00400000-00401000 r-xp 00000000 ca:01 13014 /home/ec2-user/so/e1/a.out 00600000-00601000 rw-p 00000000 ca:01 13014 /home/ec2-user/so/e1/a.out 555555554000-555555575000 r-xp 00000000 ca:01 396014 /lib64/ld-2.17.so 555555775000-555555777000 rw-p 00021000 ca:01 396014 /lib64/ld-2.17.so 555555777000-555555778000 rw-p 00000000 00:00 0 [heap] 7ffff7c32000-7ffff7ff4000 r-xp 00000000 ca:01 396021 /lib64/libc-2.17.so 7ffff7ff4000-7ffff7ffa000 r--p 00000000 ca:01 305615 /etc/ld.so.cache 7ffff7ffa000-7ffff7ffb000 rw-p 00000000 00:00 0 7ffff7ffb000-7ffff7ffd000 r--p 00000000 00:00 0 [vvar] 7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0 [vdso] 7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] (gdb) bt #0 0x000055555556c6aa in mmap64 () at ../sysdeps/unix/syscall-template.S:81 #1 0x000055555555a45f in _dl_map_object_from_fd ( name=name@entry =0x4002a1 "libc.so.6", fd=7, fbp=fbp@entry =0x7fffffffdb78, realname=0x7ffff7ffa640 "/lib64/libc.so.6", loader=loader@entry =0x555555777210, l_type=l_type@entry =1, mode=mode@entry =0, stack_endp=stack_endp@entry =0x7fffffffdb70, nsid=nsid@entry =0) at dl-load.c:1295 #2 0x000055555555c49b in _dl_map_object (loader=0x555555777210, name=0x4002a1 "libc.so.6", type=1, trace_mode=0, mode=<optimized out>, nsid=<optimized out>) at dl-load.c:2374 #3 0x0000555555560992 in openaux ( a=a@entry =0x7fffffffe128) at dl-deps.c:63 #4 0x00005555555631b4 in _dl_catch_error ( objname=objname@entry =0x7fffffffe120, errstring=errstring@entry =0x7fffffffe118, mallocedp=mallocedp@entry =0x7fffffffe110, operate=operate@entry =0x555555560960 <openaux>, args=args@entry =0x7fffffffe128) at dl-error.c:177 #5 0x0000555555561092 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>) at dl-deps.c:256 #6 0x00005555555572c5 in dl_main (phdr=<optimized out>, phdr@entry =0x555555554040, phnum=<optimized out>, phnum@entry =7, user_entry=user_entry@entry =0x7fffffffe2b8, auxv=<optimized out>) at rtld.c:1727 #7 0x000055555556a7d5 in _dl_sysdep_start (start_argptr=<optimized out>, dl_main=0x555555555a70 <dl_main>) at ../elf/dl-sysdep.c:244 #8 0x0000555555558cc1 in _dl_start_final (arg=0x7fffffffe370) at rtld.c:318 #9 _dl_start (arg=0x7fffffffe370) at rtld.c:544 #10 0x0000555555555438 in _start () 
0
source

Source: https://habr.com/ru/post/1242614/


All Articles