- Thu Apr 29, 2021 7:22 pm
#91272
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
eriksl wrote:Oh and one last thing - you will need to have a look at my instructions and strip the symbols defined in ROM from both libgcc and libc, otherwise the compiler will use the library based ones
export PATH=$(TOOLCHAIN)/bin:${PATH}
cd $(TOOLCHAIN)/lib/gcc/xtensa-lx106-elf/<version>
xtensa-lx106-elf-ar -M < strip_libc_funcs.txt
xtensa-lx106-elf-ar -M < strip_libgcc_funcs.txt
I actually never have done this. I assume it will save some disk space, but I don't think it's a requirement for succesful operation.
I think these lines in my load script already force the linker to use the rom based versions. I assume everybody does it, as it's also in the Espressif "eagle" linker scripts (included).Code: Select all...
PROVIDE ( ets_memcpy = 0x400018b4 );
PROVIDE ( memcpy = 0x4000df48 );
...
Also gcc will mostly not even generate a call for memcpy (and some similar) functions, because it inserts small replacement code by itself (unless you specifically turn off that feature).
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
