Discuss here different C compiler set ups, and compiling executables for the ESP8266
User avatar
By jcmvbkbc
#57371
davydnorris wrote:So what you're saying is that the linker is pulling in all the functions already in ROM and that's why it's too big?

Yes, below is the list of objects missing in the SDK libgcc. I don't see any other differences.
Code: Select all_addsubdf3.o
_addsubsf3.o
_divdf3.o
_divdi3.o
_divsi3.o
_extendsfdf2.o
_fixdfsi.o
_fixunsdfsi.o
_fixunssfsi.o
_floatsidf.o
_floatsisf.o
_floatunsidf.o
_floatunsisf.o
_muldf3.o
_muldi3.o
_truncdfsf2.o
_udivdi3.o
_udivsi3.o
_umoddi3.o
_umodsi3.o
_umulsidi3.o


davydnorris wrote:Is there any way we can strip these out from libgcc as part of the crosstool-ng build? Or any other steps we can take so we can use the built version?

Either patch libgcc makefile (and that may be a bit challenging, as it's not a single makefile, but a bunch of fragments), or remove unneeded objects from the final archive.

davydnorris wrote:I am assuming it's better to use a libgcc built with newer gcc versions because there may be some optimisations added?

I don't think there would be noticeable differences. Definitely not for softfloat helpers, as they are written in assembly.
User avatar
By davydnorris
#57375 Thanks for the response.

jcmvbkbc wrote:
davydnorris wrote:So what you're saying is that the linker is pulling in all the functions already in ROM and that's why it's too big?

Yes, below is the list of objects missing in the SDK libgcc. I don't see any other differences.
Code: Select all.
.
.


davydnorris wrote:Is there any way we can strip these out from libgcc as part of the crosstool-ng build? Or any other steps we can take so we can use the built version?

Either patch libgcc makefile (and that may be a bit challenging, as it's not a single makefile, but a bunch of fragments), or remove unneeded objects from the final archive.


That's the same conclusion I'd come to myself - run a list of objects to remove from the final archive. The thing that seems weird is that the diff list is all the low level assembly functions that seem to have been touched in the esp crosstool build lately. The patch that touches some of these is 0003-xtensa-add-HW-FPU-sequences-for-DIV-SQRT-RECIP-RSQRT.patch - maybe there's some patches that are missing in later gcc versions?


jcmvbkbc wrote:
davydnorris wrote:I am assuming it's better to use a libgcc built with newer gcc versions because there may be some optimisations added?

I don't think there would be noticeable differences. Definitely not for softfloat helpers, as they are written in assembly.


I've run the IoT_Sample build with both the SDK and built libraries and have printed out the symbol tables - the diffs are all in those extra low level functions. They are too big to post here but I can supply if you're interested, but here's an example of what I see:
You do not have the required permissions to view the files attached to this post.
User avatar
By jcmvbkbc
#57378
davydnorris wrote:The thing that seems weird is that the diff list is all the low level assembly functions that seem to have been touched in the esp crosstool build lately. The patch that touches some of these is 0003-xtensa-add-HW-FPU-sequences-for-DIV-SQRT-RECIP-RSQRT.patch - maybe there's some patches that are missing in later gcc versions?

This patch adds implementation of said floating point helpers using hardware FPU. It is relevant for esp32 which has hardware FPU, but not for esp8266. Otherwise these functions haven't been changed for ages, so their version ROM should be the same as in the current gcc mainline.
User avatar
By davydnorris
#57383
strip_libgcc_funcs.txt
Thanks for that. Based on your feedback I threw together a script for ar that strips out the functions from the built libgcc.a

I ran it and then rebuilt and now I have no complaints about size (and no unresolved symbols). However I tried flashing the chip and I get watchdog resets with nothing useful on the debug port :-(

So I switched libraries to the SDK version.... and I get the same. So at least it's consistent. This is with the latest crosstool-ng patches applied to your repo, and building gcc5.4.0

I then dropped back to my gcc5.2.0 toolchain, built with your HEAD version and I am getting same. So at this stage I have fixed the libgcc issue, but I don't have a working build.

I've attached the ar script for everyone to use if they want. Run it by typing following:
Code: Select allexport PATH=$(TOOLCHAIN)/bin:${PATH}
cd $(TOOLCHAIN)/lib/gcc/xtensa-lx106-elf/<version>
xtensa-lx106-elf-ar -M < strip_libgcc_funcs.txt
You do not have the required permissions to view the files attached to this post.