在ELF文件格式规范的第2-7页和第2-8页中,有两幅图片给出了一个可执行程序头的示例,以及它们将如何加载到内存中:


该规范解释:
尽管该示例的文件偏移量和虚拟地址对于文本和数据都是一致的模块化4KB,但多达4个文件页包含不纯的文本或数据(取决于页面大小和文件系统块大小)。
我的问题是:
发布于 2015-06-24 03:51:49
页面是虚拟内存中最小的可映射单元。如果您不熟悉基本知识,请参见维基百科关于虚拟内存的文章。在普通系统中,页的大小为4096字节,或以十六进制表示的0x1000。
“文本页”包含可执行代码;“数据页”包含数据。这些必须映射到固定地址,以便代码中的偏移正确。在共享库或位置无关的可执行文件中,不再指定确切的虚拟地址,但它们的相对位置是。在本例中,第0文本页从0x8048000到0x8048fff,在文本段开始之前( 0x8048100)。第1页文本从0x8049000到0x8049fff。最后一个文本页从0x8073000到0x8073fff,这超出了文本段的末尾( 0x8073eff)。
第一个数据页位于0x8074000,但数据段直到0x8074f00才开始。此页与最后一个文本页由文件的同一部分支持,但必须单独映射,因为它具有不同的权限(PROT_EXEC|PROT_READ vs PROT_READ)。这就是“数据开头的副本”/“文本结尾的副本”的意思。
如果有两个以上的段,加载完全相同。“文本”和“数据”完全是任意的,重要的是为每个段指定的标志和地址。您可以使用readelf或objdump查看此信息。
请注意,在现实世界中,在文本和数据段之间通常有一个未映射的空间(“洞”),尽管不一定在只读数据和读写数据之间,或者在初始化的和未初始化的数据之间。
例如,运行cat /proc/self/maps会给我提供如下信息:
ben@joyplim ~ % cat /proc/self/maps
00400000-0040c000 r-xp 00000000 fe:01 36176026 /bin/cat
0060b000-0060c000 r--p 0000b000 fe:01 36176026 /bin/cat
0060c000-0060d000 rw-p 0000c000 fe:01 36176026 /bin/cat
<plus the heap, stack, library, and special kernel stuff>https://stackoverflow.com/questions/31017038
复制相似问题