<feed xmlns='http://www.w3.org/2005/Atom'>
<title>threadx.git/test/tx/regression, branch v6.4.1_cert</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/threadx.git/atom/test/tx/regression?h=v6.4.1_cert</id>
<link rel='self' href='http://cgit.235523.xyz/threadx.git/atom/test/tx/regression?h=v6.4.1_cert'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/'/>
<updated>2026-09-16T15:27:52Z</updated>
<entry>
<title>Covered the byte allocate's overwritten trace entry via the port hook</title>
<updated>2026-09-16T15:27:52Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T15:27:52Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=162814d654508b1929acfbef2684ae0af2ac21e6'/>
<id>urn:sha1:162814d654508b1929acfbef2684ae0af2ac21e6</id>
<content type='text'>
The byte allocate saves the time stamp of its own trace entry and comes back to
fill in the address it allocated, unless a later event overwrote the entry
meanwhile. Interrupts are off across all of the service but the pool search, and
nothing in the kernel writes a trace event in that gap, so the other arm never
ran.

The Linux port already calls out to the harness inside that gap:
TX_BYTE_ALLOCATE_EXTENSION exists for coverage work and sits between the restore
and the disable that bracket the search. It gains a second clause, under its own
flag, calling a routine the harness declares weakly. A new test filters the byte
pool event class so the allocate's own insert writes nothing and leaves the
buffer parked on the saved entry, then has the hook write a user event, which
lands on exactly that entry. Neither half reaches the arm alone.

One configuration cannot take it at all, and that is a property of the port
rather than of the test: under TX_MISRA_ENABLE the trace time stamp comes from a
function whose body returns zero, so every entry reads zero and the comparison
is 0 == 0 whatever overwrites it. The test drives the overwrite there too and
asserts the consequence only where the time source is real.

805/805 in each of the seven configurations. Union coverage is 4383/4383 lines
and 3150/3170 branches against 3147/3168; the denominator gains the new clause's
two outcomes and both are covered. Gate raised to 99.30.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the MISRA loop exits by interposing the shims they test</title>
<updated>2026-09-16T14:34:54Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T14:34:54Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=aadf783554427b8b298cb9a26e6beb569c6bca68'/>
<id>urn:sha1:aadf783554427b8b298cb9a26e6beb569c6bca68</id>
<content type='text'>
Under TX_MISRA_ENABLE three kernel loops test a value produced by a function
whose whole body returns a constant, so the arm that goes round again cannot
execute; the six configurations without the macro compile a plain call, with no
loop and no branch at all. Two of the three are the mutex put's prioritize loops
and the third is the timer thread's own body.

Two new tests define those shim functions themselves. The kernel is built shared
and every internal call to either goes through the procedure linkage table, so
the executable's definition is the one the kernel reaches and no build file
changes. A shim that withholds success on alternate calls sends each mutex loop
round exactly twice; the prioritize processing runs unaltered and is idempotent,
so the release still leaves the mutex unowned, the suspension list empty and the
inherited priority given back, which the test asserts. The timer thread's loop is
that thread's whole body, so leaving it ends the thread: that test proves the
timer is doing its work first, arms the shim last, and depends on no tick
afterwards. Both files record which symbol they replace, why replacing it
preserves what surrounds it, and where the replaced function's own coverage comes
from -- the other tests, which call both shims through these same constructs.

798/798 in each of the seven configurations. Union coverage is 4383/4383 lines
and 3147/3168 branches against 3144 before, the three being one loop exit each;
no other outcome moved. Gate raised to 99.25.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the stack check's null arm by constructing an idle system</title>
<updated>2026-09-16T14:29:51Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T14:29:51Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=80350f23c17f978468fabb91775237bf660c17ec'/>
<id>urn:sha1:80350f23c17f978468fabb91775237bf660c17ec</id>
<content type='text'>
Four scheduler services check the stack of the thread they are about to hand the
processor to, and reach that check through a test of whether it differs from the
thread that is running. An idle system satisfies that test with no thread to
execute at all, and the kernel counts the case explicitly, but no ordinary
sequence produces it: the one path that leaves no thread to execute returns to
the scheduler from inside the suspend, without reaching any of the four.

