ELF文件格式中节和段的区别是什么

tsi*_*ing 60 linux debian gnu elf abi

来自wiki 可执行文件和可链接格式:

这些段包含运行时执行文件所必需的信息,而段包含用于链接和重定位的重要数据.整个文件中的任何字节最多只能由一个部分拥有,并且可能存在不属于任何部分的孤立字节.

但是段和段之间有什么区别?在可执行的ELF文件中,段是否包含一个或多个部分?

Emp*_*ian 55

但是段和段之间有什么区别?

正是您所引用的内容:段包含运行时所需的信息,而这些段包含链接期间所需的信息.

一个细分包含一个或多个部分?

一个段可以包含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 
Run Code Online (Sandbox Code Playgroud)

这里,PHDR段包含0个部分,INTERP段包含.interp部分,第一个LOAD段包含一大堆部分.

进一步阅读与一个很好的例证.

  • ""段包含运行时所需的信息"和""部分包含链接期间所需的信息"这一事实似乎是一个有争议的点,当人们认为部分包含在段中时.考虑到信息的类型并不紧密相关,所以对所描述它们的思考是有意义的,但是当你考虑到其中包含其他信息的事实时,它会变得更加混乱. (5认同)

Cir*_*四事件 27

Section包含链接器的静态,用于OS的段动态数据

引用是正确的,但要实际理解它的区别,您应该尝试理解节头和程序头(段)条目的字段,以及链接器(节)和操作系统(段)如何使用它们.

特别重要的信息是(除了长度):

  • 部分:告诉链接器一个部分是否:

    • 原始数据被加载到存储器,例如.data,.text
    • 或格式化的元数据有关的其它部分中,将由连接器被使用,但在运行时例如消失.symtab,.srttab,.rela.text
  • segment:告诉操作系统:

    • 应将段加载到虚拟内存中的哪个位置
    • 段具有哪些权限(读取,写入,执行).请记住,处理器可以有效地执行此操作: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.*)                                                                                                                                                                                                                                                                                               
  } 
Run Code Online (Sandbox Code Playgroud)

它告诉链接器将命名节.text.unlikely,.text.*_unlikely,.text.exit,等的.text部分.

OS开发就是自定义脚本是有用的,例如最小的情况下:https://github.com/cirosantilli/x86-bare-metal-examples/blob/d217b180be4220a0b4a453f31275d38e697a99e0/linker.ld

一旦链接了可执行文件,只有链接器在可执行文件中存储可选节标题,才能知道哪个节转到哪个节:ELF文件中存储的"节到段映射"在哪里?


zse*_*zse 7

如果我错了,请纠正我,因为我不认为自己是这个主题的专家,但根据我的研究,答案/评论中给出的一些陈述似乎并不完全准确。为了详细说明,我将引用句子并对其进行评论:

节包含链接器的静态数据、操作系统的段动态数据

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

Afaiu,GNU_RELRO 段就像一个虚拟段;如果存在,加载程序将其用作标志以使重定位数据只读。但加载程序不是操作系统的一部分,至少对于 Linux 来说是这样。

至于其他的段类型,我还没有查出它们的实际用途。它们对我来说似乎是多余的,因为相应的部分基本上具有相同或更多的信息。

因此,根据我的理解,这个答案只是一个更混乱的事实的简化近似。

部分包含段

您可以拥有没有节头的ELF 可执行文件,而可重定位 (*.o) 文件通常没有段头。此外,在接受答案的 readelf 输出中,可以看到多个段中的 .interp 部分。我没有看到任何收容限制。

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

这似乎又是一种简化。运行时加载器(或“解释器”)还需要用于加载共享库、解析符号、执行重定位等的部分。

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