Covered the trace entry update paths and the misaligned stack adjustment

[fdesbiens]

Against the merged coverage report — every build configuration instrumented and unioned, which is #665 — eighteen lines of common/src were uncovered. Seventeen of them were one missing scenario rather than eighteen separate gaps.

The scenario

tx_block_allocate.c, tx_byte_allocate.c, tx_thread_system_suspend.c and tx_thread_system_resume.c each carry blocks under TX_ENABLE_EVENT_TRACE that go back and patch a trace entry once the call has done its work, all of the same shape:

if (entry_ptr != TX_NULL)
{
    if (time_stamp == entry_ptr -> tx_trace_buffer_entry_time_stamp)
    {
        entry_ptr -> tx_trace_buffer_entry_information_field_4 = ...;
    }
}

entry_ptr comes from _tx_trace_buffer_current_ptr, which stays TX_NULL until tx_trace_enable is called at run time. Building with TX_ENABLE_EVENT_TRACE is not enough, and exactly one test in the suite enables tracing — threadx_trace_basic_test — which tests the enable API itself and never calls either allocator. So those blocks sat in the report's denominator and never in its covered set.

The tests

threadx_trace_entry_update_test enables tracing and then drives both allocators twice each — once on the path that succeeds immediately and once through a suspension that a second thread satisfies — because each allocator carries one update block on either side.

It then sleeps so the last runnable thread suspends with nothing ready to take over. That is not padding: tx_thread_system_suspend.c 345 and 351 are on the branch that sets _tx_thread_execute_ptr to TX_NULL, and the two allocator suspensions never reach it because the other thread was always ready.

The same test closes tx_trace_object_register's TX_NULL-name break by creating a semaphore with no name. A semaphore and not a thread deliberately: for TX_TRACE_OBJECT_TYPE_THREAD the register function dereferences the pointer it is handed to read the thread's priority, so that type needs a real TX_THREAD behind it.

threadx_thread_misaligned_stack_test covers the remaining line, tx_thread_create.c:136, where a stack that does not begin on a ULONG boundary costs a ULONG of size so that rounding the start up cannot run past the end of the caller's buffer. Every other test hands tx_thread_create an aligned stack. That line is compiled only under TX_ENABLE_STACK_CHECKING, so it is absent from three of the five configurations' reports rather than uncovered in them — it was verified under stack_checking_build.

Measured

All 480 tests passing, 5 of 5 configurations green:

	lines-valid	lines-covered
before	4503	4485
after	4503	4502

The denominator is unchanged, as it should be — these are tests, not new kernel code.

One line remains, and it is a flapping line rather than a gap

tx_thread_system_resume.c:529. Two clean runs of the same tree, both green, gave 4503/4503 and 4502/4503 — so a floor set at 100% would fail on a race.

Reaching it by construction was tried twice and failed both times, so it is left alone here. It needs _tx_thread_preempt_disable and _tx_thread_system_state both clear at that point:

• tx_thread_resume raises the preempt disable flag before calling _tx_thread_system_resume, and so do the put and send paths.
• Creating a higher-priority auto-start thread from thread context does not raise it, but does not reach the check either — a probe showed the guard executed only during initialisation, with the system state at TX_INITIALIZE_IN_PROGRESS.

The test written for the second attempt was deleted rather than kept: it passed and exercised real behaviour, but its documented purpose was covering that line and it did not.

Note for review

The before/after figures are against the merged report from #665. These tests stand on their own and pass in every configuration without it — but without #665 only default_build_coverage is instrumented, and most of what they cover is not measured.