【问题标题】:understanding output of strace of empty c program理解空 c 程序的 strace 的输出
【发布时间】:2016-02-09 12:19:29
【问题描述】:
int main(int argc, char *argv[])
{
    return 0;
}

鉴于上述 C 程序,我使用 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 +++

有件事让我很困惑:

  • 以0x7f785c40f000 结尾的行是什么意思?
  • 当libc.so 是1840928 很大时,为什么3949248 在mmap 中?
  • mprotect 中使用的地址来自哪里?
  • mmap 中使用的地址不是NULL 时从何而来?
  • mmap在arch_prctl之前分配的4k和8k内存是什么?

【问题讨论】:

  • 好问题。以上应该几乎都是动态加载器的工作,它有一个相当复杂的规范。将它与 -static 构建进行比较会很有趣,其中大部分内容不会发生,但其他会发生(例如 uname 调用和一些 brk 调用但没有 mmaps)。跨度>
  • @PSkocik 是的,结果就是这样:paste.ubuntu.com/15001856

标签: linux strace


【解决方案1】:

而是试图告诉您为什么使用这些确切的地址/大小(并且由于没有其他人回答),我认为您可能喜欢一种检查值来自何处的方法。您可以在加载程序上使用 gdb 并在每个系统调用或特定系统调用处停止。假设您已安装 debuginfos,您可以查看代码以查看值。这是一个例子:

$ 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 ()

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2023-03-18
    • 1970-01-01
    • 1970-01-01
    • 2011-09-14
    • 1970-01-01
    • 1970-01-01
    • 2013-12-07
    相关资源
    最近更新 更多