未记录的链接器问题:“ld返回253退出状态”

8
我收到一个错误消息,但我找不到任何相关信息。在哪里可以查找关于 ld 的 253 退出状态的信息?
我无法在任何地方找到任何信息。谷歌上只有一处提及,似乎与任何解决方案都不相关。
错误消息:
collect2.exe: error: ld returned 253 exit status
使用链接器和编译器的详细输出,没有其他警告或错误与以上内容有任何关系。
尝试解决问题:
此错误与程序大小有些相关,但是该程序还没有达到系统闪存的大小,所以我有点困惑。
如果我运行 size, 结果如下(设备限制为64 KB):
text    data     bss     dec
45608     396    6200   52204

当我将设备内存大小增加到128K时,没有任何改变,仍然显示相同的消息...

但是,如果我将代码大小减少到大约54 KB以下,则程序可以编译,不管我删除了哪些代码。

如果我只添加一点点代码,二进制文件的大小应该只会增加几百个字节。但是,当我这样做时,链接器就会出现上述错误。

通过使用objcopy创建的二进制文件进行检查时,可以看到内存中有很大的空闲区域;内存肯定没有满。链接器文件已附加,但我不知道它们如何导致我的问题:

链接已删除以替代在问题中包含链接器文件。

更新

问题仍然存在,但我注意到在生成的映射文件中,它似乎停在模板对象的中间。就好像链接器简单地抛出了一些异常并中止了。它停止的行是非常重的模板代码,但它确实实例化了与它崩溃的完全相同(或至少具有捕获的lambda类型的类似对象。根据标准,它们总是唯一的类型)。

映射文件中的最后一个项目位于0x080008CE,因为flash从地址0x08000000开始,这实际上是0x08CE,远远没有达到flash的结尾。

文件sections.ld

/*
 * Default linker script for Cortex-M (it includes specifics for STM32F[34]xx).
 *
 * To make use of the multi-region initialisations, define
 * OS_INCLUDE_STARTUP_INIT_MULTIPLE_RAM_SECTIONS for the _startup.c file.
 */

/*
 * The '__stack' definition is required by crt0, do not remove it.
 */
__stack = ORIGIN(RAM) + LENGTH(RAM);

_estack = __stack;     /* STM specific definition */

/*
 * Default stack sizes.
 * These are used by the startup in order to allocate stacks
 * for the different modes.
 */

__Main_Stack_Size = 1024 ;

PROVIDE ( _Main_Stack_Size = __Main_Stack_Size ) ;

__Main_Stack_Limit = __stack  - __Main_Stack_Size ;

/* "PROVIDE" allows to easily override these values from an
 * object file or the command line. */
PROVIDE ( _Main_Stack_Limit = __Main_Stack_Limit ) ;

/*
 * There will be a link error if there is not this amount of
 * RAM free at the end.
 */
_Minimum_Stack_Size = 256 ;

/*
 * Default heap definitions.
 * The heap start immediately after the last statically allocated
 * .sbss/.noinit section, and extends up to the main stack limit.
 */
PROVIDE ( _Heap_Begin = _end_noinit ) ;
PROVIDE ( _Heap_Limit = __stack - __Main_Stack_Size ) ;

/*
 * The entry point is informative, for debuggers and simulators,
 * since the Cortex-M vector points to it anyway.
 */
ENTRY(_start)


/* Sections Definitions */

