Re: [ECOS] ecosconfig - disabling printf?

Re: [ECOS] ecosconfig - disabling printf?

[harri.siirtola]

Sorry for the confusion. I didn't realize you wanted to remove printing 
from the whole ecos. As you must rebuild ecos anyway after config change, 
how about defining -Dprintf and -Dvprintf in the "Global build options" 
("Global compiler flags)?

	Harri


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

[ECOS]question about the performance under redboot

[peter_ku]

Hi,

1. If I use red-boot to download my code, and let it free run.

2. If I use build a standalone application and put it in the flash, copy itself to RAM , run from RAM.

the performance of condition 2 is faster than condition 1 , or equal? does red-boot effect the perfomance?


Peter

Re: [ECOS]question about the performance under redboot

[Gary Thomas]

On Tue, 2002-11-12 at 02:16, peter_ku wrote:
> 
> Hi,
> 
> 1. If I use red-boot to download my code, and let it free run.
> 
> 2. If I use build a standalone application and put it in the flash, copy itself to RAM , run from RAM.
> 
> the performance of condition 2 is faster than condition 1 , or equal? does red-boot effect the perfomance?

Both scenarios should be the same [performance].

-- 
------------------------------------------------------------
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

Re: [ECOS] ecosconfig - disabling printf?

[Gary Thomas]

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

Re: [ECOS] ecosconfig - disabling printf?

[Scott Dattalo]

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.....

Hi Andrew,

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

By methodically removing packages, I've boiled my configuration down to:

cdl_configuration eCos {
    description "" ;

    # These fields should not be modified.
    hardware    at91 ;
    template    default ;
    package -hardware CYGPKG_HAL_ARM current ;
    package -hardware CYGPKG_DEVS_FLASH_AT91 current ;
    package -template CYGPKG_KERNEL current ;
    package -template CYGPKG_MEMALLOC current ;
    package CYGPKG_HAL_ARM_AT91 current ;
    package CYGPKG_HAL current ;
    package CYGPKG_INFRA current ;
};


I simplified my application somewhat. If you don't mind, I'll list my 
total appication right here:

void cyg_user_start(void)
{

}


I probably should comment my code, don't you think?

Even with this extremely minimally contrived system, vprintf still appears 
in the executable. Which package you reckon I ought'a delete next? 

At this point, it appears the only way to delete the vprintf code is by 
diving into the eCos source and #define'ing it out. 

Scott

Re: [ECOS] ecosconfig - disabling printf?

[Bart Veer]

>>>>> "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

Re: [ECOS] ecosconfig - disabling printf?

[Andrew Lunn]

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.....

      Andrew

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

Re: [ECOS] ecosconfig - disabling printf?

[Scott Dattalo]

On Mon, 11 Nov 2002 harri.siirtola@vtt.fi wrote:

> Scott wrote:
> --------------------------------------------
> I'm at a point now in my project where I'd like to disable some of the
> ecos components so that I can reduce the memory footprint. One option in
> particular I'd like to remove is printf -- However, it's not clear which
> option (or set of options) that I must change to disable printf. For
> example, I tried to remove several packages:...

<snip>
> -------------------------------

On Mon, 11 Nov 2002 harri.siirtola@vtt.fi wrote:

> 
> Scott, how about using some #defines for disabling it? I've been using
> 
> #if NO_PRINTF
> #define printf
> #define vprintf
> // Other versions of printf if needed
> #endif
> 
> This way the compiler won't generate calls to printing functions and the 
> linker won't include the code into your executable. And you don't have to 
> have separate configurations for the cases.

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


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

Re: [ECOS] ecosconfig - disabling printf?

[harri.siirtola]

Scott wrote:
--------------------------------------------
I'm at a point now in my project where I'd like to disable some of the
ecos components so that I can reduce the memory footprint. One option in
particular I'd like to remove is printf -- However, it's not clear which
option (or set of options) that I must change to disable printf. For
example, I tried to remove several packages:...

ecosconfig remove libc_stdio

ecosconfig remove libc

If there's a printf in my application, I get the expected "implicit
declaration blah blah error". That's good, however

arm-elf-objdump -D MyApp | grep print

(MyApp is the executable for my application)

indicates that "vprintf" is still being used.


Which package(s)/option(s) do I need to inhibit to remove dependencies on
vprintf?

Scott
-------------------------------

Scott, how about using some #defines for disabling it? I've been using

#if NO_PRINTF
#define printf
#define vprintf
// Other versions of printf if needed
#endif

This way the compiler won't generate calls to printing functions and the 
linker won't include the code into your executable. And you don't have to 
have separate configurations for the cases.

	Harri


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

[ECOS] ecosconfig - disabling printf?

[Scott Dattalo]

I'm at a point now in my project where I'd like to disable some of the 
ecos components so that I can reduce the memory footprint. One option in 
particular I'd like to remove is printf -- However, it's not clear which 
option (or set of options) that I must change to disable printf. For 
example, I tried to remove several packages:

ecosconfig remove libc_stdio

ecosconfig remove libc

If there's a printf in my application, I get the expected "implicit 
declaration blah blah error". That's good, however

arm-elf-objdump -D MyApp | grep print

(MyApp is the executable for my application)

indicates that "vprintf" is still being used. 


Which package(s)/option(s) do I need to inhibit to remove dependencies on 
vprintf? 

Scott


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