objcopy如何计算elf文件要插入到输出文件中的节？

假设我运行

arm none-eabi objcopy firmwared.elf-O ihex firmware.hex

假设二进制文件是使用以下链接器脚本生成的：

ENTRY(Reset_Handler)

MEMORY
{
  FLASH (RX) : ORIGIN = 0x08020000, LENGTH = 896K
  SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 512K
  BKPSRAM (RW) : ORIGIN = 0x40024000, LENGTH = 4K
}

_estack = 0x20080000;

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    _isr_vector = .;
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } > FLASH

  .firmware_header_vector :
  {
    . = ALIGN(4);
    KEEP(*(.firmware_header_vector))
    . = ALIGN(4);
  } > FLASH

  .text :
  {
    . = ALIGN(4);
    _stext = .;
    *(.Reset_Handler)
    *(.text)
    *(.text*)
    *(.rodata)
    *(.rodata*)
    *(.glue_7)
    *(.glue_7t)
    KEEP(*(.init))
    KEEP(*(.fini))
    . = ALIGN(4);
    _etext = .;

  } > FLASH

  .ARM.extab :
  {
    . = ALIGN(4);
    *(.ARM.extab)
    *(.gnu.linkonce.armextab.*)
    . = ALIGN(4);
  } > FLASH

  .exidx :
  {
    . = ALIGN(4);
    PROVIDE(__exidx_start = .);
    *(.ARM.exidx*)
    . = ALIGN(4);
    PROVIDE(__exidx_end = .);
  } > FLASH

  .preinit_array :
  {
    PROVIDE(__preinit_array_start = .);
    KEEP(*(.preinit_array*))
    PROVIDE(__preinit_array_end = .);
  } > FLASH

  .init_array :
  {
    PROVIDE(__init_array_start = .);
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array*))
    PROVIDE(__init_array_end = .);
  } > FLASH

  .fini_array :
  {
    PROVIDE(__fini_array_start = .);
    KEEP(*(.fini_array*))
    KEEP(*(SORT(.fini_array.*)))
    PROVIDE(__fini_array_end = .);
  } > FLASH

  _sidata = .;
  .data_x : AT(_sidata) /* LMA address is _sidata (in FLASH) */
  {
    . = ALIGN(4);
    _sdata = .; /* data section VMA address */
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  } > SRAM

  .firmware_header (_sidata + SIZEOF(.data_x)):
  {
    . = ALIGN(4);
    KEEP(*(.firmware_header))
    . = ALIGN(4);
  } > FLASH

  .eth (NOLOAD) :
  {
    . = ALIGN(4);
    KEEP(*(.RxDecripSection))
    KEEP(*(.TxDescripSection))
    KEEP(*(.RxarraySection))
    KEEP(*(.TxarraySection))
    . = ALIGN(4);
  } > SRAM

  .bss :
  {
    . = ALIGN(4);
    _sbss = .;

    PROVIDE(__bss_start__ = _sbss);
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;

    PROVIDE(__bss_end__ = _ebss);
  } > SRAM

  PROVIDE(end = .);

  .heap (NOLOAD) :
  {
    . = ALIGN(4);
    PROVIDE(__heap_start__ = .);
    KEEP(*(.heap))
    . = ALIGN(4);
    PROVIDE(__heap_end__ = .);
  } > SRAM

  .reserved_for_stack (NOLOAD) :
  {
    . = ALIGN(4);
    PROVIDE(__reserved_for_stack_start__ = .);
    KEEP(*(.reserved_for_stack))
    . = ALIGN(4);
    PROVIDE(__reserved_for_stack_end__ = .);
  } > SRAM

  .battery_backed_sram (NOLOAD) :
  {
    . = ALIGN(4);
    KEEP(*(.battery_backed_sram))
    . = ALIGN(4);
  } > BKPSRAM

  /DISCARD/ :
  {
    *(.ARM.attributes)
  }
}

这将导致readelf输出为：

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08020000 010000 0001f8 00  WA  0   0  4
  [ 2] .firmware_header_ PROGBITS        080201f8 0101f8 000004 00  WA  0   0  4
  [ 3] .text             PROGBITS        08020200 010200 021b44 00  AX  0   0 64
  [ 4] .ARM.extab        PROGBITS        08041d44 042728 000000 00   W  0   0  1
  [ 5] .exidx            ARM_EXIDX       08041d44 031d44 000008 00  AL  3   0  4
  [ 6] .init_array       INIT_ARRAY      08041d4c 031d4c 000008 04  WA  0   0  4
  [ 7] .fini_array       FINI_ARRAY      08041d54 031d54 000004 04  WA  0   0  4
  [ 8] .data_x           PROGBITS        20000000 040000 0009c8 00  WA  0   0  8
  [ 9] .firmware_header  PROGBITS        08042720 042720 000008 00  WA  0   0  4
  [10] .eth              NOBITS          200009c8 0509c8 0030a0 00  WA  0   0  4
  [11] .bss              NOBITS          20003a68 0509c8 045da4 00  WA  0   0  4
  [12] .heap             PROGBITS        2004980c 042728 000000 00   W  0   0  1
  [13] .reserved_for_sta PROGBITS        2004980c 042728 000000 00   W  0   0  1
  [14] .battery_backed_s NOBITS          40024000 044000 00000c 00  WA  0   0  4
  [15] .comment          PROGBITS        00000000 042728 000075 01  MS  0   0  1
  [16] .debug_frame      PROGBITS        00000000 0427a0 00144c 00      0   0  4
  [17] .stab             PROGBITS        00000000 043bec 000084 0c     18   0  4
  [18] .stabstr          STRTAB          00000000 043c70 000117 00      0   0  1
  [19] .symtab           SYMTAB          00000000 043d88 009b00 10     20 1787  4
  [20] .strtab           STRTAB          00000000 04d888 0042bb 00      0   0  1
  [21] .shstrtab         STRTAB          00000000 051b43 0000e6 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  y (purecode), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x010000 0x08020000 0x08020000 0x21d58 0x21d58 RWE 0x10000
  LOAD           0x040000 0x20000000 0x08041d58 0x009c8 0x009c8 RW  0x10000
  LOAD           0x042720 0x08042720 0x08042720 0x00008 0x00008 RW  0x10000
  LOAD           0x0509c8 0x200009c8 0x08042720 0x00000 0x48e44 RW  0x10000
  LOAD           0x044000 0x40024000 0x40024000 0x00000 0x0000c RW  0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .isr_vector .firmware_header_vector .text .exidx .init_array .fini_array 
   01     .data_x 
   02     .firmware_header 
   03     .eth .bss 
   04     .battery_backed_sram 

---

objcopy如何知道不在输出图像中插入.bss之类的节？我知道它是动态计算的，我假设这个机制是通过段到段的映射来驱动的，但是我找不到任何关于它如何实际执行段到段的映射的解释。elf文件不存储关于哪些段是闪存的信息，但是objcopy知道它不应该将.bss复制到输出文件中。怎么做？

我不知道这是否是真正的解决方法，但这就是我最终解决这个问题的方法：

  # For each program header, get the sections contained by it
  # For each section, calculate the LMA the section will reside at 
  # Do NOT load a section if...
  #   Section type is SHT_NULL or NOBITS
  #   Section size = 0
  #   The LMA is outside of the isr_vector -> header region

---

请注意，在我的例子中，我有一个部分封顶了图像的结尾。这使得图像的确切结束位置变得非常明显。

我不知道这是否是真正的方法，但我最终解决了这个问题：

  # For each program header, get the sections contained by it
  # For each section, calculate the LMA the section will reside at 
  # Do NOT load a section if...
  #   Section type is SHT_NULL or NOBITS
  #   Section size = 0
  #   The LMA is outside of the isr_vector -> header region

