Which threads execute _Thread_Handler ?

Joel Sherrill joel at rtems.org
Sat Dec 5 16:52:14 UTC 2020


On Sat, Dec 5, 2020, 12:14 AM Richi Dubey <richidubey at gmail.com> wrote:

> Also,
>
> The stack trace for the thread looks like this:
>
> Tasks (entry function) -> rtems_task_wake_after ->_Thread_Dispatch_direct
> -> _Thread_Do_dispatch (where the _Context_switch function call lies), how
> can then the heir thread start executing from the _Thread_Handler? I do not
> see it in the trace at all.
>

Maybe the stack trace isn't right. I saw case this week where the stack
trace during system initialization doesn't work at all on a sync qemu.

I'd recommend setting a breakpoint at thread handler and at the entry point
of each of the threads just to confirm that what is supposed to happen is
actually happening.

--joel

>
>
>
> On Sat, Dec 5, 2020 at 11:05 AM Richi Dubey <richidubey at gmail.com> wrote:
>
>> I have currently no time to help you debugging this issue.
>>
>> Okay, even a hint would be helpful.
>>
>> returns to _Thread_Do_dispatch() or jumps to _Thread_Handler().
>>
>> When does it return to  _Thread_Do_dispatch() and when does it jump to
>> _Thread_Handler() ? Is there a condition? How does it choose between what
>> to do?
>>
>>
>> On Fri, Dec 4, 2020 at 1:35 PM Sebastian Huber <
>> sebastian.huber at embedded-brains.de> wrote:
>>
>>> On 04/12/2020 08:56, Richi Dubey wrote:
>>>
>>> >
>>> > When I am trying to debug tm24 running on the Strong APA scheduler
>>> > code, I can see that the thread which comes after the call
>>> > to _CPU_Context_switch, resumes execution from the same code (next
>>> > line in the _Thread_Do_dispatch function after _CPU_Context_switch),
>>> > whereas when the same code is run on a different scheduler (the
>>> > default sp scheduler) the heir thread that executes after the call
>>> > to _CPU_Context_switch starts executing from  _Thread_Handler and does
>>> > not resume its execution from the _Thread_Do_dispatch (which has the
>>> > context_switch function call).
>>> >
>>> > Why is this happening? Is the scheduler responsible for this?
>>>
>>> I have currently no time to help you debugging this issue.
>>>
>>> Each thread starts the execution in _Thread_Handler(). A context switch
>>> returns to _Thread_Do_dispatch() or jumps to _Thread_Handler(). The
>>> _Thread_Handler() completes the context switch, does some general calls
>>> to begin the thread execution and then calls the thread entry function.
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.huber at embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201205/42fa7b66/attachment.html>


More information about the devel mailing list