Hi
cc: Mailing List
On 07/11/2013 07:33 PM, Michael Trimarchi wrote:
> Hi Michael
>
> On 07/11/2013 07:01 PM, Michael Cashwell wrote:
>> 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.
>>
>
> I don't give an answer but some suggestions:
>
> - using a raw partition to boot and remove the vfat support in first stage
> boot
> - safety you can add 2Kb more to CONFIG_SPL_MAX_SIZE (tested on serial boot
> too)
> - do some tests on different toolchains
>
> Try to move all in the second stage when it's possible
>
> Michael
>
Michael
>> 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
>>
>
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