---

请注意，在我的例子中，我有一个部分封顶了图像的结尾。这使得图像的确切结束位置变得非常明显。

在

readelf

输出的

Flg

列中的

'A'

标志（ELF调用

SHF_ALLOC

）表示“在进程执行期间占用内存”的部分

SHF_ALLOC：该节在进程执行期间占用内存。一些 控制部分不驻留在对象文件的存储器映像中； 对于这些部分，此属性处于禁用状态

通常，这适用于程序和数据内存，在“正常”操作系统环境中，操作系统将

SHF_ALLOC

部分加载到指定的地址（忽略非

SHF_ALLOC

部分，或出于其他目的，视情况而定），一切就绪

在具有ROM程序内存的嵌入式环境中，只需输出映射到ROM中地址的

SHF_ALLOC

部分

（举例说明了一种情况，在这种情况下，仅按地址而不考虑

SHF_ALLOC

是不够的。）

但是：

根据链接器生成ELF文件的方式，初始化的数据节可能需要也可能不需要额外处理

理想情况下，链接器生成两个与初始化数据相关的部分：一个在RAM中（运行时数据区域），另一个在ROM中（RAM数据的初始化内容）。启动代码引用这些部分的地址，并将init数据复制到RAM区域。在这种情况下，只需输出ROM地址范围内的

SHF_ALLOC

部分即可自动生成正确的结果

如果链接器像普通操作系统一样生成单个节，那么在生成ROM映像时，需要在ROM中的某个地址标识和发送数据节（启动代码需要能够找到该地址）

---

如果配置正确，大多数体面的工具链都采用前一种方法，但我当然也使用了后一种方法。在

readelf

输出的

Flg

列中的

'A'

标志表示“在进程执行期间占用内存”的部分，ELF调用

SHF\u ALLOC

SHF_ALLOC：该节在进程执行期间占用内存。一些 控制部分不驻留在对象文件的存储器映像中； 对于这些部分，此属性处于禁用状态

通常，这适用于程序和数据内存，在“正常”操作系统环境中，操作系统将

SHF_ALLOC

部分加载到指定的地址（忽略非

SHF_ALLOC

部分，或出于其他目的，视情况而定），一切就绪

在具有ROM程序内存的嵌入式环境中，只需输出映射到ROM中地址的

SHF_ALLOC

部分

（举例说明了一种情况，在这种情况下，仅按地址而不考虑

SHF_ALLOC

是不够的。）

但是：

根据链接器生成ELF文件的方式，初始化的数据节可能需要也可能不需要额外处理

理想情况下，链接器生成两个与初始化数据相关的部分：一个在RAM中（运行时数据区域），另一个在ROM中（RAM数据的初始化内容）。启动代码引用这些部分的地址，并将init数据复制到RAM区域。在这种情况下，只需输出ROM地址范围内的

SHF_ALLOC

部分即可自动生成正确的结果

如果链接器像普通操作系统一样生成单个节，那么在生成ROM映像时，需要在ROM中的某个地址标识和发送数据节（启动代码需要能够找到该地址）

---

如果配置正确，大多数体面的工具链都采用前一种方法，但我肯定也使用过后一种方法。

因为它生成的是二进制图像，所以它主要来自程序头。那些没有加载到任何段中的部分最终将被忽略。固定零（nobit）的节也可能不会以二进制形式结束。因此这是有意义的，但这是否意味着它必须迭代节和程序头，然后“连接”该信息以说明将加载什么？因为按程序头，没有链接到特定程序头所涵盖的特定部分。据我所知，获取该信息的唯一方法是使用（files offset+FileSiz），然后查找在该范围内出现的块，以了解该程序头中有哪些节。这是正确的吗？更进一步，我感到困惑，因为.heap用PROGBITS标记，但没有加载。我想我真正想要的是真的