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