espressif / ESP8266_NONOS_SDK

ESP8266 nonOS SDK
Other
923 stars 535 forks source link

Compile binary bits with -ffunc-sections #13

Open rojer opened 7 years ago

rojer commented 7 years ago

Binary libraries should be compiled with -ffunc-sections so that they can be efficiently pruned with --gc-sections. We can enable -ffunc-sections on our code, but for the binary libs we need Espressif to do it.

wujiangang commented 7 years ago

@rojer we've compiled some libs use -ffunction-sections -fdata-sections, in commit b8fd588a33f0319dc135523b51655e97b483b205, also update the ld, please have a try.

rojer commented 7 years ago

great, thank you!

kriegste commented 7 years ago

Thanks. That saves us more than 8kB.

rojer commented 7 years ago

@wujiangang i got to try this today and ran into the following issue: you said libmain will come next, but actually, some parts of it are already affected, e.g. spi_flash.o:

$ xtensa-lx106-elf-objdump -t libmain.a
0000000c g     F .text.Cache_Read_Disable_2     0000003b Cache_Read_Disable_2
0000000c g     F .text.Cache_Read_Enable_2      0000002a Cache_Read_Enable_2

looks like internally they are not marked to be placed in IRAM, so they were placed into IROM and it ended badly :) (i use custom linker script)

so, i'm awaiting libpp, libmain anf the rest. but functions for iram should be placed into their own section, otherwise it becomes difficult to know what should go where.

kriegste commented 7 years ago

After thorough testing all is still fine here.

rojer commented 7 years ago

yes, other than that small issue (which wouldn't even be an issue if not for my custom linker script), everything is fine.

rojer commented 7 years ago

so, the new flash writing functions use new cache enable/disable methods. this breaks things in certain flash layouts, in particular when rBoot's "big flash" configuration is used, where Cache_Read_Enable_New is overridden to take into account location of the current rom in flash, andmake corrections if it's above 0x100000.

@wujiangang can you calrify what makes Cache_Read_Enable_2 different from Cache_Read_Enable_New? why was it necessary?

jmattsson commented 6 years ago

@rojer If I'm reading these two functions correctly, they're intended to only toggle the flash cache on/off without touching the actual page setup of the mapping. So, once you've run Cache_Read_Enable_New() to establish which flash area is to be mapped, you can use the ..._2() functions to toggle that without worrying about (re)mapping the wrong area. As such, there should be no need to touch these functions. Without having actual register descriptions available I can't be a 100% sure of course, but it's what it looks like.

Having Cache_Read_Enable_New() flagged as weak in libmain.a by default would of course be helpful.