This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ecosconfig - disabling printf?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]