RTEMS size

Joel Sherrill joel.sherrill at OARcorp.com
Wed Oct 30 14:05:30 UTC 2002

John Alexandersson wrote:
> Hi everyone,
> I'm a little bit confused about the minimum size of an
> RTEMS-application (RTEMS-4.5.0, erc32 BSP).
> I've created a null-program with no managers and recompiled RTEMS with
> -O2. The size of such a program is 58kb. No console is used.
> In the RTEMS manual a minimum size of 22kb is mentioned, so I am
> probably missing something here...

If that is where I think it is, that number reflects the executive
code space.  So it is just the size of the object modules that
constitute the executive proper without supporting functionality.
Plus even that number varies by CPU family a LOT.

There are a number of other things that go into making
a full executable:

  + crt0.o
  + BSP initialization
  + BSP interrupt processing complexity
  + BSP shutdown
  + libc reentrancy support
  + malloc support
  + maybe the clock driver.

I have seen many BSPs that accidentally reference technically
unneeded code during the initialization path.  Some used
to call a support routine in the console driver so you ended 
up linking in the console driver all the time.

ALso look at the --enable-options you used.  Did you disable
POSIX and ITRON?  Each pushes some size into the minimum.

Fighting to keep the smallest size possible for linked programs
is an ongoing battle and depends a lot on each BSP being careful.
All it takes is an added call to a subroutine or a variable reference
in the minimum path to force the inclusion of a lot of code.

Also it is easy to leave a printf in for debug purposes and
suddenly see the executable size explode.

> So, how do I create this 22kb program that is mentioned in the manual?

The first step is to look at the symbol table for your NULL program
and see what is there.   Use the -Map option to ld to see why things
were pulled in.  Sometimes it is just a matter of tweaking the
things to avoid linking in code that is unneeded in the minimum path.

A few years ago, we did an internal review showing that what I call
"micro-feature configuration" could reduce code size very far.
For example, you might not want any signal support or priority
ceiling protocol.  Leaving the code and data out for that feature
has a code/data size reduction.

If you find some function that you don't expect to be in your minimum,
ask.  This is one of those areas that just periodically needs attention
and housekeeping.

But the bottom line is that just like VxWorks lists the size of objects
in the libraries without considering how many of those pieces it
takes to produce a working system, the size of an RTEMS executable is
about the same situation.  Routine size is one thing, executable
size is another battle entirely which is a constant.

Please look at the size and see if you notice functionality in the
symbol table that you don't need in your NULL program.  But remember
your NULL program still has initialized a board, could shut it down
cleanly, and has a taking environment and reentrant C library at its
disposal.  Those are what is feeding the minimum size.

> /John
> -----------------------------------------------------------------
> John Alexandersson
> Software Engineer
> Saab Ericsson Space AB
> SE-405 15 Göteborg
> Sweden                         /"\
>                                \ /    ASCII Ribbon Campaign
> Phone: +46-31-735 42 86         X   against HTML email & vCards
> Fax:   +46-31-735 40 00        / \    Keep Email as ASCII
> -----------------------------------------------------------------

Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

More information about the users mailing list