页表条目变脏的方式

Question

访问和脏 (A/D) 位通知页面是否被访问或写入。当文件加载到内存中时，一些更改仅在内存中，这些更改仍未与存储在磁盘上的文件同步。被修改但没有回写的页面是脏页。

我的问题是这个概念是否也暗示 ELF 文件？ .code、.data 也会变脏吗？如果是，那怎么办？

Answer 1

我的问题是这个概念是否也适用于 ELF 文件？

是的。

.code、.data 也会变脏吗？如果是，那怎么办？

.code通常没有写权限（只有读和执行），所以它通常不会变脏。

但是，您可以将mprotect.code 页面设为可写，然后对其进行写入（这通常用于运行时修补）。如果这样做，相应的页面将变脏，并且将保持脏，因为它与MAP_PRIVATE 映射（您通常不希望正在运行的程序更改其磁盘上的图像）。

如果您的二进制文件有文本重定位，您也可能会弄脏.code 页面（当非fPIC 代码链接到ix86 上的共享库时通常会发生这种情况）。

最后，.data 页面一直被修改（每次你修改一个初始化的全局变量），然后这些页面在程序运行期间保持脏（同样，你通常不希望正在运行的程序修改其磁盘映像）。

更新：

不带 fpic 的 text/.code 重定位是在加载时为共享库进行的重定位。那么这意味着这些重定位甚至在执行入口指令之前就使 .code 变脏了。

不一定。需要考虑的两种情况：

1. a.out 直接依赖于foo.so
2. a.out 使用 dlopen 加载 foo.so

在情况 1 中，您是正确的：foo.so 中的文本重定位将导致（部分）.text 页面在执行 a.out 的第一条指令之前变脏（请注意，用户空间从ld.so 条目，而不是来自 a.out 条目）。

在情况 2 中，.text 页面将作为 dlopen 的一部分变脏，这在 main 之后很长时间（它本身在入口指令之后很长时间）。

当 .data 页面被修改时，作为响应，.code 页面是否也应该为 fpic 或非 fpic 变脏？

否：修改.data 不会导致.code 也变脏。为什么会这样？