Replacing or disabling "printf" calls

[Steven Grunza]

>From: rtems-users-bounces at rtems.org
[mailto:rtems-users-bounces at rtems.org] On Behalf Of Joel Sherrill
>Sent: Monday, October 17, 2011 11:37 AM
>To: rtems-users at rtems.org
>Subject: Re: Replacing or disabling "printf" calls
>
>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.
>--joel
>> Ralf

A method I have used in the past is to substitute a simple printf()
function that simply returns.  If there are sprintf() function calls
then it's a different story.  The function will be found in your
project's object files and the library won't be referenced.  I would
advise checking the assembly output and linker map files to make sure
you're getting what you expect.

Keep in mind that the simple printf() will execute much faster and
without a lot of stack operations so previously undetected timing race
conditions can rear their ugly head(s).