Greetings,
I've been absent for a while and couldn't find a way to search the list
archives so I apologize if this has already been discussed…
I've been fighting the SPL binary growing too large on OMAP4 (using custom
configs and features). It's annoying that too large just fails to run with no
build or runtime notice. But that's a different issue.
My main issue is that in looking through the map for SPL I've repeatedly found
code that I don't need and have a pretty good handle on that. My issue is that
code that is compiled but eliminated because it's not called leaves behind all
of its anonymous strings ("like this"). In my latest build I have the following
sections that are all anonymous strings:
0x4030b638 0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o
0x4030b8b5 0x19 arch/arm/cpu/armv7/omap4/libomap4.o
0x4030b9ad 0xbe common/spl/libspl.o
0x4030ba6b 0x57 drivers/gpio/libgpio.o
0x4030bac2 0x44c drivers/i2c/libi2c.o
0x4030bf0e 0x302 drivers/mmc/libmmc.o
0x4030c27e 0x15 drivers/serial/libserial.o
0x4030c293 0x145 drivers/spi/libspi.o
0x4030c4d8 0x53 lib/libgeneric.o
with more than half being unreferenced. This is a big deal when you only have
about 25K of SRAM for code and data.
In searching the web it seems that dead code and data are removed using
--gc-sections, -ffunction-sections and -fdata-sections which u-boot is using
correctly.
But it seems that gcc puts all anonymous strings into the same section (.rodata
or .rodata.str1.1 if string merging is on) which prevents them from
participating in the stripping process.
Interestingly, it puts its own __func__ strings into separate sections and they
are eliminated if the function go away. It just doesn't do this for plain ""
strings. Grrr.
I was shocked to find gcc posts asking about this more than 13 years ago with
barely any traction at all. Given that embarrassing history I'm not hopefully
that the gcc folks will ever address this.
Is there a work around I haven't thought of? I'm thinking along the lines of
disabling all printfs in SPL in the hope that will take the strings away (since
many are some sort of debug / progress message).
Any thoughts or guidance would be appreciated.
-Mike
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
