ltrace -S一个最小示例的分析表明,该示例mmap已在glibc 2.23中使用
在glibc 2.23中,Ubuntu 16.04在运行latrace -S于以下程序的最小程序上运行dlopen:
ltrace -S ./dlopen.out
显示:
dlopen("libcirosantilli_ab.so", 1
SYS_open("./x86_64/libcirosantilli_ab.so", 524288, 06267650550) = -2
SYS_open("./libcirosantilli_ab.so", 524288, 06267650550) = 3
SYS_read(3, "\177ELF\002\001\001", 832) = 832
SYS_brk(0) = 0x244c000
SYS_brk(0x246d000) = 0x246d000
SYS_fstat(3, 0x7fff42f9ce30) = 0
SYS_getcwd("/home/ciro/bak/git/cpp-cheat"..., 128) = 54
SYS_mmap(0, 0x201028, 5, 2050) = 0x7f1c323fe000
SYS_mprotect(0x7f1c323ff000, 2093056, 0) = 0
SYS_mmap(0x7f1c325fe000, 8192, 3, 2066) = 0x7f1c325fe000
SYS_close(3) = 0
SYS_mprotect(0x7f1c325fe000, 4096, 1) = 0
因此我们立即看到dlopen调用open+ mmap。
很棒的ltrace工具可以跟踪库调用和系统调用,因此非常适合检查这种情况下的情况。
进一步分析表明,open该文件返回文件描述符3(stdin,out和err之后的下一个空闲描述符)。
勇敢的人也可以尝试glibc代码,但是mmap经过一番快速grep之后,我找不到了,我很懒。