ESP8266 Community Forum

- Mon Nov 10, 2014 5:46 pm #2452 Hi guys.
I've pushed gcc and crosstool-NG updates: a couple of bugs fixed, setjmp/longjmp, varargs and nested functions are now working.
Please update your toolchains.
If you used crosstool-NG you should be able to do it like that:

Code: Select all$ cd /opt/Espressif/crosstool-NG
$ git pull
$ rm -rf .build/src
$ ./ct-ng build

- Thu Nov 13, 2014 1:59 pm #2567 Just one little question about the toolchain.
So far the firmware is made of a bunch of .a blobs + user appcode. The .a libs are linked in one single link group, e.g. -Wl,--start-group -lmain -lc ... -Wl,--end-group.
There are 2 ways to link the app:

• Link all blobs in one group, your .o files afterwards.
• Combine your code in an ar library and link in the same group as the others

However both ways have a few pitfalls. The first variant that looked natural to me, however it results in some functions from libc, like skip_atoi, atoi, sprintf being undefined at linktime. My guess - they were in irom0.text and only those referenced by code in .text whiting the group were pulled out of the blobs by the linker (still trying to figure that out)

The latter one is how they do in SDK. However it has a more obscure pitfall I've triggered. For my frankenstein firmware, I use a special hack to include all console commands from different files by placing them in a section .console_cmd and if I link my usercode to a library - ld just drops them, along with all the code that implements these commands. KEEP(), __attribute__((used)) do not help much here. __attribute__((constructor)) don't work either anyway.

Any idea how to make this work?

Blog|github

- Thu Nov 13, 2014 2:27 pm #2568

Just one little question about the toolchain.
So far the firmware is made of a bunch of .a blobs + user appcode. The .a libs are linked in one single link group, e.g. -Wl,--start-group -lmain -lc ... -Wl,--end-group.
There are 2 ways to link the app:

• Link all blobs in one group, your .o files afterwards.
• Combine your code in an ar library and link in the same group as the others

However both ways have a few pitfalls. The first variant that looked natural to me, however it results in some functions from libc, like skip_atoi, atoi, sprintf being undefined at linktime. My guess - they were in irom0.text and only those referenced by code in .text whiting the group were pulled out of the blobs by the linker (still trying to figure that out)

Normally .o files should go before libs, because the linker does search for undefined symbols only in libs mentioned after the objects that introduced these symbols.

The latter one is how they do in SDK. However it has a more obscure pitfall I've triggered. For my frankenstein firmware, I use a special hack to include all console commands from different files by placing them in a section .console_cmd and if I link my usercode to a library - ld just drops them, along with all the code that implements these commands. KEEP(), __attribute__((used)) do not help much here. __attribute__((constructor)) don't work either anyway.

Any idea how to make this work?

Attribute used should only be used for objects not referenced explicitly, but still used. Attribute constructor puts a pointer to a function to a special section, that crt may iterate over during startup, calling functions one by one, so it's irrelevant too.
I guess you need either to put these functions back to normal .text section, or to take a look at your linker script and mention relevant sections names in relevant places.
I can take a look if you have the complete code available somewhere.

- Thu Nov 13, 2014 3:10 pm #2570

Normally .o files should go before libs, because the linker does search for undefined symbols only in libs mentioned after the objects that introduced these symbols.

Ooops. Somehow I've missed that one. Specifying libraries after the .o files fixed everything for me so far. Thanks a ton! So don't bother looking at the codebase. It's up on my github here and here, but it's hacky as hell.

Blog|github