More weird behaviour on PowerPC.

Nick Thomas nick.thomas at
Mon May 24 20:00:10 UTC 2010


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
0x00325148 <FILTER_Task_Entry+552>:	b       0x325024
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

> 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



Nick Thomas
Email: nick.thomas at 

More information about the users mailing list