Replacing or disabling "printf" calls

Rafael Morales rmorales at
Fri Oct 21 09:58:12 UTC 2011

First of all, thank to everybody for your answers.

Below are our conclusions.

0) "mil-std-1553B driver"  /rtems-4.10/src/rtems-4.10/c/src/lib/libbsp/sparc/shared/1553/b1553rt.c)
Not use any printf flavor.

1) "spacewire driver"  /rtems-4.10/src/rtems-4.10/c/src/lib/libbsp/sparc/shared/spw
This the Gaisler's RTEMS 4.10 driver.

In this driver there are printfs in the function "grspw_print_dev"

  .text          0x400105a4     0x2224
                 0x400106b4                grspw_print_dev
                 0x4001075c                grspw_print
                 0x400109e4                grspw_device_init
                 0x40010cec                grspw_register_io
                 0x40012660                grspw_init3
                 0x40012770                grspw_init2
                 0x400127b0                grspw_register_drv

The are more print's but encapsulated with #if...#def

In adittion, we have eliminate all printf() calls in our main program and source drivers and
we're sure they're never called, but the problem persists.

2) We have tested several very simple samples (/opt/rtems-4.10/src/rtems-4.10/testsuits/samples/minimum/init.c) without using any
printf() calls or extra drivers. In that sample, the library  "lib_a-svfprintf.o" does not appear in the map.

Using the configuration options indicated in:
and removing the option:


The library  "lib_a-svfprintf.o" is present in the map.

It seems that the source of "printfs" flavors are related with the use of a file system, indepently if they appear in the main source code or in driver source code.

What is the relationship between the file system and the lib_a-svfprintf.o?

Best regards.

On 10/17/2011 7:31 AM, Ralf Corsepius wrote:

> On 10/17/2011 02:12 PM, Rafael Morales wrote:
>> Hello everyone,
>> We are working in a space project using RTEMS and we are worried about
>> program sizes.
>> Reviewing the map file of a sample program using MIL-STD-1553B and
>> spacewire driver, we have found :
>> 9460 bytes used by lib_a-vfprinft.o
>> 9192 bytes used by lib_a-svfprintf.o
>> Almost 18KB for printing it a lot!
> This actually is very little!
When you are on a PC with GBs of memory, it is.  This is on
a CPU with limited resources -- a space hardened CPU where
memory is expensive.  Someone told me that adding another
RAM module to their board would be USD100K.

The other factor is that it is common to review every line of code
that will be on the target hardware.  If printf() can be eliminated,
this is a significant body of code to review.
>> We are not using "printf" in main program, but we have found it in the
>> source file of MIL-STD-1553B and spacewire driver.
>> Those drivers was originally compiled with RTEMS and are linked with the
>> main program in any compilation.
> Are these source files part of the RTEMS source tree?
> If yes, which files are you referring to?
> If no, ... c.f. below.
This is an important point
>> Can any one help us to replace or disable that "printf" calls?
> The only option to get rid of printf is to replace all references to it
> from all code you are using.
If it is in a driver, it is almost certainly debug or status code and 
probably should be
printk().  But without seeing the code, I don't know.
> In most cases, this is hardly possible without fundamentally breaking
> the code.
Not if it is just debug.

More information about the users mailing list