我的库中的 glibc 提供了相同的覆盖 open() 并且我首先用我的库设置了 LD_PRELOAD，所以当进程调用 open() 时，打开是在我的库中定义的被调用。
问题：- glibc 中有几个其他函数调用 open() 一旦这样的例子是getpt()，当getpt() 调用open() 时，open() 被定义在 glibc 被调用时，我将如何让 getpt() 调用在我的 library() 中定义的 open()。
约束： - 我没有编译 glibc 的选项。
【问题讨论】：
标签： linux gcc overriding ld glibc
正如 tmcguire 所说，从posix_openpt 到__open 的调用是对internal 符号的调用，不能插入。
实际上，glibc 开发人员将此调用视为实现细节，您无权更改。
我正在查看编译时解决方案
你不能拥有它。
比运行时解决方案导致运行时解决方案会对性能产生影响。
运行时解决方案不需要对性能产生任何影响（除了调用open 而不是glibcs 的开销）。
我只知道库插入glibc 内部调用的一种方法：运行时修补。这个想法是
libc.so.6open的地址（这是__open的别名），glibc.text部分的边界CALL __open 指令mprotect 可写页面CALL my_open 并将其“修补”在原始指令的“顶部”mprotect返回页面读取并执行这很难看，但它适用于 i*86（32 位）Linux，CALL 可以“访问”4GB 地址空间内的任何其他指令。它不适用于 x86_64，其中 CALL 仍限制为 +/- 2GB，但从您的库到 glibc 的距离可能不止于此。
在这种情况下，您需要在libc.so.6 中找到合适的蹦床，您可以将原始CALL 重定向到该蹦床，并且您可以将注册间接JMP 放置到您的最终目的地。幸运的是，由于函数对齐，libc.so.6 通常有多个大小合适的未使用的NOP 区域。
【讨论】：
LD_PRELOAD 插入open 只是稍微不那么丑陋，可以说你也不应该在生产中这样做。
只需在我的库中定义 getpt() 函数，我就能在编译时解决它。
此解决方案不完整，因为 glibc [getpt() 除外] 中可能有其他函数可以调用 open，然后将调用 glibc 中的 open 调用。
我现在可以接受这个解决方案，但我需要在将来完全修复它。
【讨论】：
我认为你不能用 LD_PRELOAD 做到这一点。
如果你查看 libc 的反汇编（使用例如objdump --disassemble /lib64/libc.so.6 | grep -A20 "<getpt>:"，你可以看到getpt() 调用__open()，这是open() 的别名。
000000000011e9d0 <posix_openpt>:
11e9d0: 53 push %rbx
[...]
11e9ee: e8 dd d9 fb ff callq dc3d0 <__open>
但是，对 __open 的调用是不通过 PLT 的 PC 相关调用 - 这意味着您可以不使用 LD_PRELOAD 插入符号，因为 libc 中的所有调用都不会使用血小板。这可能是因为 libc 与 -BSymbolic 链接。
剩下的唯一选择是做 strace 所做的事情，并使用 ptrace 附加到进程。请参阅 this question 了解其工作原理。
【讨论】：