【问题标题】:Confusion about virtual address space and position indepedent code (PIC)对虚拟地址空间和位置无关代码 (PIC) 的困惑
【发布时间】:2020-10-13 06:50:19
【问题描述】:

在阅读this blogpost 时,当作者试图证明共享库需要 PIC 时,我遇到了以下情况。

如果您的共享库被构建为仅在加载到一个特定地址时才能工作,那么一切可能都很好 - 直到出现另一个使用该地址构建的库。

如果库的起始地址决定了库进入内存的位置,那么虚拟内存管理在这里做什么?我的意思是内存映射应该能够确定该物理地址空间中已经存在某些内容,因此我们可以将下一个共享库放置在其他地方。

而且库指定的加载地址是虚拟地址空间对吗?那么,如果两个库具有相同的虚拟地址空间加载地址,为什么还会产生问题。

所以我基本上有这个问题:

  1. 当使用非 PIC 时,两个库在同一个地址中的问题目前对我来说意义不大。这是否与第一个库与第二个库的地址重叠有关?但同样,操作系统内存管理应该能够将东西放入物理内存空闲的空间,那么冲突在哪里呢?

【问题讨论】:

  • 问题与物理地址无关。它只依赖一件事:在虚拟地址空间中,两个库不能驻留在同一个地址。

标签: c gcc memory-management linker code-generation


【解决方案1】:

问题与物理地址无关。它只依赖一件事:在虚拟地址空间中,两个库不能驻留在同一个地址。

虚拟内存将每个分配的虚拟页面映射到一个物理页面(或框架)。 假设对于进程 P1,VA 0x10000 映射到 PA 0xff000。不过,多亏了虚拟内存,一个单独的进程 P2 也可以在同一地址拥有不同的页面。因此,P2 可以将 VA 0x10000 映射到 PA 0xee000。没有冲突,因为它们是两个独立的虚拟地址空间。

但是,帖子中所述的问题适用于单个进程及其地址空间。因此,对于进程 P1,VA 0x10000 不能同时映射到 PA 0xff000 0xee000。假设您有两个非 PIC 库(libX 和 libY),它们被编译为仅在 VA 0x10000 处工作。如果 P1 想要加载这两个库,它就会遇到问题,因为它必须将它们都加载到相同的虚拟地址空间中,并且它们都想使用相同的 VA。 VA 0x10000 只能映射到其中一个库的物理页面。

对于 PIC 库,这不是问题,因为 P1 可以将 libX 放置在 VA 0x10000 并将 libY 放置在 VA 0x20000。然后虚拟内存映射可以将两个库的 VA 映射到它们各自的 PA。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-03-18
    • 1970-01-01
    • 1970-01-01
    • 2011-08-19
    • 2016-01-13
    • 1970-01-01
    相关资源
    最近更新 更多