Why do threads start execution from _Thread_Handler?

Sat Jan 9 06:08:22 UTC 2021

Hi,

Can someone please help me with this?

The strong apa scheduler code that I am trying to debug never goes
_Thread_Handler function, while the default priority scheduler's code does
go to _Thread_Handler function:

Strong APA trace:
-----------------------------------------------------------
(gdb) b _Thread_Handler
(gdb) b _Thread_Do_dispatch
(gdb) c
Continuing.

Thread 1 hit Breakpoint 11, _Thread_Do_dispatch (cpu_self=0x200540
<_Per_CPU_Information>, level=1611596115) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:267
267    !_ISR_Is_enabled( level )
(gdb) ni
...
305    _Context_Switch( &executing->Registers, &heir->Registers );
(gdb) si
...
121 ldm r1, {r4, r5, r6, r7, r8, r9, r10, r11, r13, pc}
(gdb)
_Thread_Do_dispatch (cpu_self=0x200540 <_Per_CPU_Information>,
level=1611596115) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:306
306    _Thread_Restore_fp( executing );
(gdb)
0x001081aa 306    _Thread_Restore_fp( executing );
(gdb) ni
...
0x001081e6 328  _Thread_Run_post_switch_actions( executing );
(gdb)
329 }
(gdb)
_Thread_Dispatch_direct (cpu_self=0x200540 <_Per_CPU_Information>) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:360
360 }
(gdb)
rtems_task_wake_after (ticks=0) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/rtems/src/taskwakeafter.c:47
47  return RTEMS_SUCCESSFUL;
(gdb)
48 }
Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:129
_Thread_Entry_adaptor_numeric (executing=0x201980
<_RTEMS_tasks_Objects+2576>) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadentryadaptornumeric.c:26
26 }
(gdb)
_Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:152
152  _User_extensions_Thread_exitted( executing );
(gdb)
0x00108708 152  _User_extensions_Thread_exitted( executing );
(gdb)
154  _Internal_error( INTERNAL_ERROR_THREAD_EXITTED );
(gdb)
0x0010870e 154  _Internal_error( INTERNAL_ERROR_THREAD_EXITTED );
(gdb)

Thread 1 hit Breakpoint 5, _Terminate (the_source=INTERNAL_ERROR_CORE,
the_error=5) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/interr.c:36
36  _User_extensions_Fatal( the_source, the_error );
(gdb)
0x0010e37e 36  _User_extensions_Fatal( the_source, the_error );
(gdb)

-----------------------------------------------------------

Priority Scheduler's trace:

---------------------------------------------------
(gdb) b _Thread_Handler
(gdb) b _Thread_Do_dispatch

(gdb) c
Continuing.

Thread 1 hit Breakpoint 15, _Thread_Do_dispatch (cpu_self=0x200540
<_Per_CPU_Information>, level=1611596115) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:267
267    !_ISR_Is_enabled( level )
(gdb) ni
...
0x0010a170 305    _Context_Switch( &executing->Registers, &heir->Registers
);
(gdb)
_CPU_Context_switch () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/cpu_asm.S:56
56 DEFINE_FUNCTION_ARM(_CPU_Context_switch)
(gdb)
...
121 ldm r1, {r4, r5, r6, r7, r8, r9, r10, r11, r13, pc}
(gdb)
_Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:77
77 {
(gdb)
0x0010a67a 77 {
(gdb) ni
0x0010a67c 77 {
(gdb)

Thread 1 hit Breakpoint 14, _Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:88
88  executing = _Thread_Executing;
(gdb)
0x0010a682 88  executing = _Thread_Executing;
(gdb)
0x0010a684 88  executing = _Thread_Executing;
(gdb) ni
...
(gdb) si
0x0010a6b8 126  _Thread_Do_dispatch( cpu_self, level );
(gdb)
_Thread_Do_dispatch (cpu_self=0x22ba40, level=2275904) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:260
260 {
(gdb)
...
0x0010a1b2 328  _Thread_Run_post_switch_actions( executing );
(gdb)
329 }
(gdb)
_Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:134
134  _User_extensions_Thread_begin( executing );
(gdb)
0x0010a6be 134  _User_extensions_Thread_begin( executing );
(gdb)
136  _Thread_Global_construction( executing );
(gdb)
0x0010a6c4 136  _Thread_Global_construction( executing );
(gdb)
143  ( *executing->Start.Entry.adaptor )( executing );
(gdb)
0x0010a6ca 143  ( *executing->Start.Entry.adaptor )( executing );
(gdb)
0x0010a6ce 143  ( *executing->Start.Entry.adaptor )( executing );
(gdb)
0x0010a6d0 143  ( *executing->Start.Entry.adaptor )( executing );
(gdb)

Thread 1 hit Breakpoint 13, Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
110  Task_count++;
(gdb)
0x00100eda 110  Task_count++;
(gdb)
0x00100ede 110  Task_count++;
-------------------

On Mon, Jan 4, 2021 at 11:22 PM Richi Dubey <richidubey at gmail.com> wrote:

> Hi,
>
> I am debugging a code (tm24
> <https://git.rtems.org/rtems/tree/testsuites/tmtests/tm24/task1.c>) and
> there is a scenario where a thread is blocked on the CPU and a new thread
> has to start executing in its place. So, the thread which is getting
> blocked (executing thread) executes the _Thread_Do_dispatch and runs the
> code until
> <https://git.rtems.org/rtems/tree/cpukit/score/src/threaddispatch.c#n308>:
> _Context_Switch( &executing->Registers, &heir->Registers ). After this,
> the heir thread starts executing from _Thread_Handler. Why is this the
> case? Should the heir not start its execution from where the (earlier)
> executing thread left the program counter at, i.e. after the
> _Context_Switch in _Thread_Do_dispatch?
>
> Please let me know your thoughts.
>
> Thanks,
> Richi.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210109/24d000a6/attachment-0001.html>