Ze struct dispatch + ze full chained - #537
Open
TApplencourt wants to merge 5 commits into
Open
Conversation
TApplencourt
force-pushed
the
ze-struct-dispatch
branch
from
September 9, 2026 20:35
53848d1 to
0206b0c
Compare
The switch that decodes a pNext chain named every enumerator it did not trace, so three of them sat in the generator as literal cases: zes's BASE_STATE and DEVICE_UUID, and each namespace's FORCE_UINT32. `default:` covers all of them, and covers the value a driver newer than our headers sends, which enumeration never could. Runtime behaviour is unchanged -- an stype with no case fell out of the switch before and breaks out of it now. The other hardcoded case was ZE_STRUCTURE_TYPE_DEVICE_PROPERTIES_1_2, a second tag for a struct that already had one. structure_type_name derived a single enumerator from a struct's name, so the second could only be appended as a duplicate block at the bottom of the switch. Turning STRUCT_TYPE_CONVERSION_TABLE around -- from a correction to the derived name into a struct's list of stypes -- makes that a row rather than a branch: the two labels now fall through to one tracepoint, the way the itt size switch already groups its metadata types. A struct with a third stype is a longer row. Every (stype -> tracepoint) pair is unchanged, 175 of them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ZE::ZEBaseDesc.new raised `ArgumentError: invalid enum value, :ZE_STRUCTURE_TYPE_BASE_DESC`, and so did eight sibling classes. The generated initializer stamps the stype derived from the struct's name into every struct whose first member is `stype`, without checking the spec declares that enumerator. The <ns>_base_ headers have the member but no tag of their own -- they are what the concrete descriptors are built on -- so FFI rejected the symbol and the class could not be constructed at all. The hand-written STRUCT_TYPE_REJECT was meant to hold these. It named two structs where eleven qualify, and the nine it missed are exactly the nine that raised. Asking traced_structure_type_names, which answers from the enum, replaces the list and closes the gap it left. Affected: ZEBaseCbParams, ZEBaseProperties, ZEBaseDesc, ZETBaseProperties, ZETBaseDesc, ZESBaseProperties, ZESBaseDesc, ZESBaseConfig, ZESBaseCapability. Each constructs now; none carries a tag, which is right, since nothing tags them. ze_library.rb loses those nine initializers and nothing else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The tracer walks a call's pNext chain only when LTTNG_UST_ZE_CHAINED_STRUCTS is set, and the events it fires there belong to the lttng_ust_<ns>_structs providers, which no tracing mode enabled. Between them that put the chain out of iprof's reach entirely: the extension structs a program passes were traced by tracer_ze.sh --structs and by nothing else. `full` now sets the variable and enables the five providers. minimal and default are untouched, so the per-struct tracepoint cost stays opt-in. The tally is unaffected: a struct event matches no tally rule, and the function set and call counts are identical in both modes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both names the README tells a maintainer to edit are gone: $struct_type_reject, and struct_type_conversion_table which is now STRUCT_TYPES keyed the other way round. The zex step went with the first of those. A struct tagged by a ZEX_STRUCTURE_* macro used to need a reject entry or gen_ze_library raised; traced_structure_type_names now keeps only the stypes the spec declares, so such a struct drops out on its own and there is nothing to write down -- verified against zex_device_module_register_file_exp_t, which has a Ruby class, no stype stamped in it, and no case in the tracer's switch. That leaves one manual change when transcribing zex, not two. The naming-inconsistency section gains the other thing that table now answers: a struct the spec tags with two enumerators lists both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
TApplencourt
force-pushed
the
ze-struct-dispatch
branch
from
September 9, 2026 21:11
0206b0c to
af2e467
Compare
The tracer reaches a struct tracepoint one way: it casts the void * to ze_base_desc_t *, reads ->stype, and switches on it. So a struct that no declared enumerator tags can never be selected, whatever is emitted for it. Three consumers disagreed about which structs count. The .tp emitters took every tagged struct (186), the babeltrace model rejected `<ns>_base_` by name (176), and the switch kept only what an stype names (174). The name check was a convention standing in for that last fact, and it was wrong about zes_base_state_t: the spec does declare ZES_STRUCTURE_TYPE_BASE_STATE, which is why the generator carried a hand-written empty case for it. traced_structs now asks the question the tracer asks, and all three agree on 175. Eleven tracepoints go: nine `<ns>_base_` chain headers, which are the stype field rather than a thing it selects, plus zet_metric_source_id_exp_t (the spec omits its tag) and zex_device_module_register_file_exp_t (zex tags with a uint32_t alias). That is -132 lines across four .tp files and two event classes out of btx_ze_model.yaml. zes_base_state_t goes the other way: it is traced now instead of dispatched to an empty case, +3 lines in tracer_ze.c and one event class back. Function tracepoints are untouched -- 468 in ze_tracepoints.tp before and after. Checked on a Max 1550: tracer_ze.sh --structs emits the same 46 events with the same 2 struct payloads before and after, and the ze suite passes 9/9. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
iprof --tracing-mode fulldoesn't exist (
ZE::ZEBaseDesc.newraisedArgumentErroron devel)case / switch, handle double enum per type(
ZE_STRUCTURE_TYPE_DEVICE_PROPERTIES_1_2) natively