Debugging basic BSP tasking functionality

Wed Apr 17 10:32:40 UTC 2013

Hi,

>They should do it all in the same way.  The difference is that some BSPs
use copy and >paste start.S files.  I removed a lot of copy and paste from
the ARM port with mechanical >changes.  It is possible that this broke some
BSPs including the rtl22xx_t.

I am using the stable 4.10.2 sources BTW. If the above still applies what
areas were changed, so i can investigate ?

>The stack checker inspects the pattern (0xFEEDF00D, 0x0BAD0D06,
0xDEADF00D, >0x600D0D06) at the end of the stack area.  One of these values
must be modified to the >the blown stack message.  You can set the write
break point here.

Are you sure ? looking at the code if the above pattern area is overwritten
then i would see a printk with "damaged pattern area". I dont see that, and
also when examining memory i can see the pattern is intact.

The other part of the stack check, is making sure the frame pointer is in
range of the stack, it looks like its this check that fails.

Indeed within Stack_check_Frame_pointer_in_range() GCC's
__builtin_frame_address(0); is returning a sp of 0x814d299c, which is
outside the stack range of the IDLE thread 0x814d060c -> 0x814d1610

the callstack is,..

Stack_check_Frame_pointer_in_range() at check.c:69 0x81180f6e
rtems_stack_checker_switch_extension() at check.c:276 0x81180f6e
_User_extensions_Thread_switch() at userextthreadswitch.c:41 0x8118cbaa
_Thread_Dispatch() at threaddispatch.c:128 0x8118bce6
_Thread_Enable_dispatch() at threaddispatch.c:59 0x8118bd5e
rtems_task_delete() at taskdelete.c:94 0x81189750
Init() at startup.c:241 0x81007840

On 17 April 2013 08:36, Sebastian Huber
<sebastian.huber at embedded-brains.de>wrote:

> On 04/16/2013 07:24 PM, Matthew J Fletcher wrote:
>
>> Thanks for the suggestions,
>>
>>  >Maybe this is a problem with the interrupt stack.  Is the interrupt
>> stack set
>> up correctly?
>>
>> I've triple checked this, infact all the ARM BSP's,csb336, edb7312, gp32,
>> gumstix and the rtl22xx_t all do it the same way. Only the lpcXX BSP's do
>> it
>> differently.
>>
>> They all use the linker file to allocate area's of RAM space with a
>> variable
>> pointing to the start, which is then used in the asm startup to setup the
>> stack
>> pointer and length. The rtl22xx_t is the same as all other others in this
>> regard.
>>
>
> They should do it all in the same way.  The difference is that some BSPs
> use copy and paste start.S files.  I removed a lot of copy and paste from
> the ARM port with mechanical changes.  It is possible that this broke some
> BSPs including the rtl22xx_t.
>
>
>
>>
>>  >You can set a hardware write break point in the stack pattern area.
>>
>> This was a really good piece of advice, i had forgotten about this.
>>
>> The blown stack message shows that the INIT thread stack runs 0x814d060c
>> through 0x814d1610 (4100 bytes). So i place some breakpoints and i can see
>> that  Stack_check_Initialize() has run because all bytes are 0xA5 and the
>> 0xFEEDF00D, 0x0BAD0D06, 0xDEADF00D, 0x600D0D06, pattern appears pretty
>> close to
>> the stop of the stack.
>>
>> So at the bottom we see,.. all good here. So i run the program.
>>
>> 0x814D15CC  A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>> A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5
>>
>> 0x814D1604  A5A5A5A5 A5A5A5A5 A5A5A5A5 02000000 00000431 00000000 814D1904
>> 814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000
>>
>> Then the memory watch hits,..
>>
>> 0x814D15CC  A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 A5A5A5A5 814C9A7C
>> 00000001 FFFFFFFF FFFFFFFF 8118BD5F 81421FA8 811A3ECB 81485FE0
>>
>> 0x814D1604  FFFFFFFF FFFFFFFF 811A3EA9 02000000 00000431 00000000 814D1904
>> 814D196C 814D19D4 00000000 00000000 00000000 00000000 00000000
>>
>> at 0x814d15e4 (splatted with 814C9A7C) and 0x814d15ec (splatted with
>> FFFFFFFF),
>> this is on the entry to _Thread_Dispatch(). Not sure how your email
>> client will
>> render the above, but there are various other overwrites as well.
>>
>> Now all of this is at the bottom of the stack, so 4000 bytes away from
>> the last
>> actual stack allocation, and remember this thread is just the
>> rtems_idle() with
>> a forever loop.
>>
>> So it looks like something around the inlined invocation of
>> _Thread_Enable_dispatch() is splatting the bottom of the stack.
>>
>
> The above seems to be all right.  In case the idle thread is suspended by
> an interrupt the _Thread_Dispatch() will do the context switch using the
> idle thread stack.
>
>
>
>>
>> Can i ask what stack/context _Thread_Handler() is called in ? the gdb
>> stacktrace thinks its called from _Objects_API_maximum_class(), but i
>> guess
>> thats it just failing to realise the top of the callstack.
>>
>
> The stack frame chain is not well terminated on the ARM.  So this might be
> ok.
>
> [...]
>
>          BLOWN STACK!!!
>>         task control block: 0x814C9BBC
>>         task ID: 0x09010001
>>         task name: 0x49444C45
>>         task name string: IDLE
>>         task stack area (4100 Bytes): 0x814D074C .. 0x814D1750
>>
>>         But my IDLE task is just a forever loop, so it seems unlikely.
>>
> [...]
>
> The stack checker inspects the pattern (0xFEEDF00D, 0x0BAD0D06,
> 0xDEADF00D, 0x600D0D06) at the end of the stack area.  One of these values
> must be modified to the the blown stack message.  You can set the write
> break point here.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>

-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130417/d25a3ce0/attachment-0001.html>