Arm objcopy后以二进制显示的额外数据。。。它是从哪里来的？
我有一个STM32项目，涉及一个linkerscript，它的设计目的是用“.firmware_header”部分覆盖图像的结尾。其思想是，此标头包含图像的crc，并且在这一点之后不应有任何内容。然而，当我Arm objcopy后以二进制显示的额外数据。。。它是从哪里来的？,arm,embedded,stm32,elf,objcopy,Arm,Embedded,Stm32,Elf,Objcopy,我有一个STM32项目，涉及一个linkerscript，它的设计目的是用“.firmware_header”部分覆盖图像的结尾。其思想是，此标头包含图像的crc，并且在这一点之后不应有任何内容。然而，当我 arm-none-eabi-objcopy firmware.elf -O binary firmware.bin 在最后一节之后存在一些数据，出于某种原因，需要这些数据才能启动映像。如果我将此神秘块归零，图像将无法启动。第一个问题是，从我看到的elf部分来看，在.firmware\u头之
arm-none-eabi-objcopy firmware.elf -O binary firmware.bin
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
.firmware_header :
{
. = ALIGN(4);
KEEP(*(.firmware_header))
. = ALIGN(4);
} > FLASH
. = ALIGN(4);
_sidata = .;
.data : AT(_sidata)
{
. = ALIGN(4);
_sdata = .;
PROVIDE(__data_start__ = _sdata);
*(.data)
*(.data*)
. = ALIGN(4);
_edata = .;
PROVIDE(__data_end__ = _edata);
} > 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)
}
}
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x8027c11
Start of program headers: 52 (bytes into file)
Start of section headers: 339928 (bytes into file)
Flags: 0x5000400, Version5 EABI, hard-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24
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 043a68 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] .firmware_header PROGBITS 08041d58 031d58 000008 00 WA 0 0 4
[ 9] .data PROGBITS 20000000 040000 0009c8 00 WA 0 0 8
[10] .RxDecripSection PROGBITS 200009c8 0409c8 000080 00 WA 0 0 4
[11] .RxarraySection PROGBITS 20000a48 040a48 0017d0 00 WA 0 0 4
[12] .TxDescripSection PROGBITS 20002218 042218 000080 00 WA 0 0 4
[13] .TxarraySection PROGBITS 20002298 042298 0017d0 00 WA 0 0 4
[14] .bss NOBITS 20003a68 043a68 045da4 00 WA 0 0 4
[15] .heap PROGBITS 2004980c 043a68 000000 00 W 0 0 1
[16] .reserved_for_sta PROGBITS 2004980c 043a68 000000 00 W 0 0 1
[17] .battery_backed_s NOBITS 40024000 044000 00000c 00 WA 0 0 4
[18] .comment PROGBITS 00000000 043a68 000075 01 MS 0 0 1
[19] .debug_frame PROGBITS 00000000 043ae0 00144c 00 0 0 4
[20] .stab PROGBITS 00000000 044f2c 000084 0c 21 0 4
[21] .stabstr STRTAB 00000000 044fb0 000117 00 0 0 1
[22] .symtab SYMTAB 00000000 0450c8 009b30 10 23 1790 4
[23] .strtab STRTAB 00000000 04ebf8 0042bb 00 0 0 1
[24] .shstrtab STRTAB 00000000 052eb3 000122 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 0x21d60 0x21d60 RWE 0x10000
LOAD 0x040000 0x20000000 0x08041d60 0x03a68 0x4980c RW 0x10000
LOAD 0x044000 0x40024000 0x40024000 0x00000 0x0000c RW 0x10000
事实证明，这是.data部分定义的一个问题。它将在.firmware\u头之后加载。有趣的是，在readefl等输出中，这一点并没有变得更清楚。解决了 我不明白是什么让你惊讶？section.data在链接器脚本中的section.firmware\u头之后，因此它是有意义的。您可能被以下事实弄糊涂了：.data部分有不同的加载和执行地址，readelf显示执行地址。您还可以查看.map文件，在该文件中可以看到两个地址