ARM架构下LD_PRELOAD对系统调用生效原因及静态二进制兼容性问询

我来一步步帮你拆解这些关于LD_PRELOAD的疑问，都是动态链接机制里非常关键的知识点，结合ARM架构的场景给你讲清楚：

你之前的认知有个小误区：动态编译的程序并不会直接调用内核执行系统调用。实际上，像write、read这类系统调用，在libc中都有对应的封装函数——比如libc里的write()函数，它会负责组装系统调用的参数，然后通过ARM架构的svc（以前是swi）指令触发内核态的系统调用流程。

而LD_PRELOAD的核心就是改变动态链接器的符号查找优先级：当进程发起函数调用时，动态链接器会先在你预加载的自定义共享库中查找符号。所以只要你在mylib.so里实现了自己的write()函数，进程调用write时就会优先执行你的版本，而非libc中的封装函数。你完全可以在这个自定义write里做日志记录、参数修改，之后再通过dlsym(RTLD_NEXT, "write")获取真正的libc write函数指针，调用它完成原本的系统调用流程。

答案是完全不适用。原因很简单：静态编译的二进制文件在编译阶段就把所有依赖的函数（包括libc中的所有封装函数、标准库函数）直接打包进了可执行文件本身，它不需要动态链接器（ld.so）来加载外部共享库。

而LD_PRELOAD是动态链接器ld.so提供的特性，只有当程序启动时依赖ld.so进行动态符号解析和共享库加载时，这个环境变量才会生效。静态程序根本不会和ld.so交互，自然不会理会LD_PRELOAD的设置。

结合ARM架构的动态链接流程，核心步骤是这样的：

• 当动态编译的程序启动时，操作系统会先启动动态链接器ld.so，它会读取LD_PRELOAD环境变量，将指定的自定义共享库优先加载到进程的地址空间中。
• 当进程调用某个函数（比如write）时，动态链接器会按照预加载库 → 程序自身的共享库依赖 → 系统标准库的顺序查找符号。
• 如果你在预加载的库里实现了同名的write函数，动态链接器就会将该函数的地址绑定到进程的调用点上。
• 你的自定义write函数可以自由处理逻辑，比如打印调用参数、修改传入的数据，之后再通过dlsym(RTLD_NEXT, "write")获取libc中真正的write函数地址，调用它来完成原本的系统调用触发流程。

这样就实现了对系统调用封装函数的Hook，而不是直接Hook内核的系统调用入口——这也是LD_PRELOAD能生效的核心原因。

内容的提问来源于stack exchange，提问作者yfr24493AzzrggAcom