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

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #25 on: December 11, 2018, 04:58:08 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.
Not free as in: with every ARM device you buy you pay for the development of gcc for the ARM platform.

It is kind of like (commercial) TV and radio aren't free even though you don't have to pay anything to the TV station. With every product you buy you pay for TV and radio.
« Last Edit: December 11, 2018, 05:02:57 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #26 on: December 11, 2018, 05:01:53 pm »
He's probably twisting it in the sense that "we all pay a little something for it when we buy something with an ARM core".
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21606
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #27 on: December 11, 2018, 05:05:21 pm »
..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.

Hey Mike, why don't you go PIC your nose... ;D

(...No, I don't have anything to contribute to this thread.  I use avr-gcc and have found zero problems with it.)

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #28 on: December 11, 2018, 05:15:25 pm »
I think the point of the video was not to solve the problem, but to show just how horrible tools are, since the most obvious solution or at least path to a workaround was mentioned here multiple times.

AVR-GCC toolchain is infamous with its "relocation truncated to fit: R_AVR_13_PCREL" liner errors that pop up for multiple reasons, so they get fixed and pop up again. This happens from time to time, not a huge deal, just rearrange some stuff in the code and it goes away.
Alex
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21606
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #29 on: December 11, 2018, 05:31:33 pm »
I think the point of the video was not to solve the problem, but to show just how horrible tools are, since the most obvious solution or at least path to a workaround was mentioned here multiple times.

AVR-GCC toolchain is infamous with its "relocation truncated to fit: R_AVR_13_PCREL" liner errors that pop up for multiple reasons, so they get fixed and pop up again. This happens from time to time, not a huge deal, just rearrange some stuff in the code and it goes away.

Hmm, so a discrepancy between where the compiler expected the data to be, and where the linker wanted/had to put it?  I can see that being a problem with the >128k AVRs, yes.  Or more generally, any system with segmented memory, or even more generally, a platform with different sizes of pointers.

And yeah, everything is horrible.  Anything only ever gets fixed just enough to be usable, for some arbitrary (market-driven?*) degree of "usable".  Any sufficiently large project, is too large to ever find all the bugs, or unexpected quirks, before release.

*Hey, you guys all like capitalism, right?  Right?... :P

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #30 on: December 11, 2018, 05:39:45 pm »
Hmm, so a discrepancy between where the compiler expected the data to be, and where the linker wanted/had to put it?
No, linker is just not able to place the code. LD does not "shuffle" the functions around, it just places things in a linear order and once placed, a function can no longer be taken out and placed somewhere else. And two or more functions may be located in a way that the distance between them is bigger than 13-bit relative offset allows.

This can happen on smaller memory devices too. 13-bits it +/- 8K words, so any device with memory size over this number may be affected.

And that just describes the legitimate case. This particular linker error happened in a few cases because of compiler bugs and had nothing to do with the linker itself.
Alex
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #31 on: December 11, 2018, 07:04:18 pm »
Hmm, so a discrepancy between where the compiler expected the data to be, and where the linker wanted/had to put it?
No, linker is just not able to place the code. LD does not "shuffle" the functions around, it just places things in a linear order and once placed, a function can no longer be taken out and placed somewhere else. And two or more functions may be located in a way that the distance between them is bigger than 13-bit relative offset allows.

This can happen on smaller memory devices too. 13-bits it +/- 8K words, so any device with memory size over this number may be affected.

And that just describes the legitimate case. This particular linker error happened in a few cases because of compiler bugs and had nothing to do with the linker itself.
That error ought to be sanely reported, and fixed by selecting an appropriate memory model.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #32 on: December 11, 2018, 07:09:24 pm »
That error ought to be sanely reported, and fixed by selecting an appropriate memory model.
I'm not really sure how to report it any better short of writing a complete explanation in the error message. Given the error message it is not all that hard to find documentation explaining the error in details.

You can say that compiler can try harder to avoid the issue, but it is still possible to create code that can't be properly placed in the device no matter what.

Also IAR shows very similar message in this situation as well.
« Last Edit: December 11, 2018, 07:11:56 pm by ataradov »
Alex
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #33 on: December 11, 2018, 10:13:41 pm »
Not free as in: with every ARM device you buy you pay for the development of gcc for the ARM platform.

It is kind of like (commercial) TV and radio aren't free even though you don't have to pay anything to the TV station. With every product you buy you pay for TV and radio.

That's a rather oddball definition, but okay. Let's not pollute the thread with more philosophical disputes.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #34 on: December 11, 2018, 10:29:27 pm »
I have seen similar things happen with STM32 code as well - sometimes simply changing the optimization level for the compiler will make this go away because the compiler will inline some functions, remove unused code and suddenly the linker won't blow up anymore. My impression is that the ARM port of binutils could use a bit more love.

And re Mike and the suggestion to use IAR - given that you are mostly a PIC developer, you are probably intimately familiar with the shitshow the various PIC compilers, especially for the smaller devices (PIC18 and such) are. And they were (still are?) paid. So much for the "you get what you pay for" in this case. I will use GCC or Clang (that supports ARM as well, AFAIK) any day over those things.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #35 on: December 13, 2018, 09:39:37 pm »
https://www.mail-archive.com/bug-binutils@gnu.org/msg29920.html

Quote
It seems that Nick was right that this hitting the stack limit.

The reason it's doing so is that you have a quite a lot of templates in your
C++ code.

The linker seems to segfault when it's trying to demangle this symbol
_ZNSt11_Tuple_implILj0EJN7General6Parser4NodeINS1_7KeywordILj4ELj2EEENS1_6StatesIJNS2_INS3_ILj5ELj3EEENS5_IJNS1_4SCPI3EndINS7_15CommandInternalIRKS4_JNS1_5ParamIfEENS7_5BlankILj0EEZNS7_7CommandISB

which is done in libiberty
https://github.com/gcc-mirror/gcc/blob/master/libiberty/cp-demangle.c#L4315

This hits two VLAs expanding two structs of 16 bytes. However you have 1485065
entries in dpi.num_copy_templates

causing it to push the stack down (dpi.num_saved_scopes +
dpi.num_copy_templates) * 16 bytes. Which is 190129824 bytes, or 181mb and so
way over blowing your stack limit.

I tried with GCC 9 which seems to do a better job with the templates and it
works there. But I guess the real fix is to not use those VLAs in libiberty.

But I believe that's maintained by GCC if I'm not mistaken.

for now, you can work around it by increasing your ulimit.
So, not really a bug of the linker, aside from it not reporting the stackoverflow correctly?

I did see that you're running your working dir in OneDrive. I must discourage that. It has caused me strange issues before running working dirs inside cloud synced directories.
 
The following users thanked this post: thm_w

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #36 on: December 16, 2018, 02:56:02 am »
Would be great if David replied, assuming he has a forum account, if nothing else just to confirm he reads this thread.
Yes he does.  His forum name is Seppy.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #37 on: January 16, 2019, 10:19:31 pm »
 

Offline permal

  • Regular Contributor
  • *
  • Posts: 107
  • Country: se
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #38 on: January 16, 2019, 11:34:37 pm »
David,

At 2:14 in the followup, you say the std::vector has massive disadvantages - what are you basing that statement on? Any particular context? Perhaps it was just a slip of the tongue, but the vector itself is allocated on the stack, its memory buffer is however allocated from the heap so not all is kept on the stack.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: GCC Embedded Linker Issue Stops uSupply Development
« Reply #39 on: January 17, 2019, 07:59:12 am »
Looks like the right way for GNU would be to undefine CP_DYNAMIC_ARRAYS, if they are still using this in the latest version, so that it uses the heap allocation part.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf