'loopback' test size increase of +200k! (serious name clashing)

Till Straumann strauman at SLAC.Stanford.EDU
Tue Mar 18 00:21:58 UTC 2003


Hi.

Here's some magic:

'size' on the vanilla 'loopback' test yields (powerpc/shared BSP)

powerpc-rtems-size o-optimize/loopback.exe
     text	   data	    bss	    dec	    hex	filename
   309264	  11080	  23381	 343725	  53ead	o-optimize/loopback.exe

Then, I decide to do some slight modifications, i.e. I do some
string manipulation in the 'init' task and I happen to use the
newlib 'strlcpy()' function. To my great surprise,

powerpc-rtems-size o-optimize/loopback.exe
     text	   data	    bss	    dec	    hex	filename
   502237	  19260	  51777	 573274	  8bf5a	o-optimize/loopback.exe

the executable grew by more than 200k or ~70%!!

The reason for this is the poorly packaged 'ppp' package.
It implements a couple of C-library routines (and enhancements)
and puts those 'helpers' into the same files with other ppp
code. This eventually triggers an avalanche of library dependencies.

The moral:

A) PLEASE keep add-on stuff like www, ppp, dosfs, etc. in SEPARATE
     libraries.
     Merging everything into one giant librtemsbsp.a is IMHO not a good
     idea - librtemscpu/librtemsbsp should only contain the core packages
     without bloat.
     My personal impression is that there are quite some differences in
     quality and style between the RTEMS core proper and some of the
     add-ons and/or BSPs.
     If I don't use ppp or the webserver or ftp or networking or libblock,
     I don't want to have to debug linker problems with any of those
     components. If a piece from a library is missing, it's much easier
     to figure out what library to add than figuring out what triggers
     linking of unwanted parts of one huge library.

B) FIX the ppp (and possibly other) packages.
      o the ppp package defines (global) names prone to clashing like
       'lock', 'line', 'magic', 'debug', 'modem', just to name a few.

        SUCH NAMES DONT BELONG INTO librtemsbsp.a !!!!

      o eliminate reimplementation of newlib stuff. If it is absolutely
        necessary to provide a reimplementation, put each routine in
        a separate file and use weak alias magic so the reimplementation
        is only used if 'newlib' doesn't provide it already.

My (way too long) 2 cents, as always...

-- Till.





More information about the users mailing list