rtems executable size issues

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

Hi,

I have been investigating the RTEMS executable size issue.  

Interestingly, I started by splitting both the RTEMS Classic API Task
Manager and the Core Thread Handler into one function per file and did not
see hardly any difference in size.  I found this surprising given that in
an application which just had a single empty init task it should not
reference hardly any task services.  Tracking this down, I have found a
MAJOR offender.  exinit.c (rtems_initialize_executive) instantiated all
the RTEMS constant data (see sptables.h).  This is cool except that
sptables.h includes _Entry_points which is a table with every directive in
the Classic API.  Fixing this one problem resulted in about 20K getting
dropped off the minimum executable size!!!

But before I realized this, I realized that the first culprit is
bspstart.c.  Almost all of the BSPs end up calling
console_reserve_resources from bspstart.c.  This ends up forcing this
path:

  bspstart.c -> console
  console -> termios
  termios -> semaphores (probably there anyway)

This happens even on applications which do not use the console.  I think
the only way to solve this is to split console_reserve_resources from
console.c.  The easiest solution is to make it a macro in an include file.
A slightly more complex way is to split it into its own file and change
the way libbsp/wrapup operates.  I think putting each of the bsp
subdirectories into its own .rel (especially startup) is forcing things to
be included.

I can make progress a few kilobytes at a time by splitting large source
files into "one routine per file" but until we figure out how to break the
BSP's sticky fingers, the worst inclusion reason is still out there.

I was investigating this on the sparc/erc32 but the other BSPs have the
same problem.  

As an aside, it looks like DEBUG_puts can pull in a lot also. :)

Comments, advice appreciated.

--joel