Re: [ECOS] A problem about constructor sequence

[Andrew Lunn <andrew at lunn dot ch>]

On Mon, Sep 10, 2007 at 05:14:13PM +0800, taiyun@sunnorth.com.cn wrote:
> 
> Dear all:
> 
> I want to discuss something about eCos kernel, BUT I am not sure whether my
> opinion is correct or someone has reported this problem before.
> I think there is a problem with global constructor sequence. There are two
> global instances, not only they have the same initialized priority but also
> they have some relationship between each other. They are:
> 
> Cyg_Thread cyg_libc_main_thread CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_LIBC) = ...
> AND
> static cyg_libc_startup_dummy_constructor_class cyg_libc_startup_obj
>                                   CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_LIBC);
> 
> constructor of instance cyg_libc_startup_obj will call a function named
> cyg_iso_c_start, and cyg_iso_c_start function will call
> cyg_libc_main_thread.resume(). NOTE: cyg_libc_main_thread is the fisrt
> instance I referred to.
> 
> So a nature thought comes to my mind, the first instance
> cyg_libc_main_thread must be constructed before the second instance
> cyg_libc_startup_obj. Otherwise, if cyg_libc_startup_obj was constructed
> first and cyg_libc_main_thread's not initializing yet, then there must be
> some problem.
> 
> 
> HOWEVER, these two instances have the same priority, I think same priority
> means that any of them constructs first will not affect the final result,
> no matter who. BUT these two do matter, aren't they?
> Which first may depend on compiler, and now we are using gcc4.2 compiler
> from
> http://www.codesourcery.com/gnu_toolchains/arm/download.html
> that is arm-eabi gcc compiler, and I found that this compiler does
> construct the second instance first, and eCos kernel can't start. Instance
> of mainthread(i.e. the first instance) is not initialized and its method is
> called, this is the reason of the problem, right?

This is Jifl's domain. However i will make a stab at answering....

I think you are correct. Probably the second should be

static cyg_libc_startup_dummy_constructor_class cyg_libc_startup_obj
                                   CYGBLD_ATTRIB_INIT_AFTER(CYG_INIT_LIBC)

I don't see how this can break anything. The scheduler is disabled at
this point anyway. The the resume call just marks the thread as
runable, but it won't get run until a lot later.

Jifl: Is this O.K?

      Andrew

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