请求解析arm-none-eabi-gcc默认链接脚本中多节VMA为0的原因

问题背景 #

arm-none-eabi-gcc的默认链接脚本定义了多个VMA（虚拟内存地址）为0的节，多数包含调试信息：

/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  .gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1.  */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions.  */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2.  */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2.  */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line .debug_line.* .debug_line_end) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }

  //snip several more of these, until...

  .ARM.attributes 0 : { KEEP (*(.ARM.attributes)) KEEP (*(.gnu.attributes)) }
  .note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }

我无法理解该设置的作用，DWARF节的注释也没有帮助——这些节不可能真的拥有相同起始地址，除非它们的大小都为0！此外，脚本是为节而非符号分配地址0，且该注释并不适用于Stabs节。

使用readelf -S查看发现，这些节理论上地址均为0，但偏移量各不相同——推测这些偏移量是它们加载后的实际地址：

[13] .stab             PROGBITS        00000000 009a6c 00009c 0c     14   0  4
  [14] .stabstr          STRTAB          00000000 009b08 00014d 00      0   0  1
 
   ...

  [16] .debug_aranges    PROGBITS        00000000 009cb0 0005f0 00      0   0  8
  [17] .debug_info       PROGBITS        00000000 00a2a0 0110c9 00      0   0  1
  [18] .debug_abbrev     PROGBITS        00000000 01b369 00401d 00      0   0  1
  [19] .debug_line       PROGBITS        00000000 01f386 0063ed 00      0   0  1
  [20] .debug_frame      PROGBITS        00000000 025774 00097c 00      0   0  4
  [21] .debug_str        PROGBITS        00000000 0260f0 001f29 01  MS  0   0  1
  [22] .debug_line_str   PROGBITS        00000000 028019 0000b3 01  MS  0   0  1
  [23] .debug_loclists   PROGBITS        00000000 0280cc 00221c 00      0   0  1
  [24] .debug_rnglists   PROGBITS        00000000 02a2e8 000495 00      0   0  1
  [25] .ARM.attributes   ARM_ATTRIBUTES  00000000 02a77d 00002e 00      0   0  1

我猜测虚拟地址0可能是特殊标识，并非字面意思，代表这类节不会被加载到内存（因此没有加载地址），除非在调试环境下运行，但目前没有找到相关证据支撑该猜测。恳请解释该重复地址现象的实际原理。

原理解释 #

核心：VMA=0是「非加载节」的约定标记 #

这些调试相关的节完全不需要被加载到目标硬件的内存中运行——它们只用于给调试器（如GDB）提供符号映射、源码位置、编译属性等调试辅助信息，因此链接器不需要为它们分配真实的物理/虚拟内存地址。

• 为什么用0？ 这是链接器领域的通用约定：给不需要加载的节分配一个无效且不会和可执行代码、数据节冲突的地址值，0是最直观的选择。
• 偏移量的真实含义：readelf里显示的偏移量是这些节在ELF文件中的存储位置，和内存地址无关。调试器读取ELF文件时，会直接根据这个偏移量定位到节的内容，根本不关心VMA值。
• DWARF节注释的实际意义：注释里提到的「符号相对于节起始位置」是关键——DWARF格式的符号都是以节内偏移来存储的，而非绝对内存地址，所以不管VMA设成什么，都不影响调试器解析，设为0只是遵循非加载节的约定。
• Stabs节同理：Stabs也是纯调试格式，同样不需要加载到内存，所以也用VMA=0标记。

验证方式 #

你可以用arm-none-eabi-objcopy --strip-debug input.elf output.elf命令把这些调试节从ELF文件中剥离，剥离后的文件可以正常在目标硬件上运行，这直接证明了这些节不参与程序的实际执行流程。

内容的提问来源于stack exchange，提问作者AJM