包装的open()和open64(),并看到系统调用通过VI使用open64() [英] Wrapper for open() and open64() and see that system calls by vi uses open64()

查看:500
本文介绍了包装的open()和open64(),并看到系统调用通过VI使用open64()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经写了两个包装的open() open64()。现在,我通过$ P $运行VI使用 LD_ preLOAD 环境变量ploading我的包装库,我看到 open64()包装是用来代替的open()。但是,当我与strace六我看到所做的系统调用是的open()(当然包括其他系统调用)。什么是这里的问题?

I have written wrappers for both open() and open64(). Now I run vi by preloading my wrapper library using LD_PRELOAD environment variable and I see that the open64() wrapper is used instead of the open(). But when I strace vi I see that the system calls made is to open() (of course including the other system calls). What is the issue here?

推荐答案

借助 strace的实用跟踪系统调用(系统调用)和打开的恰好是一个既系统调用和库函数。无论是的open() open64()库函数使用打开系统调用内部从内核请求服务。这是我的理解,使用的open() O_LARGEFILE 标志等同于使用 open64 ()来支持32位应用程序的大型文件。

The strace utility traces system calls (syscall) and open happens to be both a syscall and a library function. Both the open() and open64() library functions use the open syscall internally to request services from the kernel. It is my understanding that using open() with the O_LARGEFILE flag is equivalent to using open64() to support large files in 32-bit applications.

如果调用 open64()是在内部调用的open()功能,你的的open()包装就不叫,因为你不能干预内部库函数调用。它们运行之前得到解决。

If the call to open64() were to call the open() function internally, your open() wrapper would not be called because you cannot interpose internal library function calls. They are resolved before runtime.

这篇关于包装的open()和open64(),并看到系统调用通过VI使用open64()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