Compilation 关于链接器脚本创建和验证的建议

Compilation 关于链接器脚本创建和验证的建议,compilation,arm,stm32,cortex-m3,linker-scripts,Compilation,Arm,Stm32,Cortex M3,Linker Scripts,长话短说。我希望学习如何创建一个好的链接器脚本,这样当我改变平台/架构/供应商时,我就不会再陷入不知道该做什么的境地。我关心的不是任务的难度,而是理解它。 可以说,我已经开始了一种在STM的32位Cortex-M3芯片上编程和开发的基础或框架。借助于从STM32F103RB开始的帮助(我也有一个TI Stellaris LM3S828,但这是另一个问题),无需许可IDE。因为我是学生,大多数学生买不起这样的东西 我知道有ODev和Eclipse插件等等,我读过各种博客、Wiki、文档/手册页,大

长话短说。我希望学习如何创建一个好的链接器脚本,这样当我改变平台/架构/供应商时,我就不会再陷入不知道该做什么的境地。我关心的不是任务的难度,而是理解它。

可以说,我已经开始了一种在STM的32位Cortex-M3芯片上编程和开发的基础或框架。借助于从STM32F103RB开始的帮助(我也有一个TI Stellaris LM3S828,但这是另一个问题),无需许可IDE。因为我是学生,大多数学生买不起这样的东西

我知道有ODev和Eclipse插件等等,我读过各种博客、Wiki、文档/手册页,大多数项目都为您提供了一个链接器脚本,其中很少有关于定义原因和位置的解释

我已经为STM32编译了一个arm none eabi工具链,但我遇到的问题是链接器脚本。CodeSource也需要一个。在阅读gnu手册页之后,我对如何创建它们以及它们的语法有了一个基本的概念,但是除了显而易见的.text、.bss和.data之外,我根本不知道从哪里开始添加各种额外的部分


我创建了一个链接,但是我在请求节定义时遇到了链接错误,这就是我被卡住的地方。我知道如何定义它们,但知道我所做的是否接近正确是个问题。

这里是一个STM32F105RB的工作链接器脚本(R8和RC也有一些版本):

(下文)

我猜你不必改变任何事情。可能是内存{}语句中定义的区域的起源。希望这些评论能对你有所帮助

我将其与我自己开发的GNU/GCC交叉编译器一起使用。编译后,在代码上运行
nm
,以确保节位于正确的地址是很有帮助的

编辑: 我使用GNU ld文档将此链接器脚本拼凑在一起:

通过使用标准链接器脚本检查GCC交叉编译的输出,使用
nm
。我基本上识别了所有被输出的部分,并找出了哪些部分是真正有用的,以及它们应该在内存中的什么位置用于STM32F105

我在链接器脚本中记录了每个部分的用途

/*
arp.{r8,rb,rc}.ld :
These linker scripts (one for each memory density of the stm32f105) are used by
the linker to arrange program symbols and sections in memory. This is especially
important for sections like the interrupt vector, which must be placed where the
processor is hard-coded to look for it.
*/

/*stm32f105 dev board linker script*/

/*
OUTPUT_FORMAT() defines the BFD (binary file descriptor) format
OUTPUT_FORMAT(default, big, little)
*/
OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* ENTRY() defines the symbol at which to begin executing code */
ENTRY(_start)
/* tell ld where to look for archive libraries */
/*SEARCH_DIR("/home/arp/stm/ctc/arm-eabi/lib")*/
/*SEARCH_DIR("/home/arp/stm/ccbuild/method2/install/arm-eabi/lib")*/
SEARCH_DIR("/home/arp/stm32dev-root/usrlol/arm-eabi/lib")

/*
MEMORY{} defines the memory regions of the target device,
and gives them an alias for use later in the linker script.
*/

/* stm32f105rb */
MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 32k
  flash (rx) : ORIGIN = 0x08000000, LENGTH = 128k
  option_bytes_rom (rx) : ORIGIN = 0x1FFFF800, LENGTH = 16
}

_sheap = _ebss + 4;
_sstack = _ebss + 4;
/*placed __stack_base__ trying to figure out
global variable overwrite issue
__stack_base__ = _ebss + 4;*/

_eheap = ORIGIN(ram) + LENGTH(ram) - 1;
_estack = ORIGIN(ram) + LENGTH(ram) - 1;

