summaryrefslogtreecommitdiff
path: root/test/tx/regression/threadx_thread_trace_test.c
AgeCommit message (Collapse)Author
2026-09-15Covered the thread services' trace inserts in every system stateFrédéric Desbiens
Every thread service carries one TX_TRACE_IN_LINE_INSERT, and gcov scores twelve branch outcomes for the macro. Seventeen of those inserts sat between one and nine of twelve, because exactly one test in the suite ever turns tracing on and it does not drive the thread API. The code runs -- the sites are hit hundreds of thousands of times -- but tracing is never enabled when it does. The new test follows the shape the queue subsystem established. It enables tracing and walks all sixteen services once per condition the macro distinguishes: in thread context, in interrupt context from the test ISR dispatch, with the system state forced to TX_INITIALIZE_IN_PROGRESS and again to the value an interrupt presents, with the thread and internal event classes filtered out, and across a buffer wrap with and without a buffer-full notification registered. Three things are specific to this subsystem rather than inherited from the queue test. The scheduler's inserts sit behind the published ones. A resume writes an API event and then _tx_thread_system_resume writes an internal event of its own, so positioning the buffer one entry short of its end puts the API insert on the boundary and never the scheduler's. The wrap pass therefore drives the resume and the suspend twice, positioned one entry short and then two. The scheduler also updates the entry it wrote, once it knows which thread runs next, and only if the timestamp says nothing overwrote it in between. That update is unreachable unless a resume actually preempts while tracing is on, so the test ends with a pass that resumes a higher-priority thread and takes the processor back from it four times. The three regions of _tx_thread_system_suspend and the two of _tx_thread_system_resume are reached this way; what is left uncovered in them is the arm where the timestamp differs, which needs a second event inserted inside a window the kernel holds interrupts off across. The sleep service tests the system state itself, ahead of its own insert, and refuses every caller that is not a thread. Its insert is therefore only ever reached at system state zero and stops at nine of twelve. Neither the published entry point nor the internal one can reach the other three. A thread's lifecycle does not close on itself the way a queue's does: a reset is only legal from the terminated state, which a reset does not leave the thread in. So the reset is driven against a second scratch thread that the service terminates again on its way out, after its own insert has run, and the first scratch thread is created and deleted once per pass as the queue was. Merged coverage over the six build configurations rises from 3927/4627 branches to 4097/4627, with lines at 4300/4339. Every thread trace insert but the sleep is now at twelve of twelve. The gates go to 99.00 and 88.00, below the measured figures by the margin the resume-from-ISR variance needs: two clean runs agree exactly on lines and differ by one branch outcome. Assisted-by: Claude Code (Opus 5) <[email protected]>