------- Comment #24 from joel at gcc dot gnu dot org 2008-04-01 18:02 -------
With Laurent's test program, I have traces of good (powerpc/psim) and bad
(qemu) runs. The traced include only entry and exit status info for the
following calls are:
_CPU_Context_switch
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_create
pthread_exit
pthread_getschedparam
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_timedlock
pthread_mutex_unlock
pthread_setschedparam
rtems_stack_checker_is_blown
rtems_task_create
There are two anomalies in the i386 run:
The first call to pthread_setschedparam() returns EINVAL because it is passed a
sched_param with priority == 0. This field is 122 on the valid psim run.
Backtrace indicates we are still in initialization. I do not know how to tell
where the 0 came from before here.
#2 0x0010153f in system.task_primitives.operations.set_priority (t=0x1dbb38,
prio=0, loss_of_inheritance=0) at s-taprop.adb:764
#3 0x0010451d in system.tasking.initialize () at s-taskin.adb:188
#4 0x00103fc8 in system.tasking.initialization.init_rts () at s-tasini.adb:322
#5 0x0010032b in adainit ()
Later there is a pthread_mutex_unlock() call which passes in a bad mutex id.
This does not occur on the psim run.
The bad pthread_setschedparam call is not THAT far into the execution and the
traced calls up until this point are the same.
ENTER pthread_create
EXIT pthread_create (0)
ENTER _CPU_Context_switch
ENTER pthread_create
EXIT pthread_create (0)
ENTER pthread_exit
ENTER _CPU_Context_switch
ENTER pthread_mutex_init
EXIT pthread_mutex_init (0)
ENTER pthread_cond_init
EXIT pthread_cond_init (0)
ENTER pthread_mutex_init
EXIT pthread_mutex_init (0)
ENTER pthread_mutex_lock
EXIT pthread_mutex_lock (0)
ENTER pthread_mutex_unlock
EXIT pthread_mutex_unlock (0)
ENTER pthread_setschedparam
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