SECTIONS
{
    /*
     * For Cortex-M devices, the beginning of the startup code is stored in
     * the .isr_vector section, which goes to FLASH.
     */
    .isr_vector : ALIGN(4)
    {
        FILL(0xFF)

        __vectors_start = ABSOLUTE(.) ;
        __vectors_start__ = ABSOLUTE(.) ;  /* STM specific definition */
        KEEP(*(.isr_vector))               /* Interrupt vectors */

        KEEP(*(.cfmconfig))                /* Freescale configuration words */

        /*
         * This section is here for convenience, to store
         * the startup code at the beginning of the flash
         * area, hoping that this will increase
         * the readability of the listing.
         */
        *(.after_vectors .after_vectors.*)  /* Startup code and ISR */

    } >FLASH

    .inits : ALIGN(4)
    {
        /*
         * Memory regions initialisation arrays.
         *
         * Thee are two kinds of arrays for each RAM region, one for
         * data and one for bss. Each is iterated at startup and the
         * region initialisation is performed.
         *
         * The data array includes:
         * - from (LOADADDR())
         * - region_begin (ADDR())
         * - region_end (ADDR()+SIZEOF())
         *
         * The bss array includes:
         * - region_begin (ADDR())
         * - region_end (ADDR()+SIZEOF())
         *
         * WARNING: It is mandatory that the regions are word aligned,
         * since the initialisation code works only on words.
         */

        __data_regions_array_start = .;

        LONG(LOADADDR(.data));
        LONG(ADDR(.data));
        LONG(ADDR(.data)+SIZEOF(.data));

        __data_regions_array_end = .;

        __bss_regions_array_start = .;

        LONG(ADDR(.bss));
        LONG(ADDR(.bss)+SIZEOF(.bss));

        __bss_regions_array_end = .;

        /* End of memory regions initialisation arrays. */

        /*
         * These are the old initialisation sections, intended to contain
         * naked code, with the prologue/epilogue added by crti.o/crtn.o
         * when linking with startup files. The standalone startup code
         * currently does not run these, better use the init arrays below.
         */
        KEEP(*(.init))
        KEEP(*(.fini))

        . = ALIGN(4);

        /*
         * The preinit code, i.e. an array of pointers to initialisation
         * functions to be performed before constructors.
         */
        PROVIDE_HIDDEN (__preinit_array_start = .);

        /*
         * Used to run the SystemInit() before anything else.
         */
        KEEP(*(.preinit_array_sysinit .preinit_array_sysinit.*))

        /*
         * Used for other platform inits.
         */
        KEEP(*(.preinit_array_platform .preinit_array_platform.*))

        /*
         * The application inits. If you need to enforce some order in
         * execution, create new sections, as before.
         */
        KEEP(*(.preinit_array .preinit_array.*))

        PROVIDE_HIDDEN (__preinit_array_end = .);

        . = ALIGN(4);

        /*
         * The init code, i.e. an array of pointers
         * to static constructors.
         */
        PROVIDE_HIDDEN (__init_array_start = .);
        KEEP(*(SORT(.init_array.*)))
        KEEP(*(.init_array))
        PROVIDE_HIDDEN (__init_array_end = .);

        . = ALIGN(4);

        /*
         * The fini code, i.e. an array of pointers to static destructors.
         */
        PROVIDE_HIDDEN (__fini_array_start = .);
        KEEP(*(SORT(.fini_array.*)))
        KEEP(*(.fini_array))
        PROVIDE_HIDDEN (__fini_array_end = .);

    } >FLASH


    /*
     * For some STRx devices, the beginning of the startup code
     * is stored in the .flashtext section, which goes to FLASH.
     */
    .flashtext : ALIGN(4)
    {
        *(.flashtext .flashtext.*)    /* Startup code */
    } >FLASH


    /*
     * The program code is stored in the .text section,
     * which goes to FLASH.
     */
    .text : ALIGN(4)
    {
        *(.text .text.*)            /* All remaining code */

         /* Read-only data (constants) */
        *(.rodata .rodata.* .constdata .constdata.*)

        *(vtable)                    /* C++ virtual tables */

        KEEP(*(.eh_frame*))

        /*
         * Stub sections generated by the linker, to glue together
         * ARM and Thumb code. .glue_7 is used for ARM code calling
         * Thumb code, and .glue_7t is used for Thumb code calling
         * ARM code. Apparently always generated by the linker,
         * for some architectures, so better leave them here.
         */
        *(.glue_7)
        *(.glue_7t)

    } >FLASH

    /* ARM magic sections */
    .ARM.extab : ALIGN(4)
       {
       *(.ARM.extab* .gnu.linkonce.armextab.*)
       } > FLASH

    . = ALIGN(4);
       __exidx_start = .;
       .ARM.exidx : ALIGN(4)
       {
       *(.ARM.exidx* .gnu.linkonce.armexidx.*)
       } > FLASH

       __exidx_end = .;

    . = ALIGN(4);
    _etext = .;
    __etext = .;


    /*
     * This address is used by the startup code to
     * initialise the .data section.
     */
    _sidata = LOADADDR(.data);

    .ConfigData : ALIGN(4)
    {
        KEEP(*(.ConfigData));
        PROVIDE (ConfigAddress = ABSOLUTE(.));
    } > CONFIG

    /*
     * The initialised data section.
     *
     * The program executes knowing that the data is in the RAM
     * but the loader puts the initial values in the FLASH (inidata).
     * It is one task of the startup to copy the initial values from
     * FLASH to RAM.
     */
    .data : ALIGN(4)
    {
        FILL(0xFF)
        /* This is used by the startup code
           to initialise the .data section */
        _sdata = . ;            /* STM specific definition */
        __data_start__ = . ;
        *(.data_begin .data_begin.*)

        *(.data .data.*)
        *(.data_end .data_end.*)
        . = ALIGN(4);

        /* This is used by the startup code
           to initialise the .data section */
        _edata = . ;            /* STM specific definition */
        __data_end__ = . ;

    } >RAM AT>FLASH



    /* The primary uninitialised data section. */
    .bss (NOLOAD) : ALIGN(4)
    {
        __bss_start__ = .;         /* standard newlib definition */
        _sbss = .;              /* STM specific definition */
        *(.bss_begin .bss_begin.*)

        *(.bss .bss.*)
        *(COMMON)

        *(.bss_end .bss_end.*)
        . = ALIGN(4);
        __bss_end__ = .;        /* Standard newlib definition */
        _ebss = . ;             /* STM specific definition */
    } >RAM

    .noinit (NOLOAD) : ALIGN(4)
    {
        _noinit = .;

        *(.noinit .noinit.*)

         . = ALIGN(4) ;
        _end_noinit = .;
    } > RAM


    /* Mandatory to be word aligned, _sbrk assumes this */
    PROVIDE ( end = _end_noinit ); /* was _ebss */
    PROVIDE ( _end = _end_noinit );
    PROVIDE ( __end = _end_noinit );
    PROVIDE ( __end__ = _end_noinit );

    /*
     * Used for validation only, do not allocate anything here!
     *
     * This is just to check that there is enough RAM left for the Main
     * stack. It should generate an error if it's full.
     */
    ._check_stack : ALIGN(4)
    {
        . = . + _Minimum_Stack_Size ;
    } >RAM

    /* After that there are only debugging sections. */
    /* This can 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) }
}

File mem.ld

MEMORY
{
  RAM          (xrw) : ORIGIN = 0x20000000,                    LENGTH = 0x4000
  FLASH        (rx)  : ORIGIN = 0x08000000,                    LENGTH = 0x1F800
  CONFIG       (rx)  : ORIGIN = ORIGIN(FLASH) + LENGTH(FLASH), LENGTH = 0x800
  FLASHB1      (rx)  : ORIGIN = 0x00000000,                    LENGTH = 0
  EXTMEMB0     (rx)  : ORIGIN = 0x00000000,                    LENGTH = 0
  EXTMEMB1     (rx)  : ORIGIN = 0x00000000,                    LENGTH = 0
  EXTMEMB2     (rx)  : ORIGIN = 0x00000000,                    LENGTH = 0
  EXTMEMB3     (rx)  : ORIGIN = 0x00000000,                    LENGTH = 0
  MEMORY_ARRAY (xrw) : ORIGIN = 0x00000000,                    LENGTH = 0
}

更新2

引起错误的代码,在错误发生时正在链接Visual Studio。

更新3

即使使用了更新的链接器文件和以下标志,该错误仍然会发生:

arm-none-eabi-g++ -mcpu=cortex-m0 -march=armv6-m -mthumb -Os -fmessage-length=0 -ffreestanding -flto -Wunused -Wuninitialized -Wall -Wextra  -g -T "../ldscripts/mem.ld" -T "../ldscripts/sections.ld" -T "../ldscripts/libs.ld" -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"uSupply Firmware V1_0.map" --specs=nano.specs -o "uSupply Firmware V1_0.elf"  ./system/src/stm32f0-stdperiph/stm32f0xx_adc.o ./system/src/stm32f0-stdperiph/stm32f0xx_can.o ./system/src/stm32f0-stdperiph/stm32f0xx_cec.o ./system/src/stm32f0-stdperiph/stm32f0xx_comp.o ./system/src/stm32f0-stdperiph/stm32f0xx_crc.o ./system/src/stm32f0-stdperiph/stm32f0xx_crs.o ./system/src/stm32f0-stdperiph/stm32f0xx_dac.o ./system/src/stm32f0-stdperiph/stm32f0xx_dbgmcu.o ./system/src/stm32f0-stdperiph/stm32f0xx_dma.o ./system/src/stm32f0-stdperiph/stm32f0xx_exti.o ./system/src/stm32f0-stdperiph/stm32f0xx_flash.o ./system/src/stm32f0-stdperiph/stm32f0xx_gpio.o ./system/src/stm32f0-stdperiph/stm32f0xx_i2c.o ./system/src/stm32f0-stdperiph/stm32f0xx_iwdg.o ./system/src/stm32f0-stdperiph/stm32f0xx_misc.o ./system/src/stm32f0-stdperiph/stm32f0xx_pwr.o ./system/src/stm32f0-stdperiph/stm32f0xx_rcc.o ./system/src/stm32f0-stdperiph/stm32f0xx_rtc.o ./system/src/stm32f0-stdperiph/stm32f0xx_spi.o ./system/src/stm32f0-stdperiph/stm32f0xx_syscfg.o ./system/src/stm32f0-stdperiph/stm32f0xx_tim.o ./system/src/stm32f0-stdperiph/stm32f0xx_usart.o ./system/src/stm32f0-stdperiph/stm32f0xx_wwdg.o  ./system/src/newlib/_cxx.o ./system/src/newlib/_exit.o ./system/src/newlib/_sbrk.o ./system/src/newlib/_startup.o ./system/src/newlib/_syscalls.o ./system/src/newlib/assert.o  ./system/src/diag/Trace.o ./system/src/diag/trace_impl.o  ./system/src/cortexm/_initialize_hardware.o ./system/src/cortexm/_reset_hardware.o ./system/src/cortexm/exception_handlers.o  ./system/src/cmsis/system_stm32f0xx.o ./system/src/cmsis/vectors_stm32f0xx.o  ./src/peripherals/Interrupt.o  ./src/_write.o ./src/main.o

1
将MCVE(包括任何相关的链接器脚本和make文件等)包含在问题中,而不是通过外部链接,可以改善问题。 - M.M
1
这绝对是一个链接器的错误。确切的细节并不重要。链接器应该能够成功或失败,并提供可读的诊断信息。其他任何情况都是错误。 - n. m.
2
我们花费了数周时间来解决一个非常相似的问题,这是一个500k行的模板重型C++程序(完全是专有代码,我们无法提供足够的信息向上报告错误)。关闭链接时间优化对我们有所帮助。几周后进行了一些大型合并后,LTO又开始工作了。多年来,我们一直在开启和关闭它。 - haggi
1
你有没有考虑过查看GCC _ld_源代码?如果你仍在寻找解决方案,我想你也可以构建自己的调试版本_ld_。我怀疑任何人都无法在没有你尝试链接的二进制文件(和/或特定硬件)的情况下告诉你问题的确切原因。 - agg3l
1
我已经解决了这个问题,但我的解决方案被删除了,因为其中包含一个链接... 我编辑了解决方案并删除了链接,以便所有信息都在帖子中。我不知道审核过程是如何工作的,或者是否有审核过程...这是由于ld.exe需要处理的符号数量导致的堆栈溢出。解决方法是增加堆栈限制或升级到GCC 8.2,8.2对于相同的代码产生的符号要少得多。 - David Ledger
显示剩余5条评论
1个回答

4
错误的原因是在Libiberty的实现中使用了VLA。VLA是放置在堆栈上的数据结构,当程序具有大量符号时,会超过应用程序的堆栈限制。在Libiberty中,存在一个标志,允许避免VLA,并且结果是使用alloca。这个分配也发生在堆栈上,同样会出现同样的问题。
GCC 7.2生成的符号信息比GCC 8.2多得多。
解决方案有三个:
  1. 在Linux上,使用ulimit -s unlimited并从同一终端窗口启动GCC 7.2。 ulimit仅影响子进程。
  2. 在Windows上,使用不同的堆栈大小重新编译GCC ld.exe。 editbin不能正确地处理ld.exe。
  3. Windows / Linux:升级到GCC 8.2。这个版本的编译器对符号更好,并且在此情况下该问题得到解决。
Tamar Christina向Libiberty提出了这个问题,我怀疑,就像Linux内核一样,VLA将被从实现中删除。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接