STM32使用malloc时创建的大型二进制文件

Question

已解决。请参阅下面的解决方案部分

我遇到了一个问题，我的构建环境输出了一个大的二进制文件，我希望有人能帮助我重新开始。

我使用STM32F105处理器、Eclipse、FreeRTOS和CodeSourcery编译器来尝试在该设备上运行一些AHRS评估代码。我有很多代码在运行，但在实现eval代码中使用malloc分配内存的部分时遇到了问题。我不得不为_sbrk添加一些代码来编译它，现在我的二进制文件从35K增加到了将近400MB。我认为这是一个链接器问题，因为.out文件（在objcopy之前）的大小大致相同。甚至从objdump输出的.s文件看起来也相当相似。

以下是一些（希望）相关的部分：

MEMORY
{
  RAM      (RWX) : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH    (RX)  : ORIGIN = 0x08000000, LENGTH = 128K
}
_estack = ORIGIN(RAM)+LENGTH(RAM);
SECTIONS
{
  .text ORIGIN(FLASH):
  {
    *(.isr_vector)
    *(.text)
    *(.text.*)
    *(.rodata)
    _sidata = .;
  }
  .data ORIGIN(RAM):
  AT (_sidata) 
  {
    _sdata = . ;
    *(.data)
    _edata = . ;
  }
  .bss (_edata) (NOLOAD):
  {
    _sbss = .;
    *(.bss)
    *(.bss.*)
    *(COMMON)
    _ebss = . ;
    . = ALIGN(4);
   _end = .;
  }
}

/* end of allocated ram _end */
PROVIDE( _HEAP_START = _end );
/* end of the heap -> align 4 byte */ 
PROVIDE ( _HEAP_END = ALIGN(ORIGIN(RAM) + LENGTH(RAM) - 4 ,4) );

生成文件：

BOOT = boot
RTOS = FreeRTOSSource
FREERTOS = $(RTOS)/port.c $(RTOS)/tasks.c $(RTOS)/croutine.c $(RTOS)/heap_2.c $(RTOS)/list.c $(RTOS)/queue.c 
APP_SOURCE = app_source/sysmon.c app_source/hscan.c app_source/gps.c app_source/mems.c app_source/gpio.c app_source/mainstates.c app_source/leds.c app_source/database.c
INEMO_LIB = inemo/mems/LSM303DLH.c inemo/mems/L3GD20.c
OBJS = main.o 
      $(BOOT)/core_cm3.o 
      $(BOOT)/system_stm32f10x.o 
      $(BOOT)/stm32f10x_rcc.o 
      $(BOOT)/stm32f10x_gpio.o 
      $(BOOT)/stm32f10x_can.o 
      $(BOOT)/stm32f10x_iwdg.o 
      $(BOOT)/stm32f10x_i2c.o 
      $(BOOT)/startup.o 
      $(BOOT)/mx_gpio.o 
      $(FREERTOS:%.c=%.o) 
      $(INEMO_LIB:%.c=%.o) 
      $(APP_SOURCE:%.c=%.o)
CFLAGS = -O0 -gdwarf-2 -mcpu=cortex-m3 -mthumb -fno-common -I$(BOOT) -std=gnu99 -c -mfloat-abi=soft -Wall -g
LFLAGS  = -mthumb -mcpu=cortex-m3 -Tscripts/stm32f103.ld -nostartfiles -lgcc -lm -lc -mfloat-abi=soft -Wall -g -O0
CPFLAGS = -O binary 
TARGET = arm-none-eabi
#TARGET = arm-elf
CC = $(TARGET)-gcc
LD = $(TARGET)-gcc
CP = $(TARGET)-objcopy
OD = $(TARGET)-objdump
all: version $(OBJS) link
$(BOOT)/startup.o:
    $(CC) $(CFLAGS) $(BOOT)/startup_stm32f10x_cl.s -lm -lc -lnosys -o $@
%.o: %.c
    $(CC) $(CFLAGS) $< -o $@
version:
    $(CC) --version
link: $(OBJS)
    $(LD) -o main.out $(OBJS) $(LFLAGS) 
    $(CP) $(CPFLAGS) main.out main.bin
    $(OD) -D -h main.out > main.S
clean:
    rm -rf $(OBJS) main.bin main.out main.S

添加此代码加上对malloc的调用，导致二进制文件增长到几乎400MB:

