共享库地址空间
在研究共享库时，我读了一条声明
尽管共享库的代码在多个进程之间共享，但其变量却不是。使用该库的每个进程都有其在库中定义的全局变量和静态变量的副本。
我对此几乎没有疑问。
- 每个进程的代码部分是否在单独的地址空间中？
- 共享库代码部分是否在某些全局（唯一）地址空间中。
我只是一个初学者，所以请帮助我理解。
谢谢！
问题答案：
通过将文件内存映射到进程的地址空间的某些部分，可以将共享库加载到进程中。当多个进程加载同一个库时，操作系统仅允许它们共享相同的物理RAM。
可以修改的库的某些部分（例如静态全局变量）通常以写时复制模式加载，因此，尝试写操作时会发生页面错误，内核通过将受影响的页面复制到另一个物理页面来做出响应。内存（仅适用于该进程），映射将重定向到新页面，然后最终完成写操作。
要回答您的具体观点：
- 所有进程都有自己的地址空间。进程之间的物理内存共享对于每个进程都是不可见的（除非它们通过共享内存API故意这样做）。
- 所有数据和代码都存在于物理RAM中，这是一种地址空间。但是，您可能看到的大多数地址都是属于一个或另一个进程的地址空间的虚拟内存地址，即使该“进程”是内核。
-
问题内容： 我的问题如下： 程序中何时指定共享对象的地址？在链接期间？载入中？如果我想在程序内部找到命令的内存地址，可以在中轻松找到它，但是如果我不想将程序带入调试器怎么办？ 此地址可以在运行之间更改吗？是否有其他静态分析工具可让您查看在运行时将库或函数加载到该程序的内存空间中的位置？ 编辑：我想在程序之外的信息（即使用实用程序来收集信息） 问题答案： 库由加载（动态连接器或运行时链接又名rtld
-
库用于将相似函数打包在一个单元中。然后这些单元就可为其他开发人员所共享，并因此有了模块化编程这种说法— 即，从模块中构建程序。Linux支持两种类型的库，每一种库都有各自的优缺点。静态库包含在编译时静态绑定到一个程序的函数。动态库则不同，它是在加载应用程序时被加载的，而且它与应用程序是在运行时绑定的。 使用共享库的方法有两种：您既可以在运行时动态链接库，也可以动态加载库并在程序控制之下使用它们。本
-
地址空间 分段机制涉及5个关键内容：逻辑地址（Logical Address,应用程序员看到的地址，在操作系统原理上称为虚拟地址，以后提到虚拟地址就是指逻辑地址）、物理地址（Physical Address, 实际的物理内存地址）、段描述符表（包含多个段描述符的“数组”）、段描述符（描述段的属性，及段描述符表这个“数组”中的“数组元素”）、段选择子（即段寄存器中的值，用于定位段描述符表中段描述符表
-
如果你想添加共享库支持到一个原来不包含共享库支持的 port 或是其它软件， 共享库的版本号应该遵循如下规则。通常来说，由此得出的数字与软件的发行版本无关。 建立共享库的三个原则是： 从1.0开始 如果改动与以前版本相兼容，增加副版本号（注意，ELF系统忽略副版本号）。 如果是个不兼容的改动，增加主版本号。 例如，添加函数和修正错误导致副版本号增加， 而删除函数、函数调用语法改变等，会迫使主版本号
-
4. 共享库 4.1. 编译、链接、运行 组成共享库的目标文件和一般的目标文件有所不同，在编译时要加-fPIC选项，例如： $ gcc -c -fPIC stack/stack.c stack/push.c stack/pop.c stack/is_empty.c -f后面跟一些编译选项，PIC是其中一种，表示生成位置无关代码（Position Independent Code）。那么用-fPIC
-
问题内容： 我正在从python脚本中调用一个so文件。据我了解，我真的不需要释放使用ctypes在python中打开的共享库。但是，在我的so文件代码中，它dlopen另一个so文件并且不执行dlclose（）。在这种情况下，从python端使用安全吗？我不必释放在ctypes内部加载的共享库soe文件吗？ 问题答案： 始终遵循 “自己清洁后清理 ”的规则（尽管现代技术会为您提供清洁方面的帮助）