bug in gcc-3.2.3/gcc/gthr_rtems.h
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Tue Apr 20 23:05:59 UTC 2004
Till Straumann wrote:
> I think Yacine is right. Looking at gcc-3.2.2 is affected, too.
> Joel apparently added a macro definition on 2003-05-21 (gcc PR 9296)
> - however, the reasons for this change are not apparent.
> Joel, can you remember why you thought you had to define
> __GTHREAD_MUTEX_INIT ?
I will double check myhself tomorrow but this does NOT
appear to fix the problem for me. Maybe it is a build/install/test
confusion so I will double check. Has one of you successfuly
made this work with that mod?
> -- Till
> The Changelog
> EL KOLLI Yacine wrote:
>> 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:
>> to initialize __gthread_mutex_t to get a fast
>> non-recursive mutex.
>> 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.
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users