This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ecosconfig - disabling printf?
>>>>> "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