In Understanding the Linux Kernel, 3rd edition, it says:
在了解Linux内核,第3版中,它说:
Shared libraries are especially convenient on systems that provide file memory mapping, because they reduce the amount of main memory requested for executing a program. When the dynamic linker must link a shared library to a process, it does not copy the object code, but performs only a memory mapping of the relevant portion of the library file into the process’s address space. This allows the page frames containing the machine code of the library to be shared among all processes that are using the same code. Clearly, sharing is not possible if the program has been linked statically. (page 817)
共享库在提供文件内存映射的系统上特别方便,因为它们减少了执行程序所需的主内存量。当动态链接器必须将共享库链接到进程时,它不会复制目标代码,而只会执行库文件相关部分到进程地址空间的内存映射。这允许包含库的机器代码的页面框架在使用相同代码的所有进程之间共享。显然,如果程序已静态链接,则无法共享。 (第817页)
I am interested in this, want to write a small program in C to verify, given two pids as input such as two gedit processes, and then get the address information from page frames to be shared. Does anyone know how to do it? From that book, I think the bss segment and text segment address from two or more gedit processes are same, is that correct?
我对此感兴趣,想要在C中编写一个小程序来验证,给出两个pid作为输入,例如两个gedit进程,然后从页面框架中获取要共享的地址信息。有谁知道怎么做?从那本书中,我认为来自两个或更多gedit进程的bss段和文本段地址是相同的,这是正确的吗?
2 个解决方案
#1
2
It is not the text and bss sections of your gedit (or whatever) that have the same address, but the content of the libc.so shared library - and all other shared libraries used by the two gedit processes.
你的gedit(或其他)的text和bss部分不是具有相同地址,而是libc.so共享库的内容 - 以及两个gedit进程使用的所有其他共享库。
This, as the quoted text says, allows the shared library to be ONE copy, and this is the main benefit of the shared library in general.
正如引用的文本所说,这允许共享库是一个副本,这通常是共享库的主要好处。
bss is generally not shared - since that is per process data. text sections of two processes running the same executable, in Linux, will share the same code.
bss通常不共享 - 因为这是每个流程数据。在Linux中,运行相同可执行文件的两个进程的文本部分将共享相同的代码。
Unfortunately, the proof of this would be to look at the physical mapping of pages (page at address X in process A is at physical address Y, and page for address X in process B is also at physical address Y) within the processes, and that's, as far as I know, not easily available without groking about inside the OS kernel.
不幸的是,证明这一点的目的是查看进程内页面的物理映射(进程A中的地址X的页面位于物理地址Y,进程B中的地址X的页面也是物理地址Y),以及据我所知,如果不在操作系统内核中进行操作,就不容易获得。
#2
0
Look at the contents of /proc/*/maps.
查看/ proc / * / maps的内容。
#1
2
It is not the text and bss sections of your gedit (or whatever) that have the same address, but the content of the libc.so shared library - and all other shared libraries used by the two gedit processes.
你的gedit(或其他)的text和bss部分不是具有相同地址,而是libc.so共享库的内容 - 以及两个gedit进程使用的所有其他共享库。
This, as the quoted text says, allows the shared library to be ONE copy, and this is the main benefit of the shared library in general.
正如引用的文本所说,这允许共享库是一个副本,这通常是共享库的主要好处。
bss is generally not shared - since that is per process data. text sections of two processes running the same executable, in Linux, will share the same code.
bss通常不共享 - 因为这是每个流程数据。在Linux中,运行相同可执行文件的两个进程的文本部分将共享相同的代码。
Unfortunately, the proof of this would be to look at the physical mapping of pages (page at address X in process A is at physical address Y, and page for address X in process B is also at physical address Y) within the processes, and that's, as far as I know, not easily available without groking about inside the OS kernel.
不幸的是,证明这一点的目的是查看进程内页面的物理映射(进程A中的地址X的页面位于物理地址Y,进程B中的地址X的页面也是物理地址Y),以及据我所知,如果不在操作系统内核中进行操作,就不容易获得。
#2
0
Look at the contents of /proc/*/maps.
查看/ proc / * / maps的内容。