[Bug ada/35284] Branch to 0x0 from Ada run-time

["joel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #11 from joel at gcc dot gnu dot org  2008-02-22 15:34 -------
Good Morning!  By setting a breakpoint on _CPU_Context_switch in RTEMS, I can
see where things went wrong.  On both SPARC and PowerPC, we dispatched out of
this backtrace:

(gdb) bt
#0  pthread_setschedparam (thread=184614915, policy=0, param=0x175000)
    at ../../cpukit/../../../pc386/lib/include/rtems/score/thread.inl:209
#1  0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4, 
    prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#2  0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4, 
    wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#3  0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
    at s-tassta.adb:338
#4  0x001005ea in t () at t.adb:2

At this point, the Ada run-time is setting the priority of the POSIX
thread it just created.

On the PowerPC (and I assume SPARC since it works there also), the 
contents of the scheduling parameter structure is:

(gdb) p *param
$1 = {sched_priority = 122, ss_low_priority = 7462340, ss_replenish_period = {
    tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 1, 
    tv_nsec = 32724}}

On the i386, this same structure at the same point in RTEMS has this:

$1 = {sched_priority = 0, ss_low_priority = 2, ss_replenish_period = {
    tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 0, tv_nsec = 0}}

The sched_priority field is NOT a valid priority and RTEMS returns EINVAL.
There is a pragma assert after this call in the Ada
system.task_primitives.operations.set_priority so I assume assertions
are disabled.  FWIW sys/sched.h is the same file with no CPU ifdefs
on all RTEMS targets.

Since this is the first field in the structure, we are not dealing with
an alignment problem.  All of the Ada run-time target specific files 
for RTEMS are shared across the architectures so I doubt that is a problem.

I noticed that in the good backtrace, I see this:

#0  pthread_setschedparam (thread=184614915, policy=0, param=0x744c30)
    at
../../../../../../../423/rtems/c/src/../../cpukit/posix/src/pthreadsetschedparam.c:47
#1  0x00001954 in system.task_primitives.operations.set_priority (t=0x5e868, 
    prio=122, loss_of_inheritance=<value optimized out>) at s-taprop.adb:777
#2  0x00001a38 in system.task_primitives.operations.create_task (t=0x5e868, 
    wrapper=32724, stack_size=32768, priority=122) at s-taprop.adb:1016
#3  0x00007bb4 in system.tasking.stages.activate_tasks (chain_access=0x744d34)
    at s-tassta.adb:338
#4  0x000007ec in t () at t.adb:2

In the bad backtrace, I see this:

#0  0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4, 
    prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#1  0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4, 
    wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#2  0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
    at s-tassta.adb:338
#3  0x001005ea in t () at t.adb:2

Notice that create.task is passed a 0 for priority on the i386 and a 122 on the 
good backtrace.  

What to look at next?  That bad priority value has to come from somewhere. 


-- 

joel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-22 15:34:43
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284