A new test clears the thread to execute and enters one of the four services
inside a single interrupt lockout, so the tick cannot put a thread back between
the clear and the test the service makes of it. The ready list, the priority map
and the highest ready priority are left correct, so the first scheduler operation
afterwards recomputes the pointer; a periodic one-tick timer runs throughout, so
each idle period ends at the next tick rather than at a retry. The test asserts
that the thread was rescheduled and is the thread to execute again, so a service
that returned without going through the scheduler fails it rather than covering
nothing.

784/784 in each of the seven configurations. Union coverage is 4383/4383 lines
and 3144/3168 branches against 3140 before, the four being the null arm at each
of the four sites; no other outcome moved. Gate raised to 99.15.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Added the MISRA event trace configuration, completing the denominator</title>
<updated>2026-09-16T02:43:06Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T02:43:06Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=025ca0b827f7a42da059ad853889c1665ace5930'/>
<id>urn:sha1:025ca0b827f7a42da059ad853889c1665ace5930</id>
<content type='text'>
common/src/tx_misra.c holds a region behind TX_ENABLE_EVENT_TRACE with six
functions in it: the MISRA form of the in-line trace insert and five pointer
conversions the trace sources use. No build configuration compiled it. misra_build
defines TX_MISRA_ENABLE alone and trace_build defines TX_ENABLE_EVENT_TRACE alone,
so the region was absent from the coverage denominator rather than uncovered in
it - which is the reason misra_build was added in the first place.

misra_trace_build defines both. It needs TX_SOURCE_CODE as well, because
tx_misra.c is the only one of the 185 files in common/src that does not define it
for itself and the prototypes for those five conversions sit behind it in
tx_trace.h; without it the file defines five functions with no previous
declaration and the build fails. The define goes on the kernel target rather than
on every target, because TX_SOURCE_CODE also suppresses the public API mappings
that the tests and the sample need. Its empty value matches the plain define the
other 184 files carry, so no object code changes in any configuration. The defect
itself is in the header and is reported upstream as eclipse-threadx/threadx#745.

The existing trace tests drive the region as it stands: all twelve outcomes of the
insert and all but one line arrive covered without new work. The exception is
_tx_misra_entry_to_uchar_pointer_convert, whose macro no kernel source uses at
all, so the MISRA shim test asserts it alongside the conversions it already
covers.

common/src is at 4383/4383 lines and 3140/3168 branches unioned over the seven
configurations, up 44 lines and 12 outcomes on the denominator and covering all
of them. The 28 uncovered outcomes are the same 28 in the same 14 files as before.
111/111 tests pass in each of the seven.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Removed the thread sleep test's unbuildable interrupt condition block</title>
<updated>2026-09-16T00:10:45Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T00:10:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=3ee247e32de97f95ca0e6265bed76d0537e3dcf2'/>
<id>urn:sha1:3ee247e32de97f95ca0e6265bed76d0537e3dcf2</id>
<content type='text'>
Six conditional regions in the thread sleep test sit behind TEST_INTERRUPT_CONDITION,
a macro no build in the repository defines. Between them they hold an adaptive
calibration loop, a delay function, a semaphore and eleven file-scope variables,
none of which is ever compiled. Left in place they read to any later reader as
though the kernel path they target has a dedicated test, when it does not; that
path is covered by other tests.

The regions are removed, along with the two kernel headers whose only users in the
file were inside them and a commented-out define that only enabled prints inside
them. Nothing outside the regions is touched, and the SMP copy is left alone.

Merged coverage over the six build configurations is bit identical across the
deletion: 4339/4339 lines and 4599/4627 branches, with zero lines and zero branch
outcomes differing anywhere in common/src. 111/111 tests pass in each of the six.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the trace object registry's name copy and reuse choice</title>
<updated>2026-09-16T00:04:48Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-16T00:04:48Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=a598c69127812800d950cc3b3f3500ae105ea77b'/>
<id>urn:sha1:a598c69127812800d950cc3b3f3500ae105ea77b</id>
<content type='text'>
The trace object registry carried three decisions ordinary use never reaches.
The name copy stops at the string's terminator, so it never left the loop by its
own count; it had no caller that passed no name at all, so the check that
recognises one was never true and the line behind it never ran; and the search
that reuses an old entry prefers a later free entry to an earlier one unless the
earlier one has never held a valid object, which nothing the kernel registers
produces.

A new regression test creates one object whose name is longer than a registry
entry keeps room for and one with no name at all, and asserts the entry each
leaves behind. It then fills the registry, registering one entry with the object
type the registry treats as not valid, frees that entry last so the search starts
there, and registers again - so the search meets a free entry that has never held
a valid object and keeps it rather than moving on. The test asserts the new
object landed in that entry.

