if_bnxt: add bnxt logger module files to sys/conf/files for built-in kernel builds
The bnxt snapdump and coredump support patches added bnxt_log/{_data}.c. and listed it in
sys/modules/bnxt/bnxt_en/Makefile, but missed to add these files in sys/conf/files.
Fix up the issue by adding bnxt_log/{_data}.c in sys/conf/files.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
[Dexter] Enable after_hit_count for state nodes
The after_hit_count attribute for a state node causes it to become active
only after it would have become active N times. This uses the existing logic
for incrementing hit counts, i.e. after the node becomes "active", we will
not add another hit count until it stops being active for at least one step.
Since state nodes with after_hit_count do not become active before reaching
the required hit count, this requires us to keep track of an "early" set of
state nodes, meaning nodes that would be active if not for their
after_hit_count.
[Dexter] Add condition check to state nodes
This patch enables the ability for state nodes to check conditions, meaning
they will be active only if the condition is met.
Condition evaluation is somewhat language specific; we directly check
whether the value of the evaluated expression is "true" (case-insensitive),
which works for the languages we actually use Dexter with, but may require
generalizing in future.
We also cache conditions as they are evaluated; each time we step, we clear
all cached conditions for the current frame and any expired frames, but we
keep the cached conditions for any frames rootwards from the current frame;
this prevents us from unexpectedly exiting out of a callee frame because of
debug info not surviving a stack unwind; if the early exit is desired, an
!and{at_frame_idx, condition} under the lower frame may suffice.
[Dexter] Add support for writing !step values
Following from the previous patch, this patch adds support to Dexter for
generating expected values for !step nodes. This is relatively limited:
the kind of !step which this is most well-suited to this is !step exactly,
as the !step order of ignoring extra lines is redundant (all lines are added
as expected values), and !step never can't know what lines could have been
stepped on but weren't without some extra work (e.g. finding viable
breakpoint locations in the enclosing state node).
[Dexter] Add !step node for testing stepping behaviour
This patch adds a node for generating metrics based on lines stepped on. The
new node has 3 versions: !step exactly, !step order, and !step never, which
check an expected list of line numbers against the actual line numbers seen
while the expect is active.
[Dexter] Add at_frame_idx to check values in frames above current
This patch adds a new attribute for !and nodes, `at_frame_idx`, which
matches against frames above its parent node; for example, in the script:
```
!where {function: foo}:
!where {function: bar}:
!and {at_frame_idx: 1}:
!value x: 0
```
The `!value x` node checks the value of 'x' in 'foo' while the debugger is
inside 'bar'. Use of this attribute comes with some restrictions: a !where
node can never be nested under a !and{at_frame_idx} node, and neither can
another !and{at_frame_idx} node.
[Dexter] Write expects for variables in Debugger scopes
Following on from the previous patch, this patch adds support for writing
expects from !value/all nodes, generating separate expects for each
variable in the requested debugger scope, for each continuous range of lines
it is live for.
[Dexter] Add for_hit_count for state nodes
This patch adds the ability for state nodes to use a `for_hit_count: <int>`
field to limit the number of times that a given state node will be active.
[Dexter] Add !address node
Adds a node type for Dexter that allows checking abstract labels instead of
concrete addresses. Each address node has a label and optional offset, and
the first time during evaluation that a given address label is matched
against a valid pointer value, the address label will be assigned a value
that matches the seen address (adjusting for any offset). From that point,
the resolved address value will be used for the remainder of the test
evaluation.
[Dexter] Allow fetching "scopes" from the debugger
To further improve Dexter's script writing ability, this patch starts
implementing the ability for Dexter to fetch all variables with in a given
"scope", as defined by the DAP "scopes" request. This allows the test to
collect all available variables without needing to specify them explicitly
in the script, aiding in fast script generation/re-generation.
This patch does not add any script-writing functionality, but adds the
!value/all Node, which fetches all variable values from the given scope, and
enables fetching these values from DAP-based debuggers.
[Dexter] Add rewriting for aggregate variables
Following on from the previous patch, this patch allows Dexter to write
disaggregated expected values for aggregate variables. Dexter eagerly tries
to disaggregate whenever subvalues are available, but will fallback to the
root/parent value if all available subvalues are unavailable.
[Dexter] Add ability to rewrite scripts to fill-in unknown values
This patch adds a feature to Dexter that allows scripts to be passed to
Dexter with missing expected values (`null` values in YAML), which Dexter
will attempt to "fill-in" with expected values that match the debugger's
actual output. The result is written to a file with the same name as the
original test file, in the directory given by --results-directory if one
is present; all content outside of the Dexter script itself is preserved
exactly as-is.
[Dexter] Add !then node
In order to exercise more control over stepping in Dexter tests, this patch
adds the `!then` node which can be used to step out of a function or exit
the current test. Unlike expect nodes, !then nodes appear as direct singular
children of a state node:
!where {lines: 10}: !then finish
The two currently available commands are "step_out" and "finish". step_out
performs a debugger "step out" command, skipping over all !wheres in the
current frame and not stepping into any lower !wheres. The finish command
ends the debugger session immediately after finishing the current step.
