Linker fails after update to gcc arm 7.2.0

Sysprogs forums Forums VisualGDB Linker fails after update to gcc arm 7.2.0

This topic contains 12 replies, has 2 voices, and was last updated by  sidprice 1 week, 2 days ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #12946

    sidprice
    Participant

    My toolchain was updated today and later when I opened a project that has previously worked just fine I get the following error:

    c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe: cannot find : Invalid argument

    Not much information to find what the issue is and verbose output is enabled.

    Sid

    #12949

    support
    Keymaster

    Hi,

    It looks like something in the linker command line is broken. Please try enabling verbose mode via VS Project Properties -> Linker -> Advanced (not the regular VisualGDB verbose mode) and post the entire verbose build output here so that we could help you understand what is going on.

    #12954

    sidprice
    Participant

    1>—— Build started: Project: bmp_windows_build, Configuration: Release VisualGDB ——
    1> command.c
    1> crc32.c
    1> exception.c
    1> gdb_hostio.c
    1> gdb_main.c
    1> gdb_packet.c
    1> hex_utils.c
    1> main.c
    1> morse.c
    1> cdcacm.c
    1> swdptap.c
    1> timing.c
    1> gdb_if.c
    1> jtagtap.c
    1> serialno.c
    1> timing_stm32.c
    1> traceswo.c
    1> usbuart.c
    1> cc3100.c
    1> platform.c
    1> WiFi_Server.c
    1> device.c
    1> driver.c
    1> flowcont.c
    1> fs.c
    1> netapp.c
    1> netcfg.c
    1> nonos.c
    1> socket.c
    1> spawn.c
    1> wlan.c
    1> adiv5.c
    1> adiv5_jtagdp.c
    1> adiv5_swdp.c
    1> cortexa.c
    1> cortexm.c
    1> efm32.c
    1> jtagtap_generic.c
    1> jtag_scan.c
    1> kinetis.c
    1> lmi.c
    1> lpc11xx.c
    1> lpc15xx.c
    1> lpc43xx.c
    1> lpc_common.c
    1> nrf51.c
    1> sam3x.c
    1> sam4l.c
    1> samd.c
    1> stm32f1.c
    1> stm32f4.c
    1> stm32l0.c
    1> stm32l4.c
    1> swdptap_generic.c
    1> target.c
    1> Linking ../VisualGDB/Release/blackmagic.elf…
    1> GNU ld (GNU Binutils) 2.29
    1> Supported emulations:
    1> armelf
    1> opened script file platforms/stm32/f4discovery.ld
    1> opened script file libopencm3_stm32f4.ld
    1> using external linker script:
    1> ==================================================
    1> /*
    1> * This file is part of the libopencm3 project.
    1> *
    1> * Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de>
    1> *
    1> c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe: cannot find : Invalid argument
    1>collect2.exe : error : ld returned 1 exit status
    1> * This library is free software: you can redistribute it and/or modify
    1> * it under the terms of the GNU Lesser General Public License as published by
    1> * the Free Software Foundation, either version 3 of the License, or
    1> * (at your option) any later version.
    1> *
    1> * This library is distributed in the hope that it will be useful,
    1> * but WITHOUT ANY WARRANTY; without even the implied warranty of
    1> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    1> * GNU Lesser General Public License for more details.
    1> *
    1> * You should have received a copy of the GNU Lesser General Public License
    1> * along with this library. If not, see <http://www.gnu.org/licenses/&gt;.
    1> */
    1>
    1> /* Generic linker script for STM32 targets using libopencm3. */
    1>
    1> /* Memory regions must be defined in the ld script which includes this one. */
    1>
    1> /* Enforce emmition of the vector table. */
    1> EXTERN (vector_table)
    1>
    1> /* Define the entry point of the output file. */
    1> ENTRY(reset_handler)
    1>
    1> /* Define sections. */
    1> SECTIONS
    1> {
    1> .text : {
    1> *(.vectors) /* Vector table */
    1> *(.text*) /* Program code */
    1> . = ALIGN(4);
    1> *(.rodata*) /* Read-only data */
    1> . = ALIGN(4);
    1> } >rom
    1>
    1> /* C++ Static constructors/destructors, also used for __attribute__
    1> * ((constructor)) and the likes */
    1> .preinit_array : {
    1> . = ALIGN(4);
    1> __preinit_array_start = .;
    1> KEEP (*(.preinit_array))
    1> __preinit_array_end = .;
    1> } >rom
    1> .init_array : {
    1> . = ALIGN(4);
    1> __init_array_start = .;
    1> KEEP (*(SORT(.init_array.*)))
    1> KEEP (*(.init_array))
    1> __init_array_end = .;
    1> } >rom
    1> .fini_array : {
    1> . = ALIGN(4);
    1> __fini_array_start = .;
    1> KEEP (*(.fini_array))
    1> KEEP (*(SORT(.fini_array.*)))
    1> __fini_array_end = .;
    1> } >rom
    1>
    1> /*
    1> * Another section used by C++ stuff, appears when using newlib with
    1> * 64bit (long long) printf support
    1> */
    1> .ARM.extab : {
    1> *(.ARM.extab*)
    1> } >rom
    1> .ARM.exidx : {
    1> __exidx_start = .;
    1> *(.ARM.exidx*)
    1> __exidx_end = .;
    1> } >rom
    1>
    1> . = ALIGN(4);
    1> _etext = .;
    1>
    1> .data : {
    1> _data = .;
    1> *(.data*) /* Read-write initialized data */
    1> . = ALIGN(4);
    1> _edata = .;
    1> } >ram AT >rom
    1> _data_loadaddr = LOADADDR(.data);
    1>
    1> .bss : {
    1> *(.bss*) /* Read-write zero initialized data */
    1> *(COMMON)
    1> . = ALIGN(4);
    1> _ebss = .;
    1> } >ram
    1>
    1> /*
    1> * The .eh_frame section appears to be used for C++ exception handling.
    1> * You may need to fix this if you’re using C++.
    1> */
    1> /DISCARD/ : { *(.eh_frame) }
    1>
    1> . = ALIGN(4);
    1> end = .;
    1> }
    1>
    1> PROVIDE(_stack = ORIGIN(ram) + LENGTH(ram));
    1>
    1>
    1> ==================================================
    1> attempt to open failed
    ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

    #12955

    support
    Keymaster

    Hi,

    Thanks for the build log. Unfortunately it looks like an error that happens before the Linker manages to output enough information.

    Please try locating the Release\Debug\<ProjectName>.link.rsp file and post its content here (please also attach your <mcu>.props file from the project directory). The file should contain the linker command line and should help us see what could be wrong.

    If you see something suspicious in the file, please try running the following command from the project directory:

    If you can reproduce the same error, try removing the suspicious part and run GCC again. If you can successfully pinpoint a part that is causing an error, please edit your settings accordingly.

    #12956

    sidprice
    Participant

    .link.rsp file:

    -o ../VisualGDB/Release/blackmagic.elf -L../VisualGDB/Release -Wl,-gc-sections -Wl,-verbose -Wl,–defsym,_stack=0x20006000, -Wl,-T,platforms/stm32/f4discovery.ld -nostartfiles -lc -lnosys -Wl,-Map=mapfile -mthumb -mcpu=cortex-m4 -Wl,-gc-sections, -mfloat-abi=hard -mfpu=fpv4-sp-d16  -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mcpu=cortex-m4  -Wl,–start-group VisualGDB/Release/command.o VisualGDB/Release/crc32.o VisualGDB/Release/exception.o VisualGDB/Release/gdb_hostio.o VisualGDB/Release/gdb_main.o VisualGDB/Release/gdb_packet.o VisualGDB/Release/hex_utils.o VisualGDB/Release/main.o VisualGDB/Release/morse.o VisualGDB/Release/cdcacm.o VisualGDB/Release/swdptap.o VisualGDB/Release/timing.o VisualGDB/Release/gdb_if.o VisualGDB/Release/jtagtap.o VisualGDB/Release/serialno.o VisualGDB/Release/timing_stm32.o VisualGDB/Release/traceswo.o VisualGDB/Release/usbuart.o VisualGDB/Release/cc3100.o VisualGDB/Release/platform.o VisualGDB/Release/WiFi_Server.o VisualGDB/Release/device.o VisualGDB/Release/driver.o VisualGDB/Release/flowcont.o VisualGDB/Release/fs.o VisualGDB/Release/netapp.o VisualGDB/Release/netcfg.o VisualGDB/Release/nonos.o VisualGDB/Release/socket.o VisualGDB/Release/spawn.o VisualGDB/Release/wlan.o VisualGDB/Release/adiv5.o VisualGDB/Release/adiv5_jtagdp.o VisualGDB/Release/adiv5_swdp.o VisualGDB/Release/cortexa.o VisualGDB/Release/cortexm.o VisualGDB/Release/efm32.o VisualGDB/Release/jtagtap_generic.o VisualGDB/Release/jtag_scan.o VisualGDB/Release/kinetis.o VisualGDB/Release/lmi.o VisualGDB/Release/lpc11xx.o VisualGDB/Release/lpc15xx.o VisualGDB/Release/lpc43xx.o VisualGDB/Release/lpc_common.o VisualGDB/Release/nrf51.o VisualGDB/Release/sam3x.o VisualGDB/Release/sam4l.o VisualGDB/Release/samd.o VisualGDB/Release/stm32f1.o VisualGDB/Release/stm32f4.o VisualGDB/Release/stm32l0.o VisualGDB/Release/stm32l4.o VisualGDB/Release/swdptap_generic.o VisualGDB/Release/target.o -lopencm3_stm32f4 -Wl,–end-group

    Sid

    #12957

    support
    Keymaster

    The RSP file looks OK. As a quick check, could you try creating a new “LEDBlink” project with the same toolchain? If it doesn’t work, please try reinstalling the toolchain.

    If it does, please try comparing both RSP files.

    #12958

    sidprice
    Participant

    I built the Led Blink project fine.

     

    Trying to compare the two RSP files is very hard because my project is using libOpenCM3 so options are very different.

    Sid

    #12959

    support
    Keymaster

    Hi,

    We would advise trying to minimize both command lines as long as they still produce different results.

    E.g. try removing all .o files from the opencm3 command line and check if you get the same cryptic error or an actual “missing entry point” error. If the message is still cryptic, try replacing the linker script with the normal linker script and if it doesn’t change anything, try removing other options.

    #12963

    sidprice
    Participant

    Just not getting anywhere with this. I have removed the options one-at-a-time and I still see the same error.

    Sid

    #12964

    sidprice
    Participant

    Since I need to make progress on my project I switched back to the previous toolchain and my project now compiles.  More than a little worrying that there is some incompatibility between my solution and the new toolchain.

     

    even more concerning is that it seems almost impossible to debug the problem :{

    Sid

    #12968

    support
    Keymaster

    Hi,

    We have managed to reproduce the problem from the template file you attached in another thread and it looks like the the problem is caused by the extra comma after some arguments in your command line, e.g.:

    should be

    We agree that the error message shown by gcc is not very informative and extremely cryptic, although it would be beyond our capacity to maintain and ship a special fork of GCC resolving such issues. Our best advice would be to try contacting the GCC mailing lists to see if anyone there is willing to fix this.

     

    #12972

    sidprice
    Participant

    Thanks, does this mean I can update the toolchain? If so how do I get VGDB to do that,

    Sid

    #12973

    sidprice
    Participant

    I found how to update the toolchain and also an additional “,” in the linker opitons, now my project builds fine with the new toolchain. Many thanks.

    Sid

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.