bug in gcc-3.2.3/gcc/gthr_rtems.h

EL KOLLI Yacine yacine.elkolli at crf.canon.fr
Wed Apr 21 14:10:53 UTC 2004


Joel Sherrill wrote:
> 
> Grrr... something still isn't right for me.  Details and
> questions below.

Comment interleaved, hope it helps..

> EL KOLLI Yacine wrote:
> 
>> Till Straumann wrote:
>>
> 
>>> Well - it seemed to me that Yacine did. I didn't do a runtime check but
>>> my good friend 'nm' tells me:
>>
>>
>>
>> Yes I confirm that I've done a run time check, and that solved the 
>> problem.
>> I've removed the __GTHREAD_MUTEX_INIT define, then I've re-built gcc, 
>> then re-built rtems and then re-built my c++ application.
>>
>>> without mod:
>>>
>>> [tillpc]> nm -Au libstdc++.a | grep rtems_gxx_mutex_init
>>> libstdc++.a:eh_alloc.o:rtems_gxx_mutex_init
>>>
>>> with mod (i.e., __GTHREAD_MUTEX_INIT *not* defined):
>>> [tillpc]> nm -Au libstdc++.a | grep rtems_gxx_mutex_init
>>> libstdc++.a:globals.o:rtems_gxx_mutex_init
>>> libstdc++.a:eh_alloc.o:rtems_gxx_mutex_init
> 
> 
> I have these symbols as shown above so it looks like the
> toolset was built properly.

same for me

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



More information about the users mailing list