From where in libc source code, is open() getting linked?
我基本上需要自定义几个linux系统调用接口(例如sys_open)。我非常了解GNU Linker ld --wrap = symbol选项,并使用该逻辑来更改open()libcpackage器。尽管这达到了目的,但我真的很想知道libc源代码中的实际实现在哪里发挥作用。
以下两个地方是我的主要犯罪嫌疑人(请注意,fcntrl.h仅包含声明)
- GLIBC_DIR / io / open.c
- GLIBC_DIR / ports / sysdeps / unix / sysv / linux / generic / open.c
示例驱动程序:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | #include <stdio.h> #include <stdlib.h> #include <fcntl.h> int main(int argc, char *argv[]) { int fd; if ((fd = open("sample.c", O_RDONLY)) == -1) { fprintf(stderr,"file not found\ "); exit(1); } return 0; } |
相关代码段:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | main: 401dd1: bf 44 90 48 00 mov $0x489044,%edi 401dd6: b8 00 00 00 00 mov $0x0,%eax 401ddb: e8 10 03 03 00 callq 4320f0 <__libc_open> ...... ...... __libc_open: 4320f0: 83 3d 69 8e 28 00 00 cmpl $0x0,0x288e69(%rip) 4320f7: 75 14 jne 43210d <__open_nocancel+0x14> __open_nocancel: 4320f9: b8 02 00 00 00 mov $0x2,%eax 4320fe: 0f 05 syscall |
为简单起见,我准备了所有可静态执行的libc源。还足够小心,以使GCC正确选择自定义libc.a。我尝试添加一个puts语句,但是提到的两个源代码根本没有被调用。看一下可执行文件的汇编[如上所示],已将sys_open调用(__open_nocancel中的0x2)放置在可执行文件中。
所以我的问题如下:
- libc中与open()相关的代码逻辑从何而来?
- libc源代码树中没有显式命名为open的函数时,链接程序如何成功钩住open()函数?
From where exactly in libc, the open()-related code logic magically come?
输入来自
How is the linker able to successfully hook the open() function when there is no function explicitly named open in libc source tree?
如果使用正确的