Debugging basic BSP tasking functionality

[Matthew J Fletcher]

Hi

>Here a context switch from the Init to the idle (I guess) thread happens.
 The >_User_extensions_Thread_switch
>() is called before the context switch and the running thread is checked.
 So a sp of >0x814d299c must be in the range of the Init stack area.

Yes it is, Init() stack area is 0x814d1a70 -> 0x814d2a74 (4100 bytes). So
it looks like the stack pointer is not getting adjusted correctly when task
switching into a new thread ? as the rtems_idle task is using the Init()
stack pointer.

> nm your-app.exe | grep 'bsp_\(section\|stack\)' | sort

No matches.




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

> On 04/17/2013 12:32 PM, Matthew J Fletcher wrote:
>
>> 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 ?
>>
>
> I changed some linker command files and the interrupt support, e.g.
>
> http://git.rtems.org/rtems/**commit/?id=**f4dc319a8f92190c6efac916fb8b9b**
> 651d89df7c<http://git.rtems.org/rtems/commit/?id=f4dc319a8f92190c6efac916fb8b9b651d89df7c>
>
> You can try also a RTEMS 4.9 version.
>
>
>
>>  >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
>>
> [...]
>
> Here a context switch from the Init to the idle (I guess) thread happens.
>  The _User_extensions_Thread_**switch() is called before the context
> switch and the running thread is checked.  So a sp of 0x814d299c must be in
> the range of the Init stack area.
>
> What is the output of
>
> nm your-app.exe | grep 'bsp_\(section\|stack\)' | sort
>
>
> ?
>
> --
> 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/af5bc5f2/attachment.html>