| Age | Commit message (Collapse) | Author |
|---|
|
Every SMP build configuration is compiled with -DTX_REGRESSION_TEST, which opens
a block in the Linux SMP port header defining ten macros that expand to live code
-- flag tests, state changes and calls -- at eleven sites in common_smp/src. An
application defines none of them and tx_api.h expands them all to nothing, but
gcov attributes a macro expansion to the file that invokes it, so the harness's
own scaffolding was being counted as certified source.
coverage_union.py now drops those sites and prints what it dropped, covered and
total on both axes, so the exclusion can be audited rather than inferred. One
site keeps its line: tx_api.h defines TX_TIMER_INITIALIZE_EXTENSION as a real
statement under TX_MISRA_ENABLE, so that line ships and only its branches come
out. A listed site that no longer matches the report is a hard failure naming the
macro, not a silent skip. The branch gate moves 99.05 to 99.04 because the margin
is ten outcomes rather than a percentage, and a smaller denominator buys nine at
the old value; the line gate is unchanged.
The excluded code measured 10 lines and 36 branch outcomes, every one of them
covered, so the uncovered set is untouched: the same 24 outcomes at the same 22
sites in the same 13 files, over the same 194 files. Eight configurations from a
wiped tree, 136/136 tests in each, 0 failed. The union goes from 5449/5450 lines
and 3588/3612 branch outcomes to 5439/5440 and 3552/3576, re-derived key by key
against the previous measurement. gcovr's merged report is published unchanged.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The comment added in the previous commit said six outcomes in the figure have
no configuration to cover for them. That was the count of outcomes that both
have a single carrier and were seen moving between runs, not the count of
single-carrier outcomes, and as written it is wrong.
Measured over sixteen runs at two commits: thirty-five outcomes are compiled by
two configurations and covered by only one of them in at least one run, almost
all TX_THREAD_STACK_CHECK fence ordinals that stack_checking_build holds alone
because its random-fill sibling short-circuits before them. A further 894 are
compiled by exactly one configuration at all, which is structural rather than
fragile, the racing outcome excepted. The margin's justification is restated on
the figure that actually sizes it: the largest movement observed in any one
configuration is eight outcomes, and the margin is ten.
No threshold changes. The gate stays at 99.79 line and 99.05 branch, and
sixteen runs read 5449/5450 lines and 3588/3612 branch outcomes on the union
basis with an empty unstable set on both axes.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The gate's comment left open whether the ten-line, ten-outcome margin could be
removed once the unstable set closed, and deferred the answer to the coverage
evidence work. It has now been measured.
The thresholds do not move, and the comment records why. Read per configuration
over eight CI runs at one commit, eight branch outcomes and four lines move
between runs, and six outcomes in the published figure are compiled by only one
configuration that covers them: five TX_THREAD_STACK_CHECK arms that
stack_checking_build carries alone in most runs, because
stack_checking_rand_fill_build misses them in seven and four runs of eight, and
the trace race outcome, which only trace_build compiles. The union figure is
stable because the eight configurations cover for each other, not because the
suite is deterministic, so a zero-margin gate would read a runner's timing as a
regression.
Eight runs at the preceding commit read 5449/5450 lines and 3588/3612 branch
outcomes identically on the union basis, unstable set empty on both axes,
136/136 tests in each of the 64 configuration-runs. gcovr's merged report over
those same runs reads 6561, 6563 and 6564 of 6601, which is the same movement
seen through a denominator that does not collapse it.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The coverage ratchet sat at 99.03 branch, set below the 3587 outcomes every run
of the previous sample reached. Covering the user event insert's disabled-buffer
arm moves that floor by one.
Raised to 99.05, still ten outcomes below the set covered in every run, which is
now 3588 of 3612. The line gate is unchanged at 99.79: neither the line total
nor its denominator moved. The comment above the thresholds gains the one thing
about this figure a later reader has to know -- a single outcome in it is
reached by two cores racing rather than by a thread doing something in order,
and it is counted in the always-covered set on a measurement over ten runs on
two machines rather than on one sample.
Seven CI runs at the test head, all green, 136/136 in each of eight
configurations, 5449/5450 and 3588/3612 in every one. Two clean local cycles
read the same two totals.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
_tx_trace_user_event_insert tests the trace buffer pointer and returns
TX_NOT_DONE if it is null; the insert sits in the else, and the macro reads the
same variable and tests it again a few instructions later, inside one
protection with nothing between. The second test's false arm had no route on one
core and was carried as unreachable.
It is an ordinary state of the running kernel on SMP, and no fault has to be
invented for it. _tx_trace_disable clears that pointer and takes no lock of any
kind, so a thread disabling tracing on one core while another is inside the
insert clears it under that core. A new test drives 300,000 inserts against a
second thread on a core of its own writing the same store the disable service
writes. No kernel symbol is replaced and both services run their own code from
end to end; the test asserts that the two threads held different cores and that
the writer's stores reached the service, and says in the file that the arm
itself is evidenced by the coverage report because nothing outside the macro can
observe it.
The pass count is sized from measurement on the slower of two machines. The arm
is taken 49 to 132 times per run on this workstation over three runs and 521 to
1298 times per run on a CI runner over seven.
136/136 in each of eight configurations, twice from clean, 3588/3612 branch
outcomes on the union basis against 3587/3612 before. Fifty standalone repeats
in each of the eight, no failures.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The coverage ratchet sat at 99.79 line and 98.97 branch against a branch
denominator of 3610. The port hook's new clause adds two covered outcomes to
tx_byte_allocate.c, so the denominator is 3612, and the sweep closed two further
outcomes on top of that.
The branch gate goes to 99.03, still ten outcomes below the 3587 of 3612 covered
in every run of the sample. The line gate is unchanged at 99.79: neither the
line total nor its denominator moved. The comment above the thresholds records
why the denominator moved, and that the unstable set is now empty in two
consecutive samples on two different trees rather than one. The margin stays for
the reason it was kept before -- five earlier samples moved an outcome in every
direction there is -- and whether it can go is the evidence step's question.
Seven CI runs at the sweep head, all green, 135/135 in each of eight
configurations, 5449/5450 and 3587/3612 in every one. Two clean local cycles
read the same two totals.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The byte allocate records a trace event on the way in, saves the entry's time
stamp, and comes back to write the address it returned into that same entry --
but only if the time stamp says nothing overwrote the entry meanwhile. Nothing
in the kernel writes a trace event inside the window, so the other arm had no
agent and no test.
The Linux SMP port's TX_BYTE_ALLOCATE_EXTENSION gains a second clause, guarded
by its own flag and calling a routine the harness declares weakly, in the shape
TX_BYTE_RELEASE_EXTENSION already uses. The hook runs between the restore and
the disable that bracket the pool search, which on SMP is a real release of the
protection rather than an interrupt gap. 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 lets the hook write a user event onto it; neither lever
reaches the arm without the other. No kernel symbol is replaced and the allocate
runs its own code end to end. The macro expands inside tx_byte_allocate.c, so
the new clause's if is certified-source branch: the union branch denominator
moves from 3610 to 3612 and both new outcomes are covered.
The arm closes in trace_build alone. Under TX_MISRA_ENABLE the port's trace time
source returns a constant, so the comparison reads 0 == 0 whatever the hook
writes, and the test asserts the consequence only where the time source is real.
135/135 in each of eight configurations, 3586/3612 branch outcomes on the union
basis against 3583/3610 before. Fifty standalone repeats in each of the eight,
no failures.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The coverage ratchet sat at 99.32 line and 97.42 branch, set below the 5423
lines and 3527 branch outcomes every run of the previous sample reached. The
initialize, trace and MISRA shim batch has moved both floors.
Raised to 99.79 and 98.97, still ten lines and ten outcomes below the set
covered in every run of the sample, which is now 5449 lines and 3583 outcomes of
5450 and 3610. The comment above the thresholds is rewritten around the fact
that made this sample different: all seven runs read the same two totals, so the
unstable set is empty for the first time and the always-covered floor and the
worst observation coincide. The margin stays, because five earlier samples moved
an outcome in every direction there is, twice on the pair this batch has just
closed; whether it can go is the evidence step's question and not this one's.
Seven CI runs at the batch head, all green, 134/134 in each of eight
configurations, 5449/5450 and 3583/3610 in every one. Two clean local cycles
read the same two totals.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The two inserts the trace enable writes read an event class the same call sets
to all ones a few hundred lines above them, so from inside the enabling thread
neither can find it disabled. A buffer-full notification reaches the second one,
because it is called from inside the first; the first has no lever of that kind
and sat at 10 of 12.
SMP has one the monoprocessor does not, and it is an arrangement rather than a
race because the enable blocks. tx_trace_event_filter is an unprotected
read-modify-write of the enable bits, while the enable takes the SMP protection
after setting them and long before either insert, so a thread already holding
the protection on another core parks the enable there for as long as it likes. A
new test takes the protection from a core of its own, waits for the bits, clears
every class and releases; the enable runs on and both inserts find the class
gone. It asserts the consequence rather than the timing - neither insert wrote
an entry, so the buffer is where the enable left it.
A first version that waited for the window instead of holding it open was
measured and discarded: it failed 11 runs of 400, and widening the window
eightfold only took that to 3 of 100. tx_trace_enable.c:391 goes to 11 of 12 and
:392 stays at 12. 133/133 in each of the eight configurations, and 50 standalone
repeats of the new test green in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The trace object registry carried one uncovered line and three uncovered branch
outcomes. The name copy stops at the string's terminator, so it never left the
loop by its own count and never met a caller passing no name at all. The search
that reuses an entry prefers a later free one unless the earlier one has never
held a valid object, and nothing the kernel registers produces an entry that is
both in use and of no valid type.
A new test registers an object whose name is longer than a registry entry keeps
room for, one with no name, and one of the type the registry treats as not
valid. It then fills the registry, frees the not-valid entry last so the search
starts there, registers again, and asserts the new object landed in the entry
the search kept rather than in the later free one. The registry is rearranged
under one SMP protection, because every service that creates an object writes
it.
tx_trace_object_register.c goes to 66/66 lines and 42/42 branch outcomes on the
union of the eight configurations, from 65/66 and 39/42. 133/133 in each of the
eight, and 50 standalone repeats of the new test green in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The enable records two running events so that a buffer handed to an analysis
tool is never empty, and those two inserts are the only ones in the kernel that
run inside the service that turns tracing on. The buffer pointer and the event
enable bits are both set a few lines above, so neither can be found in any other
state on the way in, and both inserts sat at 4 of 12.
A new test enables with a buffer sized from the kernel's own structures to hold
exactly one event, which puts both inserts on the wrap boundary, and with three
notifications: one that counts, one that filters the running event's own class,
and one that turns tracing off. The last two are what reach the second insert's
filtered and no-buffer arms, and both are ordinary application behaviour rather
than a contrivance - a notification that stops tracing is what an application
capturing a single bufferful of history does. The forced-state passes hold one
SMP protection across the write, the enable and the restore.
tx_trace_enable.c:392 goes to 12 of 12 and :391 to 10 of 12 on the union of the
eight configurations, from 4 each. The two arms left are the first insert's own
copies of the filtered and no-buffer tests, which nothing can reach between the
assignments above it and the insert. 133/133 in each of the eight, and 50
standalone repeats of the new test green in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The interrupt control, the two ISR inserts and the user event insert are part of
the tracing machinery rather than users of it, and nothing drove their inserts
beyond the conditions testcontrol.c and threadx_trace_basic_test.c happen to
present. The two ISR inserts were the whole of this suite's unstable set: their
buffer-wrap arms were reached when the buffer happened to wrap under an insert,
which is why they moved between runs.
A new test walks the services once per condition the insert distinguishes, and
positions the buffer one entry short of its end rather than waiting for it to
wrap, under one SMP protection and asserting the wrap per service. The interrupt
control is driven at the outermost level only, and is left out of the pass that
runs from interrupt context: _tx_thread_interrupt_control takes the Linux
critical section on every call and hands it back in full only on an enable, so a
pair completed where the section is already held leaves it two levels deeper and
locks the process. Its disable half runs inside the protection, where the insert
is, and its enable half once the protection is released. Its own forced-state
passes reach the two arms the interrupt pass would have covered.
All four sites go to 12 of 12 on the union of the eight configurations, from
7, 5, 5 and 6. 133/133 in each of the eight, and 50 standalone repeats of the
new test green in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Three regions of tx_misra.c had no caller in any of the eight build
configurations. The thread stack check is reached through TX_THREAD_STACK_CHECK,
whose call sites sit inside TX_ENABLE_STACK_CHECKING and which is redirected to
the shim only under TX_MISRA_ENABLE, and no configuration defines both. The user
timer derivation's six call sites are behind TX_TIMER_ENABLE_PERFORMANCE_INFO,
three of them behind TX_TIMER_PROCESS_IN_ISR as well. The trace entry conversion
has no caller in common_smp/src at all.
A new test drives all three through the macro the kernel itself uses, so the
shim and the in-line form the other builds compile are asserted to agree. The
stack check is the one with logic in it, and is given a scratch thread one fault
at a time: a cleared identifier, either stack fence overwritten, the recorded
high-water mark moved above the stack pointer and below the stack. That thread
is created with TX_DONT_START on a fenced buffer of the test's own and never
runs, so no faulted state is ever visible to the scheduler.
tx_misra.c goes from 138/163 lines and 16/30 branch outcomes to 163/163 and
30/30 on the union of the eight configurations. 133/133 in each of the eight,
and 50 standalone repeats of the new test green in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The byte pool and block pool batch moved the union figure from 5398 lines and
3399 branch outcomes to 5423 and 3531, and the gate was still set for the figure
before it. A gate that trails the work by a whole batch stops being a ratchet.
Set from the set of lines and outcomes covered in every one of seven CI runs --
5423 and 3527 -- ten lines and ten outcomes below it, which is the basis the
comment above the thresholds describes and the same margin the last four raises
used. The always-covered branch total went 3395 to 3527; the line total, 5398 to
5423.
Seven runs at this tree read 5423 lines in every one of them and between 3527 and
3531 outcomes. Four outcomes at two sites remain unstable and both sites belong
to the trace batch that has not run yet; the line axis has now been stable across
thirty-five runs in five samples.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Where the SMP byte pool search gives the protection up, it checks on taking it
back whether the pool is still its own, and if not it delays, resets the walk and
claims the pool again. Three branch outcomes and eight lines of that were never
executed. The pool owner is written in six places, all of them kernel services,
and none can run on the searching thread's own core while that thread is inside
the walk, so the construct needs a second core in use. The existing contention
test does not reach it because its pool is too small to open the window at all:
the protection is only given up once per multiple block search limit.
A new test keeps the test thread on its own core and puts one claim thread on
each of the others, each making the same unsatisfiable request and so walking the
same pool. A claim thread is then usually already holding the protection when the
test thread reaches a window, which is the state the construct is written
against. The test waits for every claim thread to be mapped and claiming before
it starts searching, rather than sleeping a fixed number of ticks, because how
long the rebalance takes varies by configuration. It asserts the arrangement
rather than the retry, which restores the owner the walk had already set and
leaves nothing a test can read.
Three outcomes and eight lines, measured at 48,971 changes of owner in a run of
2.6 seconds. This is the second test in the suite that needs more than one core.
129/129 in each of eight configurations with retries disabled, and sixty
standalone repeats clean in the three configurations that schedule it slowest.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The SMP byte pool search walks the pool holding the protection and gives it up
every TX_BYTE_POOL_MULTIPLE_BLOCK_SEARCH blocks, so that a long walk does not
lock the other cores out for its whole duration. No test fragmented a pool past
that limit, so the release and the reacquire behind it were never executed and
the branch that guards them stood at one of two. The region has no monoprocessor
counterpart: that search gives the protection up on every block and has no
counter.
A new test fills a pool with small fragments until it refuses another, checks it
broke into at least twice the limit, and then asks for one more. Every block is
then in use or too small, so the search examines all of them and crosses the
limit several times. The walk length is the pool's fragment count plus one and
nothing else runs, so there is no timing in it. The limit is not a feature gate:
tx_api.h defines it to 20 unless the application overrides it, so the region is
compiled in every configuration.
One outcome and three lines, in all eight configurations. 129/129 in each with
retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The byte allocate keeps the same trace update in place the block allocate does,
in the same two regions, and it was uncovered for the same reason: no test had
run the service with tracing enabled, so the entry pointer checks stood at one of
two and the time stamp comparisons at zero of two.
A new test drives it with the three passes the block pool test uses. One
configuration reaches less of it than the others and that is a property of the
port rather than of the test: under TX_MISRA_ENABLE the trace time source is a
routine whose body returns a constant, so every entry carries the same time stamp
and the comparison reads equal whatever has been written over the entry. The
overwritten round drives the same arm as the intact one there, and the arm that
declines to update is reached in the plain trace configuration alone.
Seven of the eight outcomes and all seven lines. The remaining one is the false
arm of the immediate path's comparison. 129/129 in each of eight configurations
with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The block allocate records its event, saves the entry and its time stamp, and
comes back to write the address it handed out into that entry if nothing has
overwritten it. There are two such regions, one on the path that finds a block
immediately and one on the path that suspends. Nothing had ever run the service
with tracing enabled, so the entry pointer checks stood at one of two with only
the false arm taken and the time stamp comparisons at zero of two.
A new test uses two threads and three passes: a plain successful allocate, a
suspending allocate handed a block with its entry intact, and the same handover
with the trace buffer written all the way round in between so the service
correctly declines to update. The helper runs at a higher priority than the test
thread, so every handover is a preemption rather than something that waits for a
tick, and both threads keep the suite's default core mapping so only one of them
runs at a time.
Seven of the eight outcomes and all seven lines. The remaining one is the false
arm of the immediate path's comparison, whose window is one unbroken SMP
protection with no trace insert in it. 129/129 in each of eight configurations
with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Six byte pool services carry an in-line trace insert, and no test in the SMP
suite drove any of them with tracing enabled. Four sites stood at one of twelve
branch outcomes and the create and the delete at five of twelve, so 58 outcomes
of the macro's six conditions were never taken.
A new test walks the six services once per condition, in the shape the block
pool test uses. The two subsystems differ in what an interrupt may call and the
test reads that out of each error checking shell rather than assuming symmetry:
the byte allocate and the byte release are rejected at any non-zero system state
below initialisation, where the block pool permits both, so only the prioritize
and the information get run from the ISR pass here.
58 of 58 outcomes, every site at twelve of twelve. 129/129 in each of eight
configurations with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Six block pool services carry an in-line trace insert, and no test in the SMP
suite drove any of them with tracing enabled. Four sites stood at one of twelve
branch outcomes and the create and the delete at five of twelve, so 58 outcomes
of the macro's six conditions were never taken.
A new test walks the six services once per condition: thread context, the event
class filtered out, interrupt context through the ISR dispatch, initialisation
context, the state an interrupt presents, and a buffer wrap with and without a
notification registered. The last two passes go through the internal entry
points, because the error checking shell rejects a create from an interrupt and
a delete from any caller that is not a thread. The buffer is positioned one
entry short of its end and the positioning and the call are held under one SMP
protection, so the boundary entry is the service's own by construction; the pass
asserts a wrap per service rather than in total.
58 of 58 outcomes, every site at twelve of twelve. 129/129 in each of eight
configurations with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Closing the trace inserts, the zero-request refusal and the two prioritize
retry arms across the semaphore, mutex and event flags sources took the set of
branch outcomes covered in every run from 3195 to 3395, and the set of lines
from 5396 to 5398, so the gate no longer sits ten below either.
Re-derived on the union basis over a fourth sample of seven CI runs: 5398 of
5450 lines and 3395 of 3610 outcomes are covered in every one, and the gate is
set ten below each, at 98.86 and 93.76. What is left unstable is four outcomes
at two sites, up from two at one, and the comment above the thresholds records
why that is not a regression to chase: the buffer-wrap arm of the ISR enter
insert was unstable over fourteen runs, covered in all seven of the next sample
with nothing touching it, and is missed in one run of seven again here. Four
samples have now moved an outcome in every direction the three columns allow.
Seven CI runs at this commit's parent, all green, 123/123 tests in each of eight
configurations, retries disabled, and two clean workstation runs besides. The
line axis did not move within the sample at all.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The SMP priority change helper places a ready thread on its new priority list
and then chooses which priority the thread should carry: the new one if it beats
the priority inherited from a mutex, and the inherited one otherwise. The second
arm and the two lines it guards had never run. Reaching it needs three things at
once — a thread holding an inheritance mutex, ready rather than running, and
being moved to a priority no higher than the one it has inherited — and nothing
in the suite arranged all three.
A new test arranges them. The owner holds two inheritance mutexes with a waiter
on each, so its inherited priority comes from the higher waiter; deleting that
waiter's mutex hands the owner back to the priority the remaining waiter calls
for, which is the inherited priority the helper then has to choose against. The
delete is issued by a thread above both waiters, so the owner is ready and not
running when the change arrives, which is what sends it down the helper rather
than down the full rebalance. Every thread in the suite is mapped to core 0
alone, so this needed no second core.
The site reads two of two and both lines are covered, in all eight
configurations. 123/123 tests pass in each of them, and the new test passes
fifty standalone repeats in every one.
The arrangement is its own test rather than part of the mutex work this batch
wrote anyway: measured with the coverage isolated to a single test, neither the
MISRA prioritize test nor the mutex trace test reaches the helper at all.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Under TX_MISRA_ENABLE the mutex put calls the prioritize processing through a
retry loop, so that the call's result is read and the rule about discarding a
return value is met. The prioritize processing passes a success status through a
shim whose whole body returns success, so the loop's test can only be false on
the first pass and the arm that goes round again never ran. The other six
configurations compile a plain call with no branch at all.
A new test defines the shim itself, which is the technique the monoprocessor
suite already uses for the same two loops. The kernel is built shared and every
internal reference to the shim goes through the procedure linkage table, so the
definition in the test executable is the one reached, with no linker option and
no preloading. A shim that withholds success on alternate calls sends each loop
round exactly twice and leaves the mutex, the suspension list and the priorities
as the kernel expects them. The two loops sit on different paths through a
single put, and one release of an inheritance mutex with two suspended waiters
reaches both.
The shim's reach on this port was measured rather than carried over: objdump
gives one call site in the library, in the prioritize processing, because the
port overrides the other macro that could expand to it. Read the coverage with
that in mind — it is coverage of a kernel whose MISRA shim is the test's, which
the file says in its own header.
Both sites read two of two in the two MISRA configurations. 123/123 tests pass
in each of the eight configurations, and the new test passes fifty standalone
repeats in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The get service refuses to suspend a caller when the preemption lockout is
raised or when the request asks for no flags at all. The first arm is driven by
the suite's own preempt-disable safeguard; the second had no caller anywhere in
the suite, so one of the site's four outcomes was never taken. Measured rather
than inferred: the tracefiles put the uncovered outcome on the zero-request
operand in all eight configurations.
A new test asks the group for no flags under each of the four get options, with
a wait option, and then confirms that the flag it raised beforehand is still
set. The error checking shell places no constraint on the requested flags, so
the published service reaches the refusal with nothing forced. A request for no
flags can never be satisfied — an OR request finds none of the flags it asked
for present, and an AND request has its empty result rejected for not matching
the empty set it asked for — so a caller that suspended on one would never be
resumed, which is what the check prevents.
The site reads four of four on the union basis, which is the only genuine
control logic this group had. 123/123 tests pass in each of the eight
configurations, and the new test passes fifty standalone repeats in every one of
them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The six event flags services carry the same in-line trace insert as the
semaphore and mutex ones, with the same twelve outcomes from six conditions.
Four of the six sites had never run the macro body and the create and the delete
reached five outcomes of twelve, for the same reason: one test of 117 enabled
tracing.
A new test applies the pattern to the event flags services. The flag the set
raises is consumed by the get that follows it and the scratch group is created
by the first service and deleted by the last, so a pass leaves the system as it
found it. The set notification service is compiled out under
TX_DISABLE_NOTIFY_CALLBACKS and returns from above its own insert, which the
per-service expected-status function absorbs.
All six event flags trace sites read twelve of twelve, and the ten tx_event_
files are at 323/323 lines and 206/206 branch outcomes on the union basis. With
this the twenty trace inserts across the three subsystems are closed and the
thirty-three files of the group are at 1074/1074 lines. 123/123 tests pass in
each of the eight configurations, and the new test passes fifty standalone
repeats in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The six mutex services carry the same in-line trace insert as the semaphore
ones, with the same twelve outcomes from six conditions, and the same cause left
them uncovered: only one test in the suite enabled tracing. Four of the six
sites had never run the macro body and the create and the delete reached five
outcomes of twelve.
A new test applies the pattern to the mutex services. The subset an interrupt
may drive is narrower here and is decided by the shell rather than by the
service: the error checking shell rejects a create, a get and a put from an
interrupt and a delete from any caller that is not a thread, which leaves the
prioritize and the information service for the interrupt pass. The resident
mutex is created TX_NO_INHERIT deliberately, so a release with nothing suspended
takes the simple path and leaves the calling thread's priority alone; the
inheritance paths have tests of their own and nothing here depends on them.
All six mutex trace sites read twelve of twelve. The eleven tx_mutex_ files are
at 471/471 lines and 310/312 branch outcomes on the union basis; the two left
are the exit arms of the TX_MISRA_ENABLE release loops, which are unreachable by
construction and carry their own record. 123/123 tests pass in each of the eight
configurations, and the new test passes fifty standalone repeats in every one of
them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Each of the eight semaphore services carries one in-line trace insert, and the
macro scores twelve branch outcomes from six conditions: whether tracing is
enabled, whether the event class is filtered, what system state the caller is
in, whether the entry wraps the trace buffer, and whether a buffer-full
notification is registered. One test of 117 enabled tracing, so six of the eight
sites had never run the macro body at all and the create and the delete reached
five outcomes of twelve.
A new test walks the services once per condition, in an order that leaves the
system as it found it. The create and the delete are driven through their
internal entry points in the forced-state passes, because the error checking
shell rejects them from a non-thread caller and the insert sits behind it. The
positioning and the call are held under one SMP protection, so the boundary
entry is the service's own by construction rather than by being quick enough,
and the pass asserts a wrap per service so that a service whose slot was taken
by something else fails here instead of losing coverage quietly. One entry short
is the right distance: every one of these inserts sits ahead of its own counting
and suspension logic, so nothing the service goes on to do writes in front of
it.
All eight semaphore sites read twelve of twelve, and the twelve tx_semaphore_
files are at 280/280 lines and 194/194 branch outcomes on the union basis.
123/123 tests pass in each of the eight configurations, and the new test passes
fifty standalone repeats in every one of them.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Closing the ready-list walk in the time-slice rebalance took the set of branch
outcomes covered in every run from 3194 to 3195, so the gate no longer sits ten
outcomes below it.
Re-derived on the union basis over a third sample of seven CI runs: 5396 of 5450
lines and 3195 of 3610 outcomes are covered in every one, and the gate is set
ten below each, at 98.82 and 88.22. The line threshold does not move. What is
left unstable is two outcomes at one site, the buffer-wrap arm of the ISR exit
trace insert, down from five at three sites. The comment above the thresholds
records all three samples, including an outcome that came back covered in every
run of the third with nothing touching it.
Twenty-one CI runs across the three samples, all green, 117/117 tests in each of
eight configurations, retries disabled. The margin earned itself immediately: the
first clean workstation run after it was set read 3194, one outcome below the CI
floor, on a stack check covered in all twenty-one CI runs.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
When a thread's time slice expires the kernel moves it to the end of the ready
list at its priority and walks the rest of that list looking for a thread to
hand the core to, stopping at the first one it can use. The walk only runs to
the end when every other thread at the priority is already the thread its own
core is executing. Two tests reached that by accident of scheduling -- one in
ten of twenty-five standalone runs -- so the arm read covered in twelve of
fourteen CI runs and missed in two, which is neither a gap nor coverage.
It needs more than one core in use, which is why nothing reaches it on purpose:
with every thread mapped to core 0 alone there is one executing thread, and the
walk stops at the first thread it looks at. A new test clears the core
exclusions on three workers at one priority so they run one to a core, then
asserts the arrangement instead of waiting for it. Two of the three ways out of
the walk are ruled out before it runs, so the only early exit left is the one
that hands the core over -- and that one overwrites the core's entry in the
execution list, so the entry still holding the same thread afterwards means the
walk ran to the end. The arrangement, the expiry and the check are held under
one SMP protection, and the expiry is driven by calling the routine the timer
interrupt calls, inside the protection the timer interrupt holds when it calls
it.
The arm is taken in 30 of 30 standalone runs against 10 of 25 before, and the
test is green in 50 consecutive runs in each of the eight configurations. It is
a tx_thread_ construct in a timer batch, deliberately: it belongs to a batch
that closed two steps ago and no remaining batch would reach it.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The gate's thresholds were derived from one sample of seven CI runs, taken a
commit before the one they ship with. A second sample of seven has since been
taken at the head, and it puts the same 5396 lines and 3194 branch outcomes in
the always-covered column and the same five outcomes in the unstable one.
The comment above the thresholds now states both samples and the fact that they
agree. The thresholds themselves do not move: a floor two independent samples
report identically is the one the gate was already set ten lines and ten
outcomes below.
Fourteen CI runs, all green, 116/116 tests in each of eight configurations,
retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The gate held the floor the thread tests left, 98.78 line and 85.95 branch on
the union of the eight configurations. The timer and time batch has since
closed 82 of its 84 branch outcomes and both of its uncovered lines, so the
threshold is well below what the tree now reaches and no longer stops a
regression in this batch from passing.
Re-derived on the union basis over seven CI runs at the head of the batch:
5396 of 5450 lines and 3194 of 3610 branch outcomes are covered in every one of
them, and the gate is set ten lines and ten outcomes below each, at 98.82 and
88.20. The line figure is now identical in all seven runs -- the two lines that
used to move were the wrapped arm of the timer list calculation, and a test now
builds the arrangement instead of waiting for the tick to produce it. Five
branch outcomes still move: the buffer-wrap arms of the two ISR trace inserts,
and the exit arm of the ready-list walk in tx_thread_time_slice.c, which was
covered in all seven runs of the previous sample and so appeared on no list.
The seven runs read 3194, 3195, 3195, 3195, 3197, 3199 and 3199 of 3610, all
green, 116/116 tests in each of eight configurations, retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The timer thread's body is one loop whose controlling expression is, under
TX_MISRA_ENABLE, a call to a function that returns a constant rather than the
literal the other six configurations compile. The exit arm therefore never
executes, and in the configurations without the macro gcc folds the condition
and the branch does not exist at all.
The function has no behaviour of its own -- its whole body is return(TX_TRUE)
-- so the test defines it. The kernel is built shared and every internal
reference goes through the procedure linkage table, so the definition in the
test executable is the one the loop reaches, with no linker option and no
preloading. It has exactly two callers in the library: this loop, and the
initialisation loop in _tx_thread_smp_current_state_set, which is reached only
from the three initialisation paths that run before the scheduler starts a
thread and so cannot be reached from a running test.
What that costs is the timer thread, because the loop is the whole of its entry
function. The test therefore does it deliberately and last: it proves three
expirations have been processed, arms the shim, waits for the thread to end,
and reports. Nothing after the arming depends on a tick. The test file carries
the disclosure this needs -- which symbol is replaced, what the library's
version does, why replacing it leaves the rest intact, and where the replaced
function's own coverage comes from.
tx_timer_thread_entry.c:112 reads two of two in misra_build and
misra_trace_build. The file stands at 73/73 lines and 28/30 branch outcomes;
the two left are the spin-on-error loops over _tx_thread_smp_core_exclude,
which has behaviour of its own. 116/116 tests pass in each of eight
configurations, twice from clean, with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The active timer list is a ring of thirty-two slots and the current pointer
walks it one slot a tick. A timer activated for close to a full lap lands on a
slot the pointer has already passed, and the information service then measures
the time remaining in two parts rather than one. Which slot a timer lands on
depends on where the pointer happens to be when it is activated, so the suite
reached that arm by coincidence: the branch and its two lines were covered in
some runs of an unchanged tree and missed in others, which is the whole of the
line variance in this suite and one of its five unstable branch outcomes.
A new test reads the current position first and chooses the activation from it,
with the read, the activation, the interrogation and the deactivation held
under one SMP protection so the tick cannot move the pointer in between. It
asserts the arrangement rather than the answer: the two arms compute the same
number of ticks by design, so a test that checked only the returned count would
pass without having reached either one in particular. Three arrangements are
driven -- the slot ahead of the pointer, the slot behind it, and the slot
behind it on a timer carrying more ticks than the list can represent.
tx_timer_info_get.c reads 37/37 lines and 38/38 branch outcomes, in every one
of the eight configurations and in both clean runs, which is what the
coincidence never gave. 116/116 tests pass in each of eight configurations,
twice from clean, with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
One test of the ThreadX SMP regression suite enables event tracing, so the
in-line trace insert each timer and time service carries ran almost everywhere
with a null trace buffer pointer and scored one of its twelve branch outcomes.
Eight sites sat at one or five of twelve, 80 uncovered outcomes in all.
A new test walks the eight services once per condition the macro distinguishes:
thread context, both event classes filtered out, interrupt context,
initialization context, the state an interrupt presents, and a positioned
buffer wrap with and without a full notification registered. The timer services
and the time services score against different event classes, so the filtered
pass filters both. One entry is the right wrap distance for all eight: no timer
or time service writes an event buffer entry ahead of its own insert, and every
service in the notified pass has to report a wrap of its own, so a boundary
entry taken by something else fails the test rather than quietly losing
coverage.
One service is driven through its internal entry point in every pass rather
than only in the forced-state ones, and that is the SMP path rather than the
monoprocessor's. tx_api.h remaps tx_time_get() to a direct read of the system
clock unless TX_MISRA_ENABLE is defined, so in six of the eight configurations
the published macro never enters _tx_time_get and the insert inside it is
unreachable from above. The test checks the macro against the service and then
drives the service. The monoprocessor header has no such remapping.
All eight sites read twelve of twelve, taking the tx_timer_ and tx_time_ group
from 170 to 250 of its 252 branch outcomes on the union of eight
configurations. 116/116 tests pass in each of the eight, twice from a clean
tree, with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The ratchet stops later work undoing earlier work, so it has to move when a
batch closes. It was set for the figure before the thread batch: 98.70 line and
80.10 branch on the union basis, against 98.97 and 86.26 now measured.
The gate becomes 98.78 line and 85.95 branch, ten lines and ten outcomes below
the floor a run can honestly reach -- the 5394 lines and 3113 branch outcomes
covered in every one of seven CI runs on this tree. The comment above it records
what moved: the branch spread is down from eight outcomes to three and the
unstable set from eleven to five, because the thread trace test closed the two
buffer-wrap ordinals on the thread resume, thread suspend, system resume and
system suspend inserts, and they are now covered in every run rather than in
some. Two outcomes went the other way, from uncovered in seven consecutive runs
to unstable, which is why the margin is not zero.
Seven CI runs read 5394 to 5396 lines and 3115 to 3117 branches; two clean local
runs read 5396 and 3114 to 3116. 113/113 tests in each of eight configurations,
retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The resume path and the preemption check each compare a core's current thread
against its execute entry and, when they differ, pick the entry up to check its
stack. Both guard that with a null test, because the entry is empty whenever
the core has nothing to run. Neither guard had ever been reached with an empty
entry: a core whose current thread is still set is normally a core that is
running something the scheduler has already chosen a successor for.
A new test constructs the state with tx_thread_smp_core_exclude, which supports
excluding a thread from every core and leaves it ready and permanently
unmapped. The resume pass holds preemption off and one SMP protection across
the whole arrangement, so nothing else observes it: the test thread excludes
itself, resumes a scratch thread that is excluded from every core as well, and
the resume reaches its own preemption check with the execute entry still empty.
The preemption check cannot be driven that way, because returning to the system
is what it is for, so that pass gives the core up and the tick puts the
exclusion mask back once the core has gone idle. A null current thread on core
0 is the signal the tick reads: the port leaves the interrupted thread in that
entry for the whole of an interrupt, so it is empty only when the core had
nothing running, which is the one moment that cannot be confused with the
window before the check runs. The arrangement is repeated, because a tick
landing in that window costs the attempt rather than the test.
Two branch outcomes close, the last uncovered logic in
tx_thread_system_preempt_check.c and tx_thread_system_resume.c. Both remain
short of 100% branch on the null arm of the stack check behind those guards,
which no valid state produces.
113/113 tests in each of eight build configurations, from clean, with retries
disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
TX_THREAD_STACK_CHECK sits on nine sites in the SMP scheduler and scores seven
conditions at each of them. Ordinary use only ever takes the clean arm of five
of those, so the nine sites sat between eight and eleven of fourteen -- 44
uncovered branch outcomes.
A new test applies one fault to every thread the sites look at, drives one site
with it in place, and takes it out again: the lowest recorded stack pointer put
above the thread's own, each of the two fences around the stack overwritten,
the recorded pointer dropped below the stack, the word under it made used, and
the thread identifier cleared. The fault is applied per step rather than per
pass, because the first site to see a bad recorded pointer repairs it on the
way through. Three sites look at the thread the core is about to run rather
than the one being operated on, and only a time-slice rotation separates the
two, so those steps rotate the ready list and hold preemption off across the
rotation and the service that follows it -- except the preemption check, which
does nothing while preemption is held off. A cleared identifier is
incompatible with the published entry points, so the steps drive the internal
ones. The file also covers the two parts of the stack machinery no fault
reaches: the realignment a create performs when it is handed an odd stack
address, and the error handler's MISRA build, where there is no application
handler to call and the function exists only to keep its argument referenced.
36 of the 44 outcomes close, with one branch and one line in
tx_thread_create.c and two branches and three lines in
tx_thread_stack_error_handler.c. The eight left are the macro's own
null-thread arm. Four of the nine sites guard it in the source with a null test
of their own, so it cannot be taken there at all; four more are handed a thread
the caller has already dereferenced; the ninth, in tx_thread_relinquish,
already takes it.
113/113 tests in each of eight build configurations, from clean, with retries
disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
One test of the ThreadX SMP regression suite enables event tracing, so the
in-line trace insert each thread service carries ran almost everywhere with a
null trace buffer pointer and scored one of its twelve branch outcomes.
Eighteen sites across the tx_thread_ sources sat between one and seven of
twelve, 170 uncovered outcomes in all.
A new test walks the sixteen thread services once per condition the macro
distinguishes: thread context, the thread and internal event classes filtered
out, interrupt context, initialization context, the state an interrupt
presents, and a positioned buffer wrap with and without a full notification
registered. Three things are the SMP path rather than the monoprocessor's. The
system state is a per-core array behind a macro that expands to a function
call, so the forced-state passes define TX_THREAD_SMP_SOURCE_CODE and write the
entry of the core they read back. The time-slice check reaches its insert only
while a slice is active on some core, so the test thread carries one. And the
scheduler's own inserts sit behind the published ones, so the resume and the
suspend are wrapped two entries short as well as one. Every service in the
notified wrap pass has to report a wrap of its own, so a boundary entry taken
by something else fails the test rather than quietly losing coverage.
tx_thread_sleep is the one insert that cannot reach twelve of twelve. The
service tests the system state itself, ahead of its own insert, and refuses
every caller that is not a thread, so the three outcomes that need a non-zero
state have no route through either entry point. It stops at nine of twelve and
the test drives the internal entry point at a forced state to record the
refusal.
167 of the 170 outcomes close and seventeen of the eighteen sites read twelve
of twelve. 113/113 tests in each of eight build configurations, from clean,
with retries disabled.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The gate is the ratchet that stops later work undoing earlier work, so it has to
follow the coverage up. It sat at 98.60 line and 77.30 branch, derived when the
union denominator was still being settled, and the queue trace test has since
closed 103 branch outcomes that no run covered before.
The new floor is 98.70 and 80.10, on the union basis. The worst of nine runs --
seven in CI and two clean local ones -- is 5390 of 5450 lines and 2906 of 3610
branches, so the gate sits ten lines and fourteen outcomes below it. The stale
figures in the comment above it are corrected at the same time: the denominators
are 5450 and 3610, the merged one is 6595, and the eleven branch outcomes that
still move between runs are named.
Fourteen outcomes of headroom rather than the twelve that preceded it, because
an outcome's stability turns out to depend on how many runs have been looked at.
The two ordinals at tx_trace_isr_enter_insert.c:93 were covered in three of seven
runs before this change and in none of seven after it, and nothing here touches
that site. A gate set flush against a worst observation is set against a sample.
Verified: all eight configurations pass 110 of 110 and clear the new gate.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Each of the nine queue services carries one in-line trace insert, and the
insert behaves differently according to the system state it runs in, whether
its event class is filtered, whether it is the entry that wraps the trace
buffer, and whether a buffer-full notification is registered. Exactly one test
in the SMP suite enabled event tracing, so at seven of the nine sites the macro
body never executed at all and the other two reached five of its twelve
outcomes: 91 uncovered branch outcomes in the queue sources, with no test
missing for anything else in the subsystem.
The new test walks the nine services once per condition, in an order that
leaves the system as it found it, so the passes compose and repeat. Two things
are specific to SMP. The system state is per core and is normally reached
through a function call, so the forced-state passes take the array itself and
write the entry of the core they are running on, read rather than assumed. The
wrap pass holds the SMP protection across both the positioning and the service
call, which makes the boundary entry the service's own by construction: every
trace insert in the kernel is written inside that same protection, so nothing
else can take the slot in between. Create and delete are driven through their
internal entry points in the forced-state passes only, because the error
checking shell rejects both from any caller that is not a thread; the shell is
covered by its own tests and what is under test here is the insert behind it.
Nothing is interposed and no certified source is touched.
The queue sources are now at 622 of 622 lines and 394 of 394 branches over the
union of the eight build configurations, from 303 of 394. Twelve further branch
outcomes and six lines outside the subsystem arrive with it, in the MISRA shim,
the trace object registry and the thread suspend and sleep paths. All eight
configurations build clean and pass 110 of 110, twice from clean with retries
disabled, and the new test is green in 75 consecutive runs across three
configurations.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
_tx_thread_relinquish walks the ready list at the relinquishing thread's priority for a
thread to hand its core to. When the walk reaches one it cannot place, carrying
preemption-threshold or excluded from that thread's mapped core, it sets the rebalance
flag and breaks. That exit falls into the block concluding no other thread is ready,
which is not what the walk found, and that block sets the finished flag. The rebalance
at the end of the function is guarded on that flag, so it never runs.
Every rebalance requested from inside the walk is discarded, because that exit always
reaches the block first. A ready thread behind the obstacle then never reaches a core
while the others hold them and relinquish to each other. The tick keeps arriving, so it
is a livelock rather than a deadlock.
The early return now applies only when no rebalance was requested, which lets control
reach the rebalance path the other three request sites already use.
threadx_smp_relinquish_rebalance_test fills the cores with threads of one priority
relinquishing in a loop, places a thread excluded from every core behind them and a
runnable thread behind that, and fails if the runnable one has not run within 100 ticks.
It fails 3 of 3 before this change and passes 5 of 5 after. Instrumenting a passing run
of threadx_thread_relinquish_test counted 12 rebalance requests from the walk against 4
performed, all 4 from sites outside it. 109/109 in all eight configurations, twice from
clean.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
common_smp/src/tx_thread_smp_debug_entry_insert.c is 222 lines of certified
source sitting entirely under TX_THREAD_SMP_DEBUG_ENABLE. No build configuration
defined that macro, so the file compiled to nothing in all seven and was absent
from the coverage denominator rather than uncovered in it. Eight further files
carry regions behind the same macro, twenty-two regions in nine files.
This is the same argument that added misra_build, on a second whole-file macro,
and it has no monoprocessor counterpart: TX_THREAD_SMP_DEBUG_ENABLE does not
exist in common/src.
One configuration is enough. Every region is a top-level ifdef sitting beside
other guards rather than nested inside one, and the file's own inner guards
resolve without help, so no combination build of the kind misra_trace_build
needed is required here.
It brings in 54 lines and 12 branch outcomes, of which all 54 lines and 10
outcomes arrive covered with no new test written, and the file itself reads 32/32
lines and 8/10 branches. The merged report now covers 194 of the 194 files in
common_smp/src, so the scope statement needs no caveat about which files
contribute code. 108/108 tests pass in the new configuration in every run made.
The two residual outcomes are infinite spin-on-error loops and no terminating
test can cover them: the taken arm never returns, by design.
_tx_thread_smp_system_error is written in one place in the certified source, set
false at initialisation, and read only by that loop.
The gates are re-derived on the union basis: 5386/5450 lines and 2810/3608
branches at best, 5384/5450 and 2805/3608 at worst across three runs.
The suite is not yet reliably green, for reasons this configuration does not
cause and does not share. Three runs produced four hangs on the full ctest
timeout, in four other configurations, on threadx_smp_random_resume_suspend_
exclusion_pt_test, its non-pt twin and threadx_event_flag_isr_set_clear_test;
the last of those timed out on both attempts and failed. Retrying until pass
hides the rest.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The merged report's branch denominator is not the number of branches in
common_smp/src. gcovr keys each branch by the basic-block pair gcov assigned it,
and those numbers shift when a file compiles to a different amount of code, so a
source branch that survives block renumbering between two configurations is
counted twice. Over the seven configurations the denominator reads 6334 where
the source carries 3596, and 1265 of 1343 branch sites carry more branches in
the merged report than any single configuration has. Adding misra_trace_build
moved the merged figure by 994 branches against the dozen the source gained.
It is not harmless. A figure quoted as branch coverage of the source has to have
the source in its denominator, and this one moves when a build configuration is
added for reasons that have nothing to do with the code. It also has to mean the
same thing as the figure the monoprocessor certificate quotes, and until now the
two suites were counting differently.
coverage_union.py reports the union instead: a line is covered if any
configuration executed it, and the Nth branch on a line is covered if any
configuration took it, keyed by position within the line rather than by block
number. That keying is exact here rather than approximate - all 1343 branch
sites carry an identical branch count in every configuration that compiles them,
so no ordinal means two different things. gcovr's merged report is still
produced and published unchanged; the gate reads the union.
The branch gate falls from 83.00 to 77.20 and no coverage was lost doing it.
83.00 was a percentage of 4773 counted branch instances; 77.20 is a percentage
of the 3596 branches that exist.
The gate keeps a margin because the tree has not earned losing one. Over four
clean seven-configuration runs on an unchanged tree, lines did not move at all
and branches read 2792, 2792, 2796 and 2798. All ten outcomes that move are
ordinal 8 or 10 of the twelve-branch TX_TRACE_IN_LINE_INSERT expansion, at five
sites on the thread suspend, thread resume and ISR exit paths. Only 2790 were
covered by every run, and the fifth site first appeared on the fourth run, which
is the argument for the margin rather than against it. The gate sits below that
floor.
Verified: green at the committed values, and failing on either axis when raised
above the measurement, with the reports still written.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
common_smp/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 194 files in common_smp/src that does not
define it for itself and the prototypes for those five conversions sit behind it
in tx_trace.h. This tree does not build with -Werror, so without the define the
file merely warns five times about functions with no previous declaration rather
than failing outright as it does in the monoprocessor tree. That is easier to
miss and no less wrong: the coverage evidence would otherwise come from a
translation unit in which five certified functions have no visible prototype.
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 193 files carry,
and it changes no code: across all seven configurations, 0 of 194 objects differ
once debug information is stripped. Stripping is required to see that. The build
carries -g3, which records macro definitions in DWARF, so every raw object
differs on the macro section alone and a whole-object comparison answers a
different question than the one asked.
108/108 tests pass in each of the seven configurations. The merged report reads
5332/5396 lines and 5494/6334 branches over the seven, against 5283/5343 and
4534/5340 over the six.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
common_smp/src/tx_misra.c is 832 lines of certified source whose whole body sits
under TX_MISRA_ENABLE, with no else branch at all. None of the five build
configurations defined that macro, so the file compiled to nothing in every one
of them: an object and a note file existed, no instrumented code did, and the
merged report covered 186 of the 194 files in common_smp/src while claiming to
cover common_smp/src.
The decisive argument is not the file count. The shim exists to make the
kernel's pointer conversions MISRA compliant, and the MISRA analysis will be run
against the source with the macro defined. Without this configuration the build
that is analysed and the build that is covered are different builds of the same
tree, and two certificates assessed together would be making different claims
about the same shim.
The configuration is instrumented and merged like the other five. All 108 tests
pass in it unchanged.
The port empties six more files without the macro. ports_smp defines
TX_INLINE_INITIALIZATION only when TX_MISRA_ENABLE is absent, so the six
*_initialize.c files carry their bodies here, and the report covers 193 files
rather than 186.
The gates are re-baselined rather than carried forward. The denominator gained
165 lines and 567 branches that were never counted before, so the line
percentage falls while the covered line count rises: 5283/5343 lines and
4528/5340 branches over the six configurations, against 5150/5178 and 3991/4773
over the five re-merged from the same tracefiles.
One file is still absent from the denominator and this configuration does not
reach it. common_smp/src/tx_thread_smp_debug_entry_insert.c sits entirely under
TX_THREAD_SMP_DEBUG_ENABLE, which nothing defines, and eight further files carry
regions behind it. That is the same shape as this commit and has no
monoprocessor counterpart.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
The gates were set from local runs alone and left about three lines of headroom
each. CI has since measured both suites and the margin is too thin to survive an
environment sampled that few times.
observed range gate headroom
ThreadX line 4202-4204 / 4220 99.40 7 lines
ThreadX branch 3310-3329 / 4108 79.50 44 branches
SMP line 5150-5152 / 5178 99.30 8 lines
SMP branch 3994-3999 / 4773 83.00 32 branches
Every gate now sits at two to six times the spread actually observed, where they
previously sat at about one and a half. Nothing real is let through by that: a
regression worth catching moves tens of lines, not two, and these ratchet upward
as each batch of coverage work lands.
The variance is the resume-from-ISR path and the timer information path, which
are reached or missed according to how the host schedules the run rather than by
anything the tests arrange. Covering them by construction is what removes the
need for the margin.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
certification branch
The regression workflows ran on ubuntu-latest with nothing pinned, and the
coverage numbers they produce are certification evidence. Two things follow from
that, and the first is urgent rather than theoretical.
These sources declare cmake_minimum_required(VERSION 3.0.0) and CMake removed
compatibility below 3.5 in 4.0, so this branch stops configuring the day the
hosted image moves to CMake 4.x -- no change here, no warning. Worse, the branch
did not need GitHub's help to get there: scripts/install.sh ran
pip install --upgrade cmake
which installs exactly the CMake version that cannot configure these sources. It
also installed gcovr 4.1, which is far too old for the tracefile and threshold
options the coverage scripts use, and called sudo, which does not exist in a
container.
The job now runs inside debian:trixie, which carries GCC 14, gcc-multilib and
CMake 3.31.6. Being below 4.x, that configures the sources with no policy
override and no edit to CMakeLists.txt. The coverage build is 32-bit, so multilib
is not optional. install.sh installs the distribution toolchain plus gcovr 8.6,
prints all three versions into the job log, and then asserts them: GCC major 14,
CMake major below 4, gcovr exactly 8.6. The image tag is a moving target that
point releases rebuild, and a toolchain that drifts should fail by name and
number rather than quietly produce evidence built with something else.
git is installed before the checkout, because actions/checkout otherwise falls
back to a REST API tarball and leaves no .git behind, and the commit the evidence
was built from is part of the evidence. The Pages preparation step no longer
calls sudo, since the steps run as root in the container.
Nothing gated on the coverage number before: it was published, not enforced.
coverage.sh --merge now ends with a gcovr pass carrying --fail-under-line and
--fail-under-branch, after the reports are written so a failed gate still leaves
the report that explains it.
ThreadX 99.50% line 80.00% branch
SMP 99.40% line 83.00% branch
These are a ratchet, raised as each batch of gaps closes, and deliberately not
100%: a gate nothing can pass gets switched off. They sit below the measured
figures rather than at them, because the same tree does not measure identically
twice -- branches on the resume-from-ISR path are reached or missed depending on
how the host schedules the run, and two clean runs of the ThreadX suite differ by
2 lines and 19 branches. A gate set at the best observation fails on a tree
nobody changed.
Verified by raising each threshold above the measurement: line returns 2, branch
returns 4, the merged report is still written, and run.sh reports the failure
rather than swallowing it -- a run with all 95 tests passing exits 2 when the
line gate is not met.
regression_test.yml now triggers on the certification branch as well as master.
regression_template.yml needed no filter; it is workflow_call only.
Publishing stays on master. The deploy job replaces the project's public coverage
site wholesale and its condition fires on any push, so without a guard the first
push of this branch would have published its numbers as the project's. The
certification branch produces its evidence as workflow artifacts instead.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Only default_build_coverage carried -fprofile-arcs, because the gate was the
build type and it is the only one of five configurations whose name ends in
_coverage. The other four built and ran every test and their coverage was
discarded. That is not redundancy thrown away: each configuration selects a
different set of TX_ feature macros, so the code the other four compile was
absent from the denominator rather than uncovered in it, and 100% against that
report would not have been a measurement of the kernel.
TX_COVERAGE instruments a build regardless of its name, defaulting to OFF so a
single configuration built by hand behaves as before. coverage.sh gains a
--merge mode that unions the per-configuration JSON tracefiles, and
cmake_bootstrap.sh runs it after the test loop so a local run produces the same
merged report CI reads. The workflow template sets TX_COVERAGE for build and
test, and coverage_name moves to the merged report.
Measured on the ThreadX suite, all 95 tests passing in each configuration:
default_build_coverage 3827 valid 3827 covered
disable_notify_callbacks_build 3767 3767
stack_checking_build 3857 3856
stack_checking_rand_fill_build 3862 3861
trace_build 4123 4108
merged 4220 4204
The denominator grows by 393 lines and the figure moves from 100.00% to 99.62%.
The second one is honest, and the drop is the point rather than a regression:
the denominator now includes code the old report never counted. The union also
contains a file the old report did not contain at all --
tx_thread_stack_error_handler.c compiles only under TX_ENABLE_STACK_CHECKING, so
it was not listed at 0%, it was simply absent. 177 files becomes 178.
The scoping is the positional search path, not --object-directory. Left as
--object-directory while the gcovr root moved to the repository root, all five
configurations reported the union of every configuration's gcda: five identical
reports, and a merge of five copies of the same thing. Nothing about the
resulting percentage looks wrong, which is what makes it worth stating here.
Coverage collection moved out of test(). A failing ctest used to abort the
function before coverage.sh was reached, so the run whose behaviour changed was
the one that produced no report, and the gcda already existed by that point.
Collection now runs after the whole test loop, one configuration at a time,
which is also what --merge needs: every tracefile has to exist before the union
is taken. A coverage failure turns the run red but does not overwrite a test
failure's status.
Per-configuration output moved under coverage_report/per_configuration/ and is
excluded from the deployed artifact. The deploy merges the ThreadX and SMP
artifacts into one tree and every configuration directory has the same name in
both, so left at the top level one suite's would overwrite the other's on the
published site.
coverage.sh now fails when a report contains no files. gcovr treats an empty
report as success: it exits 0 and writes line-rate="1.0" alongside
lines-valid="0", so every downstream consumer reads "no data at all" as "100%
covered", and a coverage threshold cannot catch it because an empty report
passes any threshold.
The tx and smp runners are symlinks to scripts/cmake_bootstrap.sh, so they are
covered by the one change there.
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Co-authored-by: TiejunZhou <[email protected]>
|
|
|
