Author Topic: GCC Embedded Linker Issue Stops uSupply Development  (Read 10322 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
GCC Embedded Linker Issue Stops uSupply Development
« on: December 09, 2018, 11:48:08 pm »
David found a linker bug in the GCC 7.2 ARM-EABI (embedded) while working on the µSupply firmware. An example of how your project development can completely stop when you encounter errors like this.

 

Offline darik

  • Regular Contributor
  • *
  • Posts: 54
  • Country: us
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #1 on: December 10, 2018, 12:00:36 am »
Reduce the resource load on the linker by reducing the number of symbols it has to deal with.

Go into your code and make as many functions and variables as you can local in scope. Maybe that'll fix it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #2 on: December 10, 2018, 12:07:08 am »
Where does this version of the GCC come from? Even official launchpad version is newer, so it definitely worth trying. There is no real point on reporting bugs against old versions.
Alex
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #3 on: December 10, 2018, 12:12:54 am »
Right, first try the latest GCC version, maybe the bug is already fixed.

If not, good luck finding the bug in GCC. If you have lots of time, you can compile GCC with debug information and then debug the compiler and linker. If you don't have time, compile it with Keil µVision, they use a different compiler, written by ARM. It is even free, if you need less than 32 kB.

If you want to stick with GCC, and the latest version has still the bug, just comment out everything step by step until the linker error doesn't happen anymore. Or rollback to older versions of your code that works (I assume it is all version controlled and you commit often) and apply the changes to the current version step by step. You can then see exactly what causes the problem and probably find a workaround for it, like different link order etc., or the GCC guys can help then.

PS: GCC code quality sucks. By fuzzing the compiler, someone found found 100 bugs. The same fuzzing found 8 bugs in the Rust compiler and 9 bugs in LLVM/clang. Maybe it is possible to use LLVM/clang as the compiler and linker. But might need some work for writing new linker files, Makefiles etc.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline MSM

  • Newbie
  • Posts: 4
  • Country: de
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #4 on: December 10, 2018, 12:19:47 am »
Is it possible to dump several source files into one translation unit to decrease the number of the objects and avoid the need for linking too many of them? You may be able to pinpoint where the shunt hits the fan! :P
 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #5 on: December 10, 2018, 12:34:19 am »
(posted on youtube, but realised this is probably the better place ot have a discussion about this)

There is an open bug with linking with arm-none-eabi-gcc to do with link time optimisation -flto. Not sure if this is what you are using here however.

If it is:
Seems to only pop up with STM32 cores that I have seen reported.
Has to do with the order of the files that are being linked to, and specifically the weakly defined functions defined in the start.s assembly file being discarded.
This happens if you pass the assembly script to the linker after all the c and c++ files.
The temporary fix for this bug is to pass the assembly files to the linker first.

Otherwise it might be worth trying to see if this is a specific issue of the compiler on windows?
If the code is in VCS somehwere, maybe ask someone on the forums who has an stm32f0 dev environment setup to see if it is some random setting?
As some have mentioned you could try compiling on linux. If you havent got any of that setup, or have little interest in setting it up, perhaps ask one of the forum members to give it a crack to see if it can be linked there?

Compiling quite large codebases for stm32 products at work we have only run into the afore-mentioned actual bug in the compiler/linker.
There have been instances where using an eclipse based IDE, the java VM gets messed up and starts giving super weird compiler/linker errors. but these issues never followed the code when someone else tried to compile.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #6 on: December 10, 2018, 12:38:14 am »
Where does this version of the GCC come from? Even official launchpad version is newer, so it definitely worth trying. There is no real point on reporting bugs against old versions.
Using an older, more stable version is probably a better choice. I'm never using the latest GCC version. Always an older version (previous major version number) with a lot of bugs fixed. When it comes to software remember 'newer is always worse'.
« Last Edit: December 10, 2018, 12:40:15 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 11790
  • Country: us
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #7 on: December 10, 2018, 12:43:39 am »
Here's just a thought. It was hard to tell from the screen captures, but it looks like you might be passing lots of object files to the linker in the link command?

Have you tried putting all your object files into a library first, and then passing the library to the linker so it can resolve symbols that way? It might be more efficient for the linker than forcing it to consume all the object files directly.
 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #8 on: December 10, 2018, 12:45:01 am »
I think ataradov is more questioning that the current official release of the arm-none-eabi toolchain is the Q2 release, which on linux at least is 7.3.1.
 

Offline hwti

  • Contributor
  • Posts: 19
  • Country: fr
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #9 on: December 10, 2018, 12:57:44 am »
You should at least try with the latest 7-2018-q2 release from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads (even only the ld.exe if you have issues with the other changes).

As their binary releases aren't built with debug information, you won't get a callstack unless you rebuild the toolchain, which should be done on Ubuntu if you follow the official instructions (and adding "--build_type=native,debug" argument to their build-toolchain.sh, else they strip the binaries).
So I think it would be easier if you could reproduce the problem on Linux (you don't need to build the whole project, you can reuse the object files and the custom linker script if there is one).

Also, you are using ARM's toolchain, not official GCC/binutils releases, so the bugs should be reported at https://bugs.launchpad.net/gcc-arm-embedded/ (maybe the bug doesn't even exist on binutils master branch, only on ARM ones).
« Last Edit: December 10, 2018, 01:50:53 am by hwti »
 

Offline modrobert

  • Regular Contributor
  • *
  • Posts: 55
  • Country: th
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #10 on: December 10, 2018, 10:44:51 am »
Compile on Linux, if that fails do 'strace' in build script for linker on Linux.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #11 on: December 10, 2018, 11:45:05 am »
May not solve this particular issue, but as people pointed out on Youtube NEVER build code in a OneDrive/Dropbox folder. The build process creates/modifies/deletes hundreds/thousands of small files during build and when in such a shared folder it frequently causes things to break due to the sync program locking files while it tries to transfer them online.
If you need to put the work online use a proper repo system made for code but not an automated sync system.

The issue is very unlikely to be the linker itself, but something in your code causing it to barf. As someone also suggested on YT, I imagine that there was a point where it still built. Should look very closely, maybe post what you changed when it started failing.
« Last Edit: December 10, 2018, 12:12:05 pm by Kilrah »
 
The following users thanked this post: thm_w, BierOrk

Offline mywave

  • Newbie
  • Posts: 2
  • Country: no
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #12 on: December 10, 2018, 11:57:41 am »
It is not gcc that needs to be compiled with debug-information, but binutils (binutils includes all the low-level utilities).
 

Offline mywave

  • Newbie
  • Posts: 2
  • Country: no
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #13 on: December 10, 2018, 12:06:01 pm »
David, do you have tar-ball / .zip of all the files you are trying to link, and the ld command that is failing?
 

Online thm_w

  • Super Contributor
  • ***
  • Posts: 6278
  • Country: ca
  • Non-expert
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #14 on: December 10, 2018, 07:58:40 pm »
May not solve this particular issue, but as people pointed out on Youtube NEVER build code in a OneDrive/Dropbox folder. The build process creates/modifies/deletes hundreds/thousands of small files during build and when in such a shared folder it frequently causes things to break due to the sync program locking files while it tries to transfer them online.
If you need to put the work online use a proper repo system made for code but not an automated sync system.

The issue is very unlikely to be the linker itself, but something in your code causing it to barf. As someone also suggested on YT, I imagine that there was a point where it still built. Should look very closely, maybe post what you changed when it started failing.

yep, development will only "completely stop" if you decide to let it block you. Go back to the last working build, and either figure out what change broke it, or work on other functionality.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 
The following users thanked this post: nctnico

Offline BierOrk

  • Newbie
  • Posts: 1
  • Country: de
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #15 on: December 10, 2018, 09:22:16 pm »
May not solve this particular issue, but as people pointed out on Youtube NEVER build code in a OneDrive/Dropbox folder. The build process creates/modifies/deletes hundreds/thousands of small files during build and when in such a shared folder it frequently causes things to break due to the sync program locking files while it tries to transfer them online.
If you need to put the work online use a proper repo system made for code but not an automated sync system.

The issue is very unlikely to be the linker itself, but something in your code causing it to barf. As someone also suggested on YT, I imagine that there was a point where it still built. Should look very closely, maybe post what you changed when it started failing.

Using OneDrive/Dropbox can definitly mess up your build process. Make uses timestamps to decide wether a file has been modified since the last time it has been compiled. Even a network mount can be upsetting make.
An easy way to debug is to copy the source code and compile it with make -B

Maintainig your source code with git can help you to get back to a working version.
« Last Edit: December 10, 2018, 09:26:10 pm by BierOrk »
 

Offline nopjmp

  • Newbie
  • Posts: 1
  • Country: us
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #16 on: December 11, 2018, 02:41:01 am »
Made a forum account since most people might not realize this.

GCC was designed around large stack sizes. The easiest way to get this to work is modify the binaries stack size to a the same as Linux.

Default stack sizes:
Windows: 1MB
Linux: 8MiB

Code: [Select]
editbin /STACK:reserve[,commit]
So I would probably try playing around with this. You will need to be in "Developer command Prompt for VS" which should be in the Visual Studio menu.

For example:

Code: [Select]
editbin /STACK:8388608 ld.exe
You can be more conservative with 2097152 (2MB) but since this is a developer tool, I don't see a problem with using 8MB.

Note: I probably have the MiB/MB wrong since I'm finding conflicting material. I apologize if it's confusing.
 
The following users thanked this post: modrobert

Offline modrobert

  • Regular Contributor
  • *
  • Posts: 55
  • Country: th
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #17 on: December 11, 2018, 04:09:43 am »
Would be great if David replied, assuming he has a forum account, if nothing else just to confirm he reads this thread.
 
The following users thanked this post: mywave

Offline maginnovision

  • Super Contributor
  • ***
  • Posts: 1963
  • Country: us
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #18 on: December 11, 2018, 06:55:03 am »
I've had plenty of issues like this it's usually easiest to undo what you did that made it break and carefully analyze that code to see if anything is odd. If that doesn't work you can start commenting out blocks. If you haven't been using any version control, even if just your memory, then you sort of just need to go through everything. Do you compile with -wall? Without seeing the code I can only suggest the basic diagnostic method.  :-//
 
The following users thanked this post: Kilrah

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #19 on: December 11, 2018, 07:24:45 am »
..but it's Open Source, so you can fix issues like this yourself...
Seems you get what you pay for.

BTW  there are code-limited free versions of IAR and other professional tools, which ought to be enough for something a simple as a power supply...

I'll get my coat.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: NivagSwerdna, Fire Doger

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #20 on: December 11, 2018, 07:27:21 am »
When I was working on a big project (ZigBee stack, ~150K binary), we have reported numerous bugs to IAR, it is no better. The first few were painful, since we had to go through the support people. At some point we've just got direct contact with the engineers and things got better.
Alex
 
The following users thanked this post: Gabri74

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #21 on: December 11, 2018, 10:30:41 am »
When I was working on a big project (ZigBee stack, ~150K binary), we have reported numerous bugs to IAR, it is no better. The first few were painful, since we had to go through the support people. At some point we've just got direct contact with the engineers and things got better.
Not just that but ARM GCC is maintained by ARM themselves so saying it is free isn't exactly right.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Gabri74

  • Regular Contributor
  • *
  • Posts: 105
  • Country: it
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #22 on: December 11, 2018, 01:52:48 pm »
From the video it seems you are using Eclipse/CDT + gnu arm toolchain.
Have you tried building the same project using Atollic True Studio?
It ships with modified versions of gcc/gdb.
Since it's based on Eclipse and officially supported by ST it could work.

https://atollic.com/truestudio/
 

Offline Gabri74

  • Regular Contributor
  • *
  • Posts: 105
  • Country: it
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #23 on: December 11, 2018, 02:00:24 pm »
When I was working on a big project (ZigBee stack, ~150K binary), we have reported numerous bugs to IAR, it is no better. The first few were painful, since we had to go through the support people. At some point we've just got direct contact with the engineers and things got better.
This ^^^
Same with Keil. Despite having a full-payed license once had to download a pirated copy of their RTX RTOS to fix a bug they weren't so inclined to fix...
Last week spent one day debugging a code I swear on my life was correct but didn't work as expected (a simple FIFO queue).
Know what? Changed compiler revision and magically worked. Spent 3 hours digging trough change logs and found this
Quote
[SDCOMP-48383]  In certain circumstances, when compiling at -O3 -Otime or with --vectorize, the compiler could generate incorrect code for a do while loop with a controlling expression that contains a postfix decrement operator with an operand of unsigned type.
This was the (pseudo-)code that triggered the bug (not kidding...)
Code: [Select]
do {
    if (queue->buf[cnt] == MAX)
        do_something();
} while (cnt--)

So paid does not always means better...  ;)
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #24 on: December 11, 2018, 04:16:43 pm »
When I was working on a big project (ZigBee stack, ~150K binary), we have reported numerous bugs to IAR, it is no better. The first few were painful, since we had to go through the support people. At some point we've just got direct contact with the engineers and things got better.
Not just that but ARM GCC is maintained by ARM themselves so saying it is free isn't exactly right.

In what sense does it make it "not free"? That's like saying that since RedHat maintains a lot of GCC/employs many maintainers "saying GCC is free isn't exactly right".

"Free-ness" of software doesn't depend on who maintains the code but on the license (when talking free as in freedom) and on price (when talking free as in beer). In GCC case the license is still GPL and it is still a free download, both the "normal" and the ARM versions.


 
« Last Edit: December 11, 2018, 04:21:33 pm by janoc »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf