--- Comment #39 from charlet at gcc dot gnu dot org 2008-05-12 22:43
---
Fixed on trunk.
Patch pre-approved on active branches if deemed necessary.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from laurent at guerby dot net 2008-04-05 09:51 ---
It's usually best to develop a patch against trunk and then port it if interest
for other branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #37 from joel at gcc dot gnu dot org 2008-04-04 15:11 ---
Forgot we are up to 4.4... it applies to 4.2 and 4.3 branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #36 from joel at gcc dot gnu dot org 2008-04-04 14:30 ---
Test results running with osinte.diff have been posted to gcc-testresults for
i386, mips, sparc, and powerpc. They look very good. Most failures are
cross-target or FPU exceptions now.
This needs to be applied to th
--- Comment #35 from joel dot sherrill at oarcorp dot com 2008-04-03 14:30
---
Subject: Re: Branch to 0x0 from Ada run-time
laurent at guerby dot net wrote:
> --- Comment #34 from laurent at guerby dot net 2008-04-03 03:47 ---
> May be other platform aligned the record 8 byte
--- Comment #34 from laurent at guerby dot net 2008-04-03 03:47 ---
May be other platform aligned the record 8 byte hence hiding the issue, and x86
only 4 bytes hence showing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #33 from laurent at guerby dot net 2008-04-03 03:46 ---
Great news!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #32 from joel at gcc dot gnu dot org 2008-04-03 00:14 ---
Created an attachment (id=15417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15417&action=view)
Correct structure bindings
pthread_condattr_t was missing a field.
sched_param had an incorrect type.
--
ht
--- Comment #31 from joel at gcc dot gnu dot org 2008-04-03 00:10 ---
(In reply to comment #30)
> Did you look at what happens in Initialize_TCB to the variable Success ?
After waiting and waiting at the hospital today, I had plenty of time
to think. My guess was that the saved copy o
--- Comment #30 from laurent at guerby dot net 2008-04-02 16:44 ---
Did you look at what happens in Initialize_TCB to the variable Success ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #29 from joel at gcc dot gnu dot org 2008-04-02 15:08 ---
I have spent the morning debugging at the assembly level and I am nearly 100%
positive %ebx is getting corrupted. It is correct before the call to
STPO.Initialize_TCB (T, Success);
at s-taskin.adb and 0x0 upo
--- Comment #28 from laurent at guerby dot net 2008-04-02 11:44 ---
I did not notice that s-taprop for rtems was the posix version
procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is
Mutex_Attr : aliased pthread_mutexattr_t;
Result : Interfaces.C.
--- Comment #27 from laurent at guerby dot net 2008-04-02 07:36 ---
My guess is that Initialize_TCB you wrote for RTEMS (s-taprop-rtems) does not
set success to True for some reason:
procedure Initialize_ATCB
...
STPO.Initialize_TCB (T, Success); --- here call into RTEMS specif
--- Comment #26 from joel at gcc dot gnu dot org 2008-04-01 22:40 ---
(In reply to comment #25)
> The binder will generate a call to Set_Globals
The code is different for the head but the intent is clear. Thanks
for the explanation.
A diff of the generated b~ file for powerpc and i386
--- Comment #25 from laurent at guerby dot net 2008-04-01 19:40 ---
The binder will generate a call to Set_Globals
pragma Import (C, Set_Globals, "__gnat_set_globals");
Set_Globals
(Main_Priority=> -1,
Time_Slice_Value => -1,
WC_
--- 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
pthre
--- Comment #23 from laurent at guerby dot net 2008-03-31 20:21 ---
pthread create and context switch should be the first to look at, in comparison
with a platform where it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #22 from joel at gcc dot gnu dot org 2008-03-31 20:16 ---
(In reply to comment #21)
> Best think would be to trace rtems calls on a platform where it works vs on
> the
> simulator. On a platform where it works, look at the backtrace of the task
> creation call and try to fin
--- Comment #21 from laurent at guerby dot net 2008-03-14 22:29 ---
Best think would be to trace rtems calls on a platform where it works vs on the
simulator. On a platform where it works, look at the backtrace of the task
creation call and try to find out why it doesn't get called on i3
--- Comment #20 from joel at gcc dot gnu dot org 2008-03-14 21:46 ---
I don't want this bug to die from inattention. Returning to my analysis of
Laurent's program, the task does not get to run at all before the system is
finalized. I suspect this indicates the initialization of the task
--- Comment #19 from joel at gcc dot gnu dot org 2008-02-25 20:45 ---
How early can I look at the task priority? Is it stored in some data structure
that I can see with objdump before the program is run?
I have yet to see anything in the debugger except 0 getting passed to task
creat
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-22 22:35 ---
(In reply to comment #17)
> If you have it on CFARM let me know where and what command to launch to gdb
> your testcase.
I have been building and running it on my laptop but there is now enough on
CFARM to run it.
q
--- Comment #17 from laurent at guerby dot net 2008-02-22 22:02 ---
If you have it on CFARM let me know where and what command to launch to gdb
your testcase.
What does RTEMS ada_pthread_minimum_stack_size returns in both case (under
gdb)?
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-22 22:01 ---
I can add mips/jmr3904 to the list that runs t.adb correctly. So we have
this as a summary:
sparc/sis, powerpc/psim, mips/jmr3904, arm/edb7312 - t.adb runs OK
i386/pc386 fails
bfin/exkit533 - GNAT bug bo
I doubleche
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-22 21:56 ---
(In reply to comment #14)
> Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
> RTEMS ada_pthread_minimum_stack_size:
>
> package body System.Parameters is
>
>function ada_pthread_minim
--- Comment #14 from laurent at guerby dot net 2008-02-22 21:12 ---
Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
RTEMS ada_pthread_minimum_stack_size:
package body System.Parameters is
function ada_pthread_minimum_stack_size return Interfaces.C.size_t
--- Comment #13 from joel at gcc dot gnu dot org 2008-02-22 20:53 ---
Laurent's t.adb works on arm/edb7312.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #12 from joel at gcc dot gnu dot org 2008-02-22 16:43 ---
I just noticed that the stack size passed to
system.task_primitives.operations.create_task is also 0 in the back trace on
the i386. It is 32724 on the PowerPC.
So two parameters are bad. The 0 just indicates that the
--- 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=18
--- Comment #10 from charlet at adacore dot com 2008-02-22 08:34 ---
Subject: Re: Branch to 0x0 from Ada run-time
> Arnaud, do you have any idea on what to look at (interesting breakpoint and
> data structures)? RTEMS tasking works on other platforms. May be some Ada/C
> thread interfa
> Arnaud, do you have any idea on what to look at (interesting breakpoint and
> data structures)? RTEMS tasking works on other platforms. May be some Ada/C
> thread interface data structure has the wrong size in the case of x86 and
> things get corrupted (s-oisinte-rtems.ads).
I'd suggest putting
--- Comment #9 from laurent at guerby dot net 2008-02-22 08:29 ---
Arnaud, do you have any idea on what to look at (interesting breakpoint and
data structures)? RTEMS tasking works on other platforms. May be some Ada/C
thread interface data structure has the wrong size in the case of x86
--- Comment #8 from charlet at gcc dot gnu dot org 2008-02-22 08:02 ---
Sounds like something specific to RTEMS, since I've never seen something like
that on any other platform.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from joel dot sherrill at oarcorp dot com 2008-02-21 23:55
---
Subject: Re: Branch to 0x0 from Ada run-time
laurent at guerby dot net wrote:
> --- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 ---
> Could you post the exact backtrace on my testcase
--- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 ---
Could you post the exact backtrace on my testcase? It purposely doesn't use the
complex Text_IO so things should be clearer. Also if you could use gdb to get
an understanding of what is done during adainit execution befor
--- Comment #5 from joel at gcc dot gnu dot org 2008-02-21 22:53 ---
Created an attachment (id=15202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15202&action=view)
generated from Laurent's t.adb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-21 22:52 ---
Runs OK on powerpc/psim and sparc/sis built from the same source tree for GCC
and RTEMS.
Fails like a99006a on i386.
Are there only ~300 tests which rely on tasking? I posted this URL:
http://gcc.gnu.org/ml/gcc-test
--- Comment #3 from laurent at guerby dot net 2008-02-21 22:32 ---
The great majority of FAIL are tests with an Ada task so my guess is that
tasking is broken.
I'm not a specialist but GNAT soft links are pointers to function which are set
by the elaboration code to point to tasking or
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-21 22:11 ---
Created an attachment (id=15201)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15201&action=view)
numerically sorted symbol table matching qemu.log
This is the numerically sorted symbol table matching the attache
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-21 22:10 ---
Created an attachment (id=15200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15200&action=view)
QEMU trace up to branch to 0x0
Search for "^0x" and then scroll backwards to see the indirect call in
ques
40 matches
Mail list logo
