rtems executable size issues

[joel at OARcorp.com (joel at OARcorp.com)]

On Tue, 18 May 1999, VALETTE Eric wrote:

> >>>>> "joel" ==   <joel at oarcorp.com> writes:
> 
> 
> joel> I have been investigating the RTEMS executable size issue.  
> 
> Working on PPC port during my *rainy* hollidays (at least someone will benefit
> of rainy wheather), I also suggest to look at the way some libraries are build:
> 
> Using ld -r to aggregate .o file and then putting the .rel in the libs leads to
> potentially load a LOT of unused code...
> 
> Maybe a make-librry should use other technic (like a find of .o files)...

Overnight, I though about this more and came to the same basic conclusion.
RTEMS itself is not THAT heavy.  The problem is that the bsp's init patch 
results in a BIG chunk of stuff getting referenced.  Since console,
malloc, termios, and newlibc are big files, there is no way to miss
grabbing ALL of it.  That in turn references a lot of RTEMS services which
until yesterday resulted in the entire manager coming in.

  bspstart
    libc_init
	malloc
	    region
	libio
	    semaphore
	newlibc
	    extensions
    console_reserve_resources
	console
	    termios
	    semaphore

Here is what I see needed to make a significant difference.  This is for
the sparc/erc32 bsp but I believe this applies to all of the BSPs.  Each
BSP could have its own problem but the structure is similar enough that
all are suffering from these.

  + I agree getting away from .rel's in the bsp will be a big step.

  + Next break up console.c into at least two parts.  For the erc32, I can
see that as a minimum console_reserve_resources, DEBUG_puts, and the
polled IO routines need to be in a separate file.  This will avoid pulling
in the entire console driver which breaks that dependency chain.  That
saves 10K minimum.

  + Divide at least malloc initialization from the run-time code.  This
file should probably just be split up entirely since it is library
routines.

  + newlibc.c is not THAT bad.  It just pulls in all of the extension manager
which has its own set of sticky fingers.   So break up the extension
manager.

  + Split initialization of termios.c from the rest.  That should at least
avoid forcing the entire thing in if you reference it.  Eventually, it
probably needs to be broken up though.

  + libmisc.  I can see that it needs to get away from .rel's and assoc
needs to be broken up. I suspect that other pieces have the same problem.  
assoc.c looks to be costing about 1K.

At first I thought about breaking up bspstart.c but have realized that it
is not really that bad.  It is the fact that every init routine it
references forces in big pieces of object code.  So I think making sure it
references routines that can be pulled in by themselves will help a lot.

Eventually I will have to attack the core and the rest of POSIX but for
now, the bigger problem is outside the executive itself.

Any major sources I may have missed?  

I have created samples/minimum so others can look at what is getting
pulled in for their BSP. I will slowly plug away at minimum size for the
sparc/erc32.  Hopefully, I can keep the list of BSP modifications to a
minimum.

--joel