两个不同的程序是否在相同的物理内存位置加载共享库函数答案

【问题标题】：Does two different programs load shared library function at same physical memory location两个不同的程序是否在相同的物理内存位置加载共享库函数
【发布时间】：2014-02-03 19:12:12
【问题描述】：

我正在使用 OpenSSL 共享库使用 AES_cbc_encrypt() 函数进行简单加密。我想知道如果我从两个不同的程序中使用这个 AES_cbc_encrypt() 函数，这两个程序会指向这个 AES_cbc_encrypt() 函数在物理内存中的相同位置吗？

我的其他问题是

1> 如果我使用共享库，它会被所有使用它的程序自动指向相同的物理内存位置吗？

或者

2 > 我是否需要遵循其他一些技术来强制程序将共享库加载到 RAM 中的同一物理内存中。（我不这么认为，那么就没有使用共享内存的概念。这是我的理解）。

3 > 如何检查两个程序是否在同一物理位置加载共享库函数。

4> 我使用 (& AES_cbc_encrypt) 计算两个程序中函数的位置（虚拟地址），然后使用工具capture，将此虚拟地址（VPN）转换为物理地址（PFN）。但是，我不知道如何从这个 VPN 计算物理地址，PFN 信息。所以无法进一步比较。有什么线索吗？

例如我的虚拟地址是

=0x400cb0

虚拟地址

起始地址-结束地址

 00400000-00402000

实体页面

 : A600000000036E26

 : A60000000008A4C3

在我的系统中

**虚拟地址空间：48位

物理地址空间：36 位**

我在 Linux 下使用 GCC。任何帮助或指针/链接将不胜感激。提前致谢。

【问题讨论】：

我不明白你为什么关心物理内存。把它的管理留给内核，它做得很好。
你为什么问？看来你误会了virtual memory。

标签： c linux operating-system shared-libraries shared-memory

【解决方案1】：

阅读 Drepper 的论文How To Write Shared Libraries。

共享库使用position independent code（以最小化relocation）。它们是由动态链接器ld-linux(8) 编辑的mmap(2)。 Linux processes 在virtual memory 中的address space 由linux kernel 到paging 管理。

内核通常会共享共享库的读取段（例如text segment）（因此它们的页面确实为不同的进程使用相同的 RAM）。

您可以使用/proc/self/maps（或/proc/1234/maps 用于pid 1234 的进程）来找出进程的内存映射。见proc(5)。

您不应该关心（并且应用程序不会直接看到）RAM 页面。只有内核通过MMU 管理物理RAM（它可以在RAM 中移动页面，将它们分页到磁盘等）。

另见mincore(2) 和mlock(2)。另请阅读OOM & thrashing & swap space。

阅读Advanced Linux Programming！

【讨论】：

@Basile，感谢您的回答。我正在尝试验证两个程序是否都指向 RAM 中的相同物理位置，但无法执行 .那个方向的任何线索。我从其他地方读到（理论上）这两个程序都指向同一个位置。我想以编程方式检查。
你不应该在意。 RAM 由内核管理，应用程序代码看不到它。应用程序只能看到虚拟内存。
@bholanath：一般来说你找不到那个映射。物理映射可能瞬息万变。
你这个问题没有任何意义。内核可以随意调出 RAM 页面（但它通常不会这样做，除非在压力下）。当你查询内核时，信息可能已经过时了......所以它对应用程序代码没有意义。
我认为clflush 只能在内部内核中使用。我是从应用程序的角度说的。如果您不是非常熟悉 Linux 应用程序代码，请不要在内核中编写代码。

【解决方案2】：

当我使用选项 -fPIC 进行编译时，我从两个程序中获得了相同的虚拟地址（可能是巧合）以及相同的整个库的物理地址。

gcc -fPIC -o aes openssl_aes.c -lcrypto

这证明共享库被加载到相同的物理位置。

【讨论】：