On May 11, 2018 5:49:44 PM GMT+02:00, Freddie Chopin <freddie_cho...@op.pl> wrote: >On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote: >> For the Cortex-M devices (and probably many other RISC targets), >> -fdata-sections comes at a big cost - it effectively blocks >> -fsection-anchors and makes access to file-static data a lot bigger. >> People often use -fdata-sections and -ffunction-sections along with >> -Wl,--gc-sections with the aim of removing unused code and data (and >> thus saving space, useful on small devices) - I would expect LTO >> would >> manage that anyway. The other purpose of these is to improve >> locality >> of reference - again LTO should do that for you. But even without >> LTO, >> I find the cost of -fdata-sections high compared to -fsection- >> anchors. > >Unfortunatelly having LTO doesn't make -ffunction-sections + -fdata- >sections + --gc-sections useless. > >My test project compiled: >- without LTO and without these attributes - 150824 B ROM + 4240 B RAM >- with LTO and without these attributes - 133812 B ROM + 4208 B RAM >- without LTO and with these attributes - 124456 B ROM + 3484 B RAM >- with LTO and with these attributes - 120280 B ROM + 3680 B RAM > >As you see these attributes give much more than LTO in terms of size. > >As for the -fsection-anchors I guess this has no use for non-PIC code >for arm-none-eabi. Whether I use it or not, the sizes are identical.
That's an interesting result. Do you have any non-LTO objects? Basically I'm curious what ld eliminates that gcc with LTO doesn't. As to a workaround for the ld bug you can try keeping all .debug_* sections. IIRC 2.30 has the bug fixed (on the branch). Richard. >Regards, >FCh
