More weird behaviour on PowerPC.
Till Straumann
strauman at slac.stanford.edu
Mon May 24 20:17:14 UTC 2010
On 05/24/2010 03:00 PM, Nick Thomas wrote:
> 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 !!!!
>
It doesn't necessarily show that. It could be (and this wouldn't
be a huge surprise) that the stack gets corrupted and doesn't reflect
anymore
the true return addresses.
You can e.g., jump down into some subroutine which overruns
a stack variable (thus corrupting the stack). When the subroutine
returns it jumps into the woods instead of the caller
and raises a 0x700 exception.
> 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:
>
>
That's not too helpful since the memory contents are already
dumped with the disassembly above.
You can extract more information from the register contents,
the memory contents of the stack at the time of the crash
and a disassembly + listing of the code (if any -- probably
the PC is somewhere in the woods but it could also be that
the text got corrupted) at the PC location where
the code crashed.
HTH
-- Till
>> 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
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list