Re: [ECOS] ecosconfig - disabling printf?

[Gary Thomas <gthomas at ecoscentric dot com>]

On Mon, 2002-11-11 at 16:00, Bart Veer wrote:
> >>>>> "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.
>

This is indeed the way to analyze the issue.  By my reckoning, 
I don't see that getting rid of 'printf()' and friends is going
to have that big a savings anyway.

BTW - I fixed the dependency on sprintf() in the new stack - it
only uses the diag_XXX forms which are much smaller and will [most]
always be present.

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss