bug in gcc-3.2.3/gcc/gthr_rtems.h

[EL KOLLI Yacine]

Joel Sherrill wrote:
> EL KOLLI Yacine wrote:
> 
>> Comment interleaved, hope it helps..
> 
> 
> I think we are getting there.  We might be fixing two things. :(

well that can be a good news ;o)

>>> EL KOLLI Yacine wrote:
>>>
> 
>>> I rebuilt completely a toolset and RTEMS for psim so that
>>> shouldn't be a problem.
>>>
>>> I am still not getting a break at rtems_gxx_mutex_init
>>> and the test is obviously failing.
>>
>>
>>
>> Are you sure that your c++ test is using STL ?
> 
> 
> Hmmm.. that may be a hint.  I added your list
> code before the cout.  Now rtems_gxx_mutex_init
> is being called but the test fails on the cout.
> 
> Can you run the cdtest when
> RTEMS_TEST_IO_STREAM is defined in main.cc?

yes and It works.


I've modified the _Thread_Handler function to make it calling _eabi() 
instead of _init(). I've done this a while a go, when I was trying to 
get the IO streams working. But I'don't remember if that solves my 
problem, nor why I have not submitted the modification :o(.

When you run cdtest global constructors should print a message on sreen 
before the main message. Do you have the print out from the global 
constructors ?

>> If no STL constructor is called then gxx_muext_init will not.
>> With my test software I was getting gxx_mutex_init called once without 
>> the patch, and called 3 times with the patch.
>>
>> try adding the following lines to the cdtest sample:
>>
>> #include <list>
>> .
>> .
>> .
>> cdtest(void){
>> .
>> std::list<int> int_list;
>> for (int i=0;i<10;i++) int_list.push_front(i);
>>
>>> My patch to gthr-rtems is:
>>> diff -uNr /usr1/rtems/work-tools/original/gcc-3.2.3/gcc/gthr-rtems.h 
>>> gcc-3.2.3/gcc/gthr-rtems.h
>>> --- /usr1/rtems/work-tools/original/gcc-3.2.3/gcc/gthr-rtems.h  Wed 
>>> Jan 29 09:57:53 2003
>>> +++ gcc-3.2.3/gcc/gthr-rtems.h  Tue Apr 20 14:17:52 2004
>>> @@ -37,7 +37,6 @@
>>>  #define __GTHREADS 1
>>>
>>>  #define __GTHREAD_ONCE_INIT  0
>>> -#define __GTHREAD_MUTEX_INIT 0
>>>  #define __GTHREAD_MUTEX_INIT_FUNCTION  rtems_gxx_mutex_init
>>
>>
>>
>> I have the same patch
>>
>>>
>>> Yacine, what BSP are you using?  Could you confirm things
>>> with psim?
>>
>>
>>
>> I'am using gen405 bsp.
>>
>> I've never played with psim, I'll give it a try, but this may take 
>> some time
>>
>>>>> -- Till
>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Till
>>>>>>>
>>>>>>> The Changelog
>>>>>>>
>>>>>>> EL KOLLI Yacine wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I think there is a bug in gthr_rtems.h in the gcc-3.2.3 source 
>>>>>>>> tree under gcc-3.2.3/gcc/gthr_rtems.h.
>>>>>>>>
>>>>>>>> In this file   __GTHREAD_MUTEX_INIT is define to 0 and 
>>>>>>>> __GTHREAD_MUTEX_INIT_FUNCTION   is defined to rtems_gxx_mutex_init.
>>>>>>>>
>>>>>>>> But a comment in gthr.h states:
>>>>>>>>      __GTHREAD_MUTEX_INIT
>>>>>>>>          to initialize __gthread_mutex_t to get a fast
>>>>>>>>     non-recursive mutex.
>>>>>>>>      __GTHREAD_MUTEX_INIT_FUNCTION
>>>>>>>>          some systems can't initialize a mutex without a
>>>>>>>>     function call.  On such systems, define this to a
>>>>>>>>     function which looks like this:
>>>>>>>>     void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *)
>>>>>>>>     Don't define __GTHREAD_MUTEX_INIT in this case
>>>>>>>>
>>>>>>>> The result of having defined __GTHREAD_MUTEX_INIT is that the 
>>>>>>>> STL global constructor does not call rtems_gxx_mutex_init to 
>>>>>>>> init its mutex, but rather use the statically defined value 0.
>>>>>>>> All locking performed by the STL lib on this mutex fail with 
>>>>>>>> return value OBJECT_ERROR, which seems not be tested.
>>>>>>>>
>>>>>>>> I've recompiled gcc with __THREAD_MUTEX_INIT left undefined. Now 
>>>>>>>> STL constructor is calling rtems_gxx_mutex_init , and nothing 
>>>>>>>> seems broken.
>>>>>>>>
>>>>>>>> Any comments ?
>>>>>>>>
>>>>>>>> Y El Kolli.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
=====================================================
EL KOLLI Yacine         | yacine.elkolli at crf.canon.fr
Canon C.R.F.            | Phone: +33.(0)2.99.87.68.79
http://www.crf.canon.fr | FAX: +33.(0)2.99.84.11.30
====================================================