ELF文件格式中的“section”和“segment”有什么区别？

Question

ELF文件格式中的“section”和“segment”有什么区别？

linuxdebiangnuelfabi

104

来自维基百科可执行和可链接文件格式（Executable and Linkable Format，简称ELF）：

段（Segment）包含运行时执行文件所必需的信息，而节（Section）包含重要的链接和重定位数据。整个文件中的任何字节最多只能被一个节所占有，也可能存在一些孤立的字节不属于任何节。

但是“节（Section）”和“段（Segment）”有什么区别呢？在可执行ELF文件中，一个段是否包含一个或多个节？

- tsing

1

段包含运行时执行所必需的信息，而节则用于链接和重定位。因此，真正的问题是“运行时需要什么，链接和重定位需要什么？”回答这个问题后，节和段之间的区别就会变得更加清晰。 - xealits

3个回答

59

该部分包含链接器用的静态数据，以及操作系统用的动态数据段

引言是正确的，但要实际理解它们之间的区别，应该尝试理解节头和程序头（段）条目的字段以及链接器（节）和操作系统（段）如何使用它们。

除了长度外，特别重要的信息包括：

节：告诉链接器一个节是要么：
- 原始数据将被加载到内存中，例如.data、.text等；
- 或者格式化的其他节的元数据，这些元数据将由链接器使用，但在运行时消失，例如.symtab、.srttab、.rela.text。
段：告诉操作系统：
- 段将被加载到虚拟内存的哪个位置；
- 段具有哪些权限（读、写、执行）。请记住，处理器可以有效地执行此操作：x86分页是如何工作的？

我编写了一篇涵盖更多细节的教程：http://www.cirosantilli.com/elf-hello-world/

一个段是否包含一个或多个节？

是的，而且是链接器将节放入段中。

在Binutils中，如何使用ld将节放入段中是由称为链接脚本的文本文件确定的。文档：https://sourceware.org/binutils/docs/ld/Scripts.html

您可以使用ld --verbose获取默认值，并使用-T设置自定义值。

例如，我的默认Ubuntu 17.04链接器脚本包含：

  .text           :                                                                                                                                                             
  {                                                                                                                                                                             
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)                                                                                                                         
    *(.text.exit .text.exit.*)                                                                                                                                                  
    *(.text.startup .text.startup.*)                                                                                                                                            
    *(.text.hot .text.hot.*)                                                                                                                                                    
    *(.text .stub .text.* .gnu.linkonce.t.*)                                                                                                                                                                                                                                                                                               
  }

这告诉链接器将名为.text.unlikely，.text.*_unlikely，.text.exit等的部分放置在.text段中。

操作系统开发是使用自定义脚本的情况，最小示例：https://github.com/cirosantilli/x86-bare-metal-examples/blob/d217b180be4220a0b4a453f31275d38e697a99e0/linker.ld

一旦可执行文件被链接，只有当链接器将可选的部分头存储在可执行文件中时，才能知道哪个部分进入了哪个段中：在ELF文件中，“部分到段映射”存储在哪里？

- Ciro Santilli OurBigBook.com

嗯，段的名称是如何确定的？理论上，段没有名称，而readelf显示它们时也没有名称。我猜ld在脚本中使用这些名称作为占位符/变量，对吧？ - newlog

@newlog 是的，我认为输出的 ELF 简单地没有存储段的名称。看到使用名称的链接器脚本示例会很有趣，但我没有这些示例。此外，我很好奇为什么ld知道 .text 具有执行权限而不具有写权限。 - Ciro Santilli OurBigBook.com

6

如果我理解有误，请纠正，因为我不认为自己是这个主题的专家，但根据我的研究，一些答案/评论中给出的陈述似乎不完全准确。具体而言，我将引用句子并对其进行评论：

“Section contains static for the linker, segment dynamic data for the OS”

根据this LWN文章，内核仅使用类型为PT_INTERP、PT_LOAD和PT_GNU_STACK的段头将可执行文件加载到内存中。但还有其他段类型，如PHDR、DYNAMIC、NOTE、GNU_EH_FRAME、GNU_PROPERTY、GNU_RELRO，它们被忽略了。

据我所知，GNU_RELRO段就像一个虚拟段；如果存在，则加载器将其用作标志，使重定位数据变为只读。但是，加载器不是操作系统的一部分，至少对于Linux来说是这样。

至于其他的段类型，我还没有弄清楚它们实际上是用来做什么的。它们对我来说似乎是多余的，因为有相应的节，基本上具有相同或更多的信息。

因此，从我的理解来看，那个答案只是一个更混乱的真相的简化近似。

段包含部分。

您可以拥有没有节头的ELF可执行文件no section header，而可重定位（*.o）文件通常没有段头。此外，在接受的答案中的readelf输出中，可以看到.interp部分在多个段中。我没有看到任何约束限制。

段包含运行时需要的信息，而节包含链接期间需要的信息。

同样，这似乎是一种简化。运行时加载器（或“解释器”）也需要用于加载共享库、解析符号、进行重定位等的节。

总之，虽然给出的答案可能是合理的一般近似值，但是当查看细节时，它显然变得更加复杂。

- zse

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Employed Russian · Accepted Answer

但是“section”和“segment”之间有什么区别呢？

就像你引用的一样：段包含运行时需要的信息，而节包含链接期间需要的信息。

一个段是否包含一个或多个节？

一个段可以包含0个或多个节。例如：

readelf -l /bin/date

Elf file type is EXEC (Executable file)
Entry point 0x402000
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000d5ac 0x000000000000d5ac  R E    200000
  LOAD           0x000000000000de10 0x000000000060de10 0x000000000060de10
                 0x0000000000000440 0x0000000000000610  RW     200000
  DYNAMIC        0x000000000000de38 0x000000000060de38 0x000000000060de38
                 0x00000000000001a0 0x00000000000001a0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000000c700 0x000000000040c700 0x000000000040c700
                 0x00000000000002a4 0x00000000000002a4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8
  GNU_RELRO      0x000000000000de10 0x000000000060de10 0x000000000060de10
                 0x00000000000001f0 0x00000000000001f0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .ctors .dtors .jcr .dynamic .got

这里，PHDR 段不包含任何节，INTERP 段包含 .interp 节，而第一个 LOAD 段包含了许多节。

更多阅读，其中有一张漂亮的插图：