标签：libc gcc linker system-calls linux

我基本上需要自定义几个linux系统调用接口(例如sys_open).我非常了解GNU Linker ld –wrap = symbol选项,并使用该逻辑来更改open()libc包装器.尽管这达到了目的,但我真的很想知道libc源代码中的实际实现在哪里.

以下是我的主要怀疑对象(请注意,fcntrl.h仅包含声明)

> GLIBC_DIR / io / open.c
> GLIBC_DIR / ports / sysdeps / unix / sysv / linux / generic / open.c

样本驱动程序：

#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\n");
        exit(1);
    }

    return 0;
}

有关摘要：

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?

输入来自sysdeps / unix / syscall-template.S

How is the linker able to successfully hook the open() function when there is no function explicitly named open in libc source tree?

如果使用正确的-DSYSCALL_SYMBOL = …预处理上述源代码,则会发现源代码中提到了open.

标签：libc,gcc,linker,system-calls,linux
来源： https://codeday.me/bug/20191120/2040811.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。