Re: [ECOS] A problem about constructor sequence

Re: [ECOS] A problem about constructor sequence

[taiyun]

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

Thanks a lot, really appreciate your answers.

But I still doubt, I have checked the source code of thread.cxx, I found
that thread's state is set to SUSPENDED in Cyg_Thread class's constructor
and suspend_count variable is set to 1(1 represents suspended and 0
represents ready or running, right?), so when Cyg_Thread's resume method is
called, suspend_count will be set to 0 to indicate this thread is not
suspended, and state of thread will be set, too.

cyg_libc_main_thread is an instance of Cyg_Thread, so it must follow this
procedure. If it was constructed first, then when instance
cyg_libc_startup_obj is constructed, cyg_libc_main_thread.resume will be
called.
BUT if cyg_libc_main_thread is constructed after cyg_libc_startup_obj, I
think this case will cause problem. Because cyg_libc_startup_obj will call
cyg_libc_main_thread.resume, NOW I know scheduler is not start yet till
this point, so it just sets some flag, it is ok.
BUT after cyg_libc_startup_obj is constructed, then will be
cyg_libc_main_thread. In constructor of cyg_libc_main_thread, thread's
state will be set to SUSPENDED, and will never be resumed, isn't it?

Can't this cause problem??

Sincerely Yours



***********************************************
Beijing Sunnorth eCos Maintainer Group

Maintainers:
liqin@sunnorth.com.cn
wanghui@sunnorth.com.cn
taiyun@sunnorth.com.cn
yxinghua@sunnorth.com.cn

Bejing Sunnorth Electronic Technology Co.,LTD
***********************************************


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

Re: [ECOS] A problem about constructor sequence

[Andrew Lunn]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

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

Here is the patch i have committed to CVS.

     Andrew

[-- Attachment #2: startup.diff --]
[-- Type: text/x-diff, Size: 1481 bytes --]

Index: language/c/libc/startup/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/language/c/libc/startup/current/ChangeLog,v
retrieving revision 1.9
diff -u -r1.9 ChangeLog
--- language/c/libc/startup/current/ChangeLog	2 Jul 2007 11:48:59 -0000	1.9
+++ language/c/libc/startup/current/ChangeLog	11 Sep 2007 16:47:46 -0000
@@ -1,3 +1,9 @@
+2007-09-11  Andrew Lunn  <andrew.lunn@ascom.ch>
+
+	* src/cstartup.cxx: Change the INIT priority of
+	cyg_libc_startup_obj so that it is always called after the thread
+	has been constructed. Reported by taiyun@sunnorth.com.cn
+
 2007-07-02  Gary Thomas  <gary@mlbassoc.com>
 
 	* cdl/startup.cdl: Add (char *) casts to make GCC/4.2.x happy.
Index: language/c/libc/startup/current/src/cstartup.cxx
===================================================================
RCS file: /cvs/ecos/ecos/packages/language/c/libc/startup/current/src/cstartup.cxx,v
retrieving revision 1.3
diff -u -r1.3 cstartup.cxx
--- language/c/libc/startup/current/src/cstartup.cxx	23 May 2002 23:07:11 -0000	1.3
+++ language/c/libc/startup/current/src/cstartup.cxx	11 Sep 2007 16:47:46 -0000
@@ -104,7 +104,7 @@
 };
 
 static cyg_libc_startup_dummy_constructor_class cyg_libc_startup_obj
-                                  CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_LIBC);
+                                  CYGBLD_ATTRIB_INIT_AFTER(CYG_INIT_LIBC);
 
 #elif defined( CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT )
 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] A problem about constructor sequence

[Jonathan Larmour]

Andrew Lunn wrote:
> 
> 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?

I think this is absolutely fine.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine

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

Re: [ECOS] A problem about constructor sequence

[Andrew Lunn]

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

[ECOS] A problem about constructor sequence

[taiyun]

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?

Thanks for your answering in advance, and sorry for my bad expression.



***********************************************
Beijing Sunnorth eCos Maintainer Group

Maintainers:
liqin@sunnorth.com.cn
wanghui@sunnorth.com.cn
taiyun@sunnorth.com.cn
yxinghua@sunnorth.com.cn

Bejing Sunnorth Electronic Technology Co.,LTD
***********************************************


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