ESP8266 Community Forum

- Sat Oct 29, 2016 8:09 pm #57371

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

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.

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.

- Sun Oct 30, 2016 2:52 am #57375 Thanks for the response.

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.
.
.


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?

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.

- Sun Oct 30, 2016 3:28 am #57378

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.

- Sun Oct 30, 2016 7:37 am #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.