More weird behaviour on PowerPC.
Nick Thomas
nick.thomas at pixsan.com
Mon May 24 20:00:10 UTC 2010
Hi
My colleague and I have spent the last couple of days upgrading our RTEMS OS
from 4.7.1 to 4.7.3. At the same time we have added the -fno-strict-aliasing
flag to the compiler.
I don't this these modifications have helped in our stability issues,
because I have just observed a weird thing with the new build :(
It's just taken a 0x0700 (Program Exception). And looking at the call stack
I see:
(gdb) bt
#0 0x00000014 in ?? ()
#1 0x00000010 in ?? ()
#2 0x00325148 in FILTER_Task_Entry ()
#3 0x003197b8 in task_launch ()
The last good address is 0x00325148. Which is indeed in FILTER_Task_Entry,
the disassembly around 0x00325148 is:
0x0032513c <FILTER_Task_Entry+540>: stw r10,1864(r16)
0x00325140 <FILTER_Task_Entry+544>: sth r0,4(r11)
0x00325144 <FILTER_Task_Entry+548>: bl 0x323964
<FILTER_String_Length+60>
0x00325148 <FILTER_Task_Entry+552>: b 0x325024
<FILTER_Task_Entry+260>
0x0032514c <FILTER_Task_Entry+556>: lwz r4,1912(r19)
0x00325150 <FILTER_Task_Entry+560>: li r5,0
So, at 0x00325148 is a simple branch instruction to an address earlier
inside the same function. But, the call stack shows that it next went to
0x00000010 !!!!
What on earth could make it do that?
I don't know if this is useful, but here is the dump of the memory at those
locations:
> md 0x0032513c 6
0032513c : 0x91500748 -1857026232 .P.H
00325140 : 0xb00b0004 -1341456380 ....
00325144 : 0x4bffe821 1275062305 K..!
00325148 : 0x4bfffedc 1275068124 K...
0032514c : 0x80930778 -2137847944 ...x
00325150 : 0x38a00000 950009856
Regards
Nick
-----------------------------
Nick Thomas
Email: nick.thomas at pixsan.com
More information about the users
mailing list