jcmvbkbc/newlib-xtensa

newlib config for lx106/esp8266 is too bloated

pfalcon opened this issue · 10 comments

pfalcon commented

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?

jcmvbkbc commented

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 commented

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:

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

nekromant commented

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.

jcmvbkbc commented

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 commented

Gotta love open-source bureaucracy, but here we go:
jcmvbkbc/crosstool-NG#2

aplikatika commented

Hi guys,

I am in a mission to run Javascript on Esp8266.

I struggled a lot and I managed to compile the Espruino with Xtensa, now all goes well, but I stuck with this linker segmentation overflow "section .text' will not fit in regioniram1_0_seg'"

0x00000.bin 195kb
0x40000.bin 144kb

Is there any guru who would like to help me solving this?

Espruino: https://github.com/espruino

nekromant commented

@aplikatika Just try and link with -lcirom instead of -lc. It's a version of libc that's fully in irom, not iram.

aplikatika commented

Thank you @nekromant very much! It actually didn't change anything but I got a clue for what I need to achieve here...

I would like to keep libc in iram for faster execution, a "hello world" build is using 28kb of iram, that is giving me 6kb free iram. I need to move most of JS stuff into irom.

This can be done by attributing all functions with ICACHE_FLASH_ATTR, but this is not good solution since there are so many functions and I am sure that guys from Espruino would not accept that.

Better way I suppose is to master the eagle.app.v6.ld linker script. I moved *(.literal .text) into .irom0.text section, so all major libraries went into irom. Performance-wise this is also not good. If there is a way to specify exactly which .o files go to which section, that will be perfect!

scargill commented

Can someone guide a non-Linux non-Makefile whiz through this - happy to tinker with he eagle.app.v6 linker script - but how did you move the .text stuff into irom0.text? I'm up to 7c20 in .text - and this will soon seriously jeardise my expansion capability (programming in C on PC). I already have just about all routines - except those that need to be REALLY fast and they're small) to ICACHE_FLASH_ATTR

Some simply info possible?

huppyuy commented

@aplikatika Did you solve your problem? And How? Thanks!!!