/* SECTIONS{} defines all the ELF sections we want to create */
SECTIONS
{
    /*
    set . to an initial value (0 here).
    . (dot) is the location counter. New sections are placed at the
    location pointed to by the location counter, and the location counter
    is automatically moved ahead the length of the new section. It is important
    to maintain alignment (not handled automatically by the location counter).
    */
    . = SEGMENT_START("text-segment", 0);



    /*isr_vector contains the interrupt vector.

    isr_vector is read only (could be write too?).

    isr_vector must appear at start of flash (USR),
    address 0x0800 0000*/
    .isr_vector :
    {
      . = ALIGN(4);
      _sisr_vector = .;

      *(.isr_vector)

      _eisr_vector = .;
    } >flash

    /*text contains executable code.

    text is read and execute.*/
    .text :
    {
      . = ALIGN(4);
      *(.text)
      . = ALIGN(4);
      *(.text.*)
    } >flash

    /*init contains constructor functions
    called before entering main. used by crt (?).*/
    .init :
    {
      . = ALIGN(4);
      KEEP(*(.init))
    } >flash

    /*fini contains destructor functions
    called after leaving main. used by crt (?).*/
    .fini :
    {
      . = ALIGN(4);
      KEEP(*(.fini))
    } >flash

    /* rodata contains read only data.*/
    .rodata :
    {
      . = ALIGN(4);
      *(.rodata)

      /* sidata contains the initial values
      for variables in the data section.

      sidata is read only.*/
      . = ALIGN(4);
      _sidata = .;
    } >flash

    /*data contains all initalized variables.

    data is read and write. 
    .data (NOLOAD) : AT(_sidata)*/
    .data : AT(_sidata)
    {
      . = ALIGN(4);
      _sdata = .;

      *(.data)

      _edata = .;
    } >ram

    /*bss contains unintialized variables.

    bss is read and write.
    .bss (NOLOAD) :*/
    .bss :
    {
      . = ALIGN(4);
      _sbss = .;
      __bss_start__ = .;

      *(.bss)
      . = ALIGN(4);

      /*COMMON is a special section containing
      uninitialized data.

      Example: (declared globally)
      int temp; //this will appear in COMMON */
      *(COMMON)

      _ebss = .;
      __bss_end__ = .;
    } >ram AT>flash

    . = ALIGN(4);
    end = .;

        /* remove the debugging information from the standard libraries */
    DISCARD :
    {
     libc.a ( * )
     libm.a ( * )
     libgcc.a ( * )
     }

    /* 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) }
    /* 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_frame    0 : { *(.debug_frame) }
    .debug_str      0 : { *(.debug_str) }
    .debug_loc      0 : { *(.debug_loc) }
    .debug_macinfo  0 : { *(.debug_macinfo) }
    /* SGI/MIPS DWARF 2 extensions */
    .debug_weaknames 0 : { *(.debug_weaknames) }
    .debug_funcnames 0 : { *(.debug_funcnames) }
    .debug_typenames 0 : { *(.debug_typenames) }
    .debug_varnames  0 : { *(.debug_varnames) }
}

我有一个简单的链接器脚本,可以跨平台重复使用,只需根据需要更改一些地址

有许多示例,其中许多是gcc示例,大多数都有链接器脚本

MEMORY
{
   rom : ORIGIN = 0x00000000, LENGTH = 0x40000
   ram : ORIGIN = 0x10000000, LENGTH = 30K
}

SECTIONS
{
   .text : { *(.text*) } > rom
   .bss  : { *(.bss*) } > ram
}

有人告诉我,我们不能只提供答案中的链接,因为这些链接可能会发生变化,但会将信息引入到我们正在讨论的答案中。我已将您指定的文件添加到您的答案中。您从何处获得创建此脚本所需的信息?你怎么知道你需要_sheap、_sidata和_sstack以及分配给他们什么。这就是我要找的信息类型。我编辑了我的答案。这些部分中的每一部分(以及更多部分)都显示在使用标准链接器脚本的编译中。检查脚本中的注释_sheap是堆的开始,_sstack是堆栈的开始。gnu链接器脚本充其量是相当痛苦的。从gcc 3.x到4.x,以前有用的东西不再有用了,所以,我认为不管你做得多么好,总有一天他们会把你脚下的地毯拽出来。这是真的。我只能期待。然而,从4.x到5.x,我可以得到一些扎实的工作,这将是一个遵循更改日志的问题。如果有任何重大变化,请保持简单。绝对任何人都能读到并理解它。很多人试图直接将内存映射寄存器等放到链接器脚本中,很快它就有了自己的生命。更不用说不可移植了。这不是至少缺少了数据部分吗?(初始化的全局变量将去哪里?)