Dear Tom Rini, > On 09/18/12 12:25, Marek Vasut wrote: > > Dear Tom Rini, > > > >> On 09/18/12 12:19, Marek Vasut wrote: > >>> Dear Tom Rini, > >>> > >>>> On 09/18/12 11:33, Marek Vasut wrote: > >>>>> Dear Scott Wood, > >>>> > >>>> [snip] > >>>> > >>>>>> I think I got some wires crossed and was thinking about > >>>>>> printf/puts. We want those to be optimized away at > >>>>>> compile time (not pointed to a stub at link time) on an > >>>>>> SPL that has no output support, but once that's done the > >>>>>> low level serial functions shouldn't be referenced > >>>>>> anymore, right? > >>>>> > >>>>> But if you point them to stubs, that's OK. The compiler > >>>>> will GC these useless stubs anyway. But wait, we're getting > >>>>> to LTO here, right? > >>>>> > >>>>> So the safest bet really is macro in serial.h ? > >>>> > >>>> Due to the gcc bug I've mentioned before, yes. Dummy > >>>> functions will, I bet, keep the string constants around. do > >>>> {} while(0) will drop them out entirely. > >>> > >>> Damn, not much gain on m28evk (with C functionss/with macros), > >>> using gcc 4.7.1: > >>> > >>> Configuring for m28evk board... text data bss dec > >>> hex filename 418994 7780 288632 715406 aea8e ./u-boot > >>> 11773 788 12 12573 311d ./spl/u-boot-spl > >>> > >>> Configuring for m28evk board... text data bss dec > >>> hex filename 418998 7780 288628 715406 aea8e ./u-boot > >>> 11765 788 12 12565 3115 ./spl/u-boot-spl > >> > >> Right, didn't have many strings. But do you see what I mean now > >> about not needing this patch as it stands currently? > > > > No, I don't. If I remove this patch, the build breaks either > > because serial_* is defined twice or not defined at all. > > m28evk currently, needlessly, defines serial_puts/putc. I locally > patched master to drop them from arch/arm/cpu/arm926ejs/mxs/spl_boot.c > and the references in common/libcommon.o are correctly > garbage-collected. They are in fact unused functions today as they're > garbage collected without patching, see spl/u-boot-spl.map after > building.
I'd love to, this is what I get with my patchset when I remove the #ifdef from serial.c: $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- ./MAKEALL m28evk Configuring for m28evk board... make[1]: *** [/home/marex/U-Boot/u-boot-marex/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 arm-linux-gnueabi-size: './u-boot': No such file common/libcommon.o: In function `get_current': /home/marex/U-Boot/u-boot-marex/common/serial.c:229: undefined reference to `default_serial_console' make[1]: *** [/home/marex/U-Boot/u-boot-marex/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs.... So someone still has to implement default_serial_console() call. Is that fine ? > So again I say, if common/serial.o is NOT being discard in > your series on m28evk there is a bug in your series to fix or a change > to better understand and document Ok, I spent hours documenting this series. What else is there to document? Besides, my team is starting to collect dead weight and we're running behind the schedule a lot ... I'm fucked, I'm desperate and I really don't know what to do anymore. Pardon if I'm a bit unpleasant to deal with recently. > (and then see if we can change since > as Scott notes, this needs to work for 4kb boards and that is tight). What exactly are the 4k boards? One more question -- if I have two __weak functions and one non-weak, the non- weak wins and noone complains, right? Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot