On Thu, Aug 09, 2012 at 10:37:43AM -0700, Tyler Olmstead wrote:
Hi Tom,
On Thu, Aug 9, 2012 at 7:35 AM, Tom Rini trini@ti.com wrote:
On 08/08/2012 07:24 PM, Tyler Olmstead wrote:
Remove linker command line options from the SPL makefile that force the inclusion of unreferenced command code from linked object files. As commands are not used in the SPL, these options resulted in an unnecessary increase in the image size, in addition to introducing the possibility of tricky link errors in the case where the command code contained symbols that were not resolved by linking in the limited objects compiled in the SPL build.
Signed-off-by: Tyler Olmstead tyler.j.olmstead@gmail.com
Without either figuring out how to make the strings be garbage collected automatically (I'm talking with a toolchain friend of mine about how to try and do this) or whacking U_BOOT_CMD to do this for us, we will start adding bloat to SPL after we do this.
I absolutely agree that bloat in the SPL should be avoided wherever possible, but I don't understand how this patch would increase the image size by *not* forcing commands to be linked in. There are numerous examples where the linker is relied upon to not include unused code into SPL. Is there something unique about U_BOOT_CMD that makes it especially troublesome?
It doesn't bloat today, true. It bloats as soon as someone else adds in code that links in a new U_BOOT_CMD that wasn't guarded as now the string literals that before would have been guarded and not linked in will now be un-guarded and not garbage collected (while the command will be). The linker is in fact getting this wrong already in a number of cases (run a 'strings' on an SPL binary) and this needs to be fixed too. I don't want to make the problem potentially worse until we have a fix for the general problem.
To see what I mean, build omap3_beagle with this patch and then un-guard nandecc in arch/arm/cpu/armv7/omap3/board.c. The command will be collected but the command/help string will be in the binary.