[ECOS] ecosconfig - disabling printf?

Bart Veer bartv@ecoscentric.com
Mon Nov 11 16:56:00 GMT 2002


>>>>> "Scott" == Scott Dattalo <scott@dattalo.com> writes:

    Scott> On Mon, 11 Nov 2002, Andrew Lunn wrote:
    >> On Mon, Nov 11, 2002 at 07:28:53AM -0800, Scott Dattalo wrote:
    >> > Harri,
    >> > 
    >> > It's not that simple. To implement your suggestion requires that the eCos 
    >> > source be modified. The whole idea of the CDL is to configure eCos - not 
    >> > modify it. I'm fairly certain there's a way to disable printf (and 
    >> > friends) via CDL. Since posting the original query I've deleted every 
    >> > package that I could. However, I'm starting to suspect that there's a 
    >> > dependency buried in the bowels of the arm/at91 source code that is 
    >> > forcing (v)printf to be linked with my executable. If that's the case, 
    >> > then well, I'll modify the eCos source in the short term. Then when 
    >> > T[io]m's patches are committed to CVS I'll re-visit the issue.
    >> > 
    >> > Scott
    >> 
    >> The linker map may help you out here. It should be possible to find
    >> out which objects reference (v)printf. 
    >> 
    >> Never actually tried this.....

    Scott> Hi Andrew,

    Scott> Examining the source, I see the vprintf is referenced by
    Scott> many, many I/O related functions. Essentially anything that
    Scott> needs formatted strings appears to reference vprintf (this
    Scott> includes diag_printf).

This is not the best way to go about this. Amongst other issues
diag_printf() calls _vprintf(), not vprintf(), and _vprintf() only
provides a small subset of the full printf() functionality.

If you want to find out which functions are called where, use the "nm"
command appropriate to your architecture e.g. arm-elf-nm. If you use
"nm" on libtarget.a, libextras.a, and vectors.o in install/lib of your
build tree you will get full info about all functions provided and
needed by the various eCos modules.

For example, for a synthetic target build I see the following:

$ nm install/lib/libtarget.a
hal_synth_arch_synth_entry.o:
         U __CTOR_END__
         U __CTOR_LIST__
00000000 T _linux_entry
         w cyg_assert_fail
         U cyg_assert_msg
00000000 T cyg_hal_invoke_constructors
         U cyg_hal_sys_brk
         U cyg_hal_sys_exit
         U cyg_start
         U synth_hardware_init
         U synth_hardware_init2
...

So hal/synth/arch/current/src/synth_entry.c provides functions
_linux_entry and cyg_hal_invoke_constructors(), and requires
cyg_assert_msg(), cyg_hal_sys_brk(), etc.

I have not looked at all the output, but a quick glance indicates that
the network stack use sprintf(), possibly unnecessarily. Linker
garbage collection may well eliminate some or all of those uses for a
typical application. For example inet_ntop() uses sprintf(), and
in eCos inet_ntop() is used only getaddrinfo(). So if application code
uses either getaddrinfo() or inet_ntop() then that will cause
sprintf() to be pulled. It is much easier to find this sort of
information from the nm output than from the entire eCos source tree.

Bart



More information about the Ecos-discuss mailing list