ESP8266 Community Forum

- Fri Apr 30, 2021 4:54 am #91281

Not sure if things have changed but using the esp-open-sdk build I got a large increase in code and stack usage, and tracked it down to the compiler using software versions of the low and higher level functions instead of the ROM based versions. There appeared to be a whole bunch of them left out of the explicit definitions in the linker. Things may have changed now though

I have collected all (known) functions in ROM and added them to the linker file (if not yet there from Espressif). Also my images are already very large (just under 500 k), so for me it's less important, only if it's in IRAM context. Thanks for the tip though and I will check this.

Indeed it appears gnu ld simply links in the libc versions, even though PROVIDEs are present. A bit disappointing. I did strip the libc.a from ROM-provided functions and it saved me 320 bytes in flash (on a total of 592 k) and 0 on IRAM, so for me it's not worth the while. Others may feel differently, they'll have to do the strip themselves, I don't know of a hook in ct-ng where to automate it.

About libgcc, I don't feel confident we should do this. The versions in ROM are for gcc 3 or 4, as we're on 10 now, I think they're at least a bit outdated.

- Fri Apr 30, 2021 8:11 pm #91288

Just had a look at your repo and the local patches dir - how are you getting the local patches for gcc 10 to be applied or don't you need them any more?

No, apparently no patches are required for gcc 10. The gcc 9 which I have been using for some time now, sourced from your repository, also did not have any patches for it, only older versions of gcc. It seems that Max Fillipov (aka jcmvbkbc) has managed to get the required patches for xtensa into gcc upstream. The rest what's specific for lx106 is handled by the "traits" include files from the overlay which have been the same for ages.

I found I had to copy the directory and rename it to the version of newlib/compiler for the patches to be found and applied - perhaps that's not needed any more?

I think so? I couldn't find any patches for gcc 9 either, which I've been using for some time now. But maybe I am missing something here and something should be corrected someway...

If this is the case then that is awesome - will make maintaining the ct repo so much simpler

- Fri Apr 30, 2021 8:19 pm #91289

Not sure if things have changed but using the esp-open-sdk build I got a large increase in code and stack usage, and tracked it down to the compiler using software versions of the low and higher level functions instead of the ROM based versions. There appeared to be a whole bunch of them left out of the explicit definitions in the linker. Things may have changed now though

I have collected all (known) functions in ROM and added them to the linker file (if not yet there from Espressif). Also my images are already very large (just under 500 k), so for me it's less important, only if it's in IRAM context. Thanks for the tip though and I will check this.

Indeed it appears gnu ld simply links in the libc versions, even though PROVIDEs are present. A bit disappointing. I did strip the libc.a from ROM-provided functions and it saved me 320 bytes in flash (on a total of 592 k) and 0 on IRAM, so for me it's not worth the while. Others may feel differently, they'll have to do the strip themselves, I don't know of a hook in ct-ng where to automate it.

About libgcc, I don't feel confident we should do this. The versions in ROM are for gcc 3 or 4, as we're on 10 now, I think they're at least a bit outdated.

There isn't a hook to do it unfortunately - I would assume the correct approach would be a config file that excluded them at build time. I put the stripping into my overall makefile for esp-open-sdk - it's in the zip I gave you if you want to see.

Regarding the libgcc functions - if you look at them, they are some of the most basic functions around and I would be very surprised if they have changed at all since K&R wrote the language. The thing that I am most concerned about is that the ROM based versions will know about the word alignment needs. I actually seem to remember that I had some crashes in my code and that was what led me to realise the gcclib versions were being used

- Sat May 01, 2021 4:40 am #91291 Yes newlib does know about alignment and it will work. Just don't use the generic string functions for copying bytes from flash (words is possible but only aligned). I made a function for that myself and then there is no problem. It does it pretty fast too, so I can really recommend to move all strings in the program from dram (default) to flash.