#include <sys/types.h>
extern unsigned int _HEAP_START;
caddr_t * _sbrk(int incr) {
      static unsigned char *heap = NULL;
      unsigned char *prev_heap;
      if (heap == NULL) {
          heap = (unsigned char *)_HEAP_START;
      }
      prev_heap = heap;
      heap += incr;
      return (caddr_t) prev_heap;
}

有没有想过如何重新行动起来？感谢您提供的任何帮助！

解决方案

通过Notlikethat的注释，我看到在构建过程中创建了另一段代码，但链接器脚本没有同名的部分。链接器决定把这个部分放在RAM中，而它本应该把它放在FLASH中。由于它跨越了RAM和FLASH，bin文件填充了它们之间的区域，导致了大的二进制文件。在链接器脚本中添加以下行（在FLASH部分），允许代码以正常大小重新构建。

*(.rodata.str1.4)

新的完整链接器脚本如下所示：

MEMORY
{
  RAM      (RWX) : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH    (RX)  : ORIGIN = 0x08000000, LENGTH = 128K
}
_estack = ORIGIN(RAM)+LENGTH(RAM);
SECTIONS
{
  .text ORIGIN(FLASH):
  {
    *(.isr_vector)
    *(.text)
    *(.text.*)
    *(.rodata)
    *(.rodata.str1.4)
    _sidata = .;
  }
  .data ORIGIN(RAM):
  AT (_sidata) 
  {
    _sdata = . ;
    *(.data)
    _edata = . ;
  }
  .bss (_edata) (NOLOAD):
  {
    _sbss = .;
    *(.bss)
    *(.bss.*)
    *(COMMON)
    _ebss = . ;
    . = ALIGN(4);
   _end = .;
  }
}

/* end of allocated ram _end */
PROVIDE( _HEAP_START = _end );
/* end of the heap -> align 4 byte */ 
PROVIDE ( _HEAP_END = ALIGN(ORIGIN(RAM) + LENGTH(RAM) - 4 ,4) );

谢谢你的帮助！

Answer 1

看起来有东西以链接器脚本无法捕获的方式插入RAM部分。您可以在最终的ELF上使用objdump或类似的方法来检查符号表并检查任何可疑的东西，例如，用这个链接器脚本构建一些琐碎的代码会给出：

$ arm-none-eabi-objdump -t a.out
a.out:     file format elf32-littlearm
SYMBOL TABLE:
20000000 l    d  .note.gnu.build-id 00000000 .note.gnu.build-id
08000000 l    d  .text  00000000 .text
20000000 l    d  .data  00000000 .data
20000004 l    d  .bss   00000000 .bss
00000000 l    d  .comment   00000000 .comment
00000000 l    d  .ARM.attributes    00000000 .ARM.attributes
00000000 l    df *ABS*  00000000 test.c
00000000 l    df *ABS*  00000000 sum.c
00000000 l    df *ABS*  00000000 
20000000 g     O .data  00000004 j
080000c0 g       .text  00000000 _sidata
20000004 g       .bss   00000000 _sbss
08000038 g     F .text  0000003c sum
20000000 g       .data  00000000 _sdata
080000bc g     O .text  00000004 k
20000008 g       .bss   00000000 _ebss
20000004 g     O .bss   00000004 i
08000000 g     F .text  00000038 main
08000074 g     F .text  00000048 sum2
20005000 g       *ABS*  00000000 _estack
20000004 g       .data  00000000 _edata
20000008 g       .bss   00000000 _end

在这种情况下，有一些带有RAM地址的符号，但在这种情况中，导致这个最终二进制文件膨胀到约400MB的是.note.gnu.build-id条目。检查章节标题揭示原因：

$ arm-none-eabi-objdump -h a.out
a.out:     file format elf32-littlearm
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .note.gnu.build-id 00000024  20000000  20000000  00030000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000074  08000000  08000000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .data         00000004  20000000  08000074  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000004  20000004  08000078  00020004  2**2
                  ALLOC
  4 .comment      00000036  00000000  00000000  00030024  2**0
                  CONTENTS, READONLY
  5 .ARM.attributes 00000033  00000000  00000000  0003005a  2**0
                  CONTENTS, READONLY

.data和.bss部分具有RAM虚拟地址（VMA），但加载地址仍在闪存（LMA）中。另一方面，音符部分也有RAM加载地址，因此将ELF转换为原始二进制会使其位于图像中其他部分之后约400MB。

从提供的额外细节来看，听起来库函数正在生成自己的.rodata部分，这些部分与脚本中的任何内容都不匹配，因此链接器的启发式算法会相当随意地分配这些部分。我会尝试将*(.rodata.*)添加到.text部分来捕捉这些内容。