newlib config for lx106/esp8266 is too bloated

[pfalcon]

[migrated from https://github.com/jcmvbkbc/newlib-xtensa/issues/1]

Trying to compile Espressif "AT" firmware with a toolchain built with https://github.com/jcmvbkbc/crosstool-NG and this newlib, I get error:

/mnt/hdd/projects-3rdparty/xtensa/esp-open-sdk/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: at section `.text' will not fit in region `iram1_0_seg'
/mnt/hdd/projects-3rdparty/xtensa/esp-open-sdk/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: region `iram1_0_seg' overflowed by 6708 bytes
collect2: error: ld returned 1 exit status

That's because libc code goes into .text segment, which in turn goes into "iram" on ESP8266 which is just 32K, and newlib config appears too bloated for such device.

Can you please look into slimming it down?

[pfalcon]

jcmvbkbc commented 11 hours ago This has nothing to do with newlib per se. If you need your text to get to a certain output section in the final binary edit your linker script accordingly. Ok, and the question is not even about newlib, but about its config used in lx106-g++ crosstool-ng. Oh well. I don't use libc myself, but surely I can review/apply your patches to the config.

[pfalcon]

This has nothing to do with newlib per se.

Yes, more with how you configure it for crosstool-NG, but as it lacked a bugtracker, here we go.

If you need your text to get to a certain output section

Who said I need that? I wrote "Can you please look into slimming it [newlib] down?"

Here're are few links for reference:

• http://community.arm.com/groups/embedded/blog/2013/01/21/shrink-your-mcu-code-size-with-gcc-arm-embedded-47
• https://github.com/32bitmicro/newlib-nano-1.0
• grep for "nano" in http://sourceware.org/newlib/README (and other switches)
• grep for "nano" in https://launchpad.net/gcc-arm-embedded/+milestone/4.7-2012-q4-major

I don't have any patches, sorry, I assume you know that stuff better than me. I just hope that I can take well-maintained parts from community, spend several days (!) on integration testing that it all fits together, and then report issues back to upstreams, with the hope that they won't be closed right away ;-).

[pfalcon]

nekromant commented 4 hours ago There are 2 hacks that can be done here:

The simplest part would be optimize libc for size (-Os) That's there in ct-ng menuconfig. That will be quite a win in terms of size already.

Alternative:

$(OBJCOPY) --rename-section .text=.irom0.text
--rename-section .literal=.irom0.literal libc.a Or the LD script. Section renaming seems to work just fine, but some functions will be way slower when placed in ICACHE_FLASH. I'm still experimenting with newlib and don't seem to be able to use anything like sprintf that complains about _sbrk_r. I used to fix stuff like that for STM32 by recompiling newlib disabling builtin syscalls and providing my own stubs, but ARM and XTENSA seem to be quite different here.

[pfalcon]

jcmvbkbc commented 25 minutes ago Who said I need that? I wrote "Can you please look into slimming it [newlib] down?" Moving sections to FLASH from IRAM is one of the common ways of fixing the build error you've reported.

For further discussion please report this issue to the correct repository.

[pfalcon]

Moving sections to FLASH from IRAM is one of the common ways of fixing the build error you've reported.

So, to clarify, that's not what I meant - it's not good idea to move entire libc (with things like strlen() and memcpy()) to flash for slower access, and doing it function by function basis is too cumbersome. The talk is exactly about tweking configure parameters, maybe applying some unobtrusive patches, to achieve smaller code footprint with typical embedded libc usage (i.e. usually handful of libc functions used, like string operations).