The registry is now at 65/65 lines and 42/42 branches, and common/src is at
4339/4339 lines - every line of the certified source is reached in at least one
of the six build configurations. Branches are at 4599/4627, up 3 outcomes and the
last uncovered line, with the gates raised to 99.95 and 99.30 to hold them.
111/111 tests pass in each of the six.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the trace inserts in the tracing machinery's own services</title>
<updated>2026-09-15T23:59:33Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-15T23:59:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=c17b34f5511addf1bbcce9e4aaffe176b109f168'/>
<id>urn:sha1:c17b34f5511addf1bbcce9e4aaffe176b109f168</id>
<content type='text'>
Five in-line trace inserts sit in the trace component itself rather than in a
service that uses it: two in the enable, one in the interrupt control, one in
each of the two inserts a port's interrupt shim makes around an ISR, and one in
the user event insert. Between them they scored four to seven of the twelve
branch outcomes the macro carries.

A new regression test walks the four ordinary ones once per condition the macro
distinguishes: tracing off altogether, thread context with every event enabled,
their three event classes filtered out, interrupt context through the test ISR
dispatch, initialization context, the state an interrupt presents, and a
positioned buffer wrap with and without a buffer-full notification registered.
None of these services has an error checking shell in front of it and none
refuses a caller on the strength of the system state, so the published entry
points reach every insert in every state. The interrupt control is driven as the
kernel's own lockout macros drive it, a disable whose returned posture is handed
straight back, so the pair is balanced whatever posture it is called in. The
buffer is positioned and the service called under one lockout, because the tick's
own ISR inserts would otherwise take the boundary.

A second test drives the two inserts the enable writes itself. They run a few
lines after the buffer pointer and the event enable bits are both set, so the
only things left free are the system state, whether the buffer holds a single
entry, and what a notification called from inside the first insert does before
the second runs. The enable is given a buffer sized from the kernel's own
structures to hold exactly one event, with three notifications: one that counts,
one that filters the running event's class, and one that turns tracing off - the
shape an application capturing a single bufferful of history uses.

Four of the five inserts now score twelve of twelve. The user event insert
reaches eleven: its own guard on the buffer pointer, a few lines above and inside
the same lockout, makes the insert's null arm unreachable. The enable's first
insert reaches ten for the same kind of reason - the buffer pointer and the
enable bits are assigned above it. Merged over the six build configurations:
4338/4339 lines and 4596/4627 branches, up 36 outcomes, with the branch gate
raised to 99.20 to hold them. 110/110 tests pass in each of the six.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the MISRA compliance shim's stack check and conversions</title>
<updated>2026-09-15T23:52:09Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-15T23:52:09Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=b17aad1760dc2557f3f79545f07dfab346d63391'/>
<id>urn:sha1:b17aad1760dc2557f3f79545f07dfab346d63391</id>
<content type='text'>
A MISRA build routes the kernel's pointer conversions, its user timer derivation
and its thread stack check through functions in the compliance shim. Four of
them had no caller in any build configuration: the stack check and the user
timer derivation are only reached from code the shim's own configuration
compiles out, and two of the conversions are only used by the trace sources,
which a MISRA build does not compile either. The shim carried 24 uncovered lines
and 14 uncovered branch outcomes, all of it certified source.

A new regression test drives each of them through the macro the kernel itself
uses, so the shim and the in-line form the other five configurations compile are
asserted to agree. The stack check is the one with logic in it, and it is driven
the way the in-line form is: a scratch thread is created on a buffer of the
test's own with a fence on each side, given one fault at a time, and checked with
the fault in place. The faults reach the stack going deeper than recorded, each
of the two fences overwritten, the lowest recorded pointer dropped below the
stack, the word under that pointer used, a control block that is no longer a
thread, and no thread at all. Nothing is written outside the scratch thread's
control block and its own fenced stack, and the thread is never started, so no
faulted state is ever visible to the scheduler.

The compliance shim is now at 81/81 lines and 18/18 branches. Merged over the
six build configurations: 4338/4339 lines and 4560/4627 branches, up 24 lines
and 14 outcomes, with the gates raised to 99.90 and 98.40 to hold them. 108/108
tests pass in each of the six.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Decorrelated the wait abort ISR test's interrupt source from the thread it samples</title>
<updated>2026-09-15T22:16:00Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-15T22:16:00Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=01433b19f3882da82b507143c6843b441b1f5701'/>
<id>urn:sha1:01433b19f3882da82b507143c6843b441b1f5701</id>
<content type='text'>
threadx_thread_wait_abort_and_isr_test waits for the periodic timer interrupt to
land while the preempt disable flag is set. The same interrupt also puts the
semaphore that wakes the thread being sampled, so the two run in lockstep: the tick
wakes thread 0, thread 0 does a fixed amount of work and suspends, and the next tick
arrives a fixed interval later with thread 0 in the same place every time. That is
the resonance the ISR's own comment describes, and perturbing the handler's duration
only shifts the phase rather than breaking the correlation. The window itself is a
few instructions wide, so a sampler locked to the thread's own cycle can miss it
indefinitely.

The simulator's timer thread waits on _tx_linux_timer_semaphore with a one-tick
deadline and delivers an interrupt early when the semaphore is posted, which the
port already relies on elsewhere. The test now runs a plain POSIX thread that posts
it, injecting interrupts at moments unrelated to the tick grid and sampling thread 0
at arbitrary points in its cycle rather than the same one. The injector posts only
when nothing is outstanding, so interrupts can never be queued faster than they are
serviced. It is confined to the Linux simulation port and no port file changes.

Measured over eight runs each, one configuration, before and after: the loop went
from 2 to 17 seconds, mean about 10, to under 2 seconds with the variance collapsing
as well, which is the decorrelation rather than merely more sampling.

The count of windows asked for goes back to ten, which is what it was before it had
to be lowered to three to fit a budget. The reasoning for three was to ask for what
a run can actually reach; a run now reaches ten in one to three seconds, against the
148 to 726 seconds the unbounded version took for the same ten. The budget and the
zero-window ceiling stay exactly as they were, so a run that somehow still falls
behind behaves as it does today.

Across the six build configurations the test now takes 0.21 to 0.99 seconds each,
against 43 to 181 previously, with three of the six formerly pinned at the budget.
107 of 107 tests pass in every configuration and merged coverage is unchanged at
4314/4339 lines and 4546/4627 branches, identical line for line and branch for
branch.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Covered the byte pool services' trace inserts and the allocate's trace update</title>
<updated>2026-09-15T21:06:17Z</updated>
<author>
<name>Frédéric Desbiens</name>
<email>frederic.desbiens@eclipse-foundation.org</email>
</author>
<published>2026-09-15T21:06:17Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/threadx.git/commit/?id=875412db1179a0778592735971d41b7707379dbe'/>
<id>urn:sha1:875412db1179a0778592735971d41b7707379dbe</id>
<content type='text'>
The six in-line trace inserts in the memory byte pool services were reached in
one system state only, so each scored one or five of the twelve branch outcomes
the macro carries.

A new regression test walks the six services once per condition the macro
distinguishes: thread context with every event enabled, the byte pool trace
event class filtered out, interrupt context through the test ISR dispatch,
initialization context, the state an interrupt presents, and a positioned buffer
wrap with and without a buffer-full notification registered. Only the prioritize
and information services are driven from the ISR: the shell rejects a byte
allocate and a byte release from an interrupt outright, where the block pool
permits an allocate that does not ask to suspend. The forced-state passes drive
the internal entry points, and no byte pool service reads the system state
itself, so the internal entry point reaches every insert in every state. The
byte pool search restores interrupts to their previous posture rather than
enabling them outright, so the lockout the forced-state pass holds survives the
allocate.

A second test drives the allocate service's trace update in place, the same way
its block pool counterpart is driven: the path that finds memory immediately,
the path that suspends until a release hands it some, and then the suspending
path again with the trace buffer written all the way round while the thread is
suspended, so the service correctly declines to update an entry that now belongs
to a different event.

Every byte pool insert now scores twelve of twelve, and the subsystem is at
413/413 lines and 381/382 branches. The one outcome left is the same one the
block pool leaves: the arm that needs an event written over the same slot
between the insert and the check on the immediate path. Merged over the six
build configurations: 4314/4339 lines and 4546/4627 branches, up 5 lines and 64
outcomes, with the gates raised to 99.30 and 98.00 to hold them.

Assisted-by: Claude Code (Opus 5) &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
