4.14.2 References in event source fields
Event sources must follow these rules when referring to fields or to resources.
Identifying resources and memory spaces
Event sources that include a field that identifies a resource must use the numeric
resource id as the field, see
not the resource name string. If resource names are reported, which is discouraged,
they must be consistent with the
Event sources that include a field that identifies a memory space must use the
spaceId as the field, see
MemorySpaceInfo.spaceId. The same restrictions apply when
referring to memory spaces as to resources.
Syntax of references in the format string
A format string can refer to values in this and other instances, with the following syntax and semantics. In the following list, variables are enclosed by angle brackets,
<…>, and optional items are enclosed by square brackets,
[…]. This list is ordered roughly from more common to less common use cases:
- Refers to a field in this event source. The client must make sure the field
- Refers to a resource in this instance. Only well-defined for synchronous
event sources, otherwise the results are undefined.
- Refers to a field in another, previous, event. The client
must make sure the other event and field are enabled and must buffer the
values of these fields. The semantics are only well-defined for event
sources with a defined ordering relationship. Because event sources can only
refer to past events, not to future events, usually only the last event in a
causal event chain can refer to all fields of that event chain. Clients are
not expected to wait until data is available. Using this reference requires
detailed knowledge of the ordering of the event sources involved.
- Refers to a resource in another instance. This is only
well-defined for synchronous events where other instances are stable and are
causally connected to this instance. For example an event source from within
a downstream cache might be able to refer to resources in its parent cache
or parent core if they are causally connected. In some cases, an
approximation of otherwise hard to produce data might still be useful, for
example acquiring the approximate PC value of an otherwise unrelated sibling
core to debug multithreading problems. Using this reference requires
detailed knowledge of the causal relationship between instances and their
- Refers to an event field in a previous event of another
instance. The client must make sure the event and field are enabled in the
other instance and the client must buffer the values of these fields. This
is only well-defined if the events involved have a strict ordering
relationship and if the instances involved are strongly causally connected.
This might be the case, for example, when transactions flow through multiple
components of a memory subsystem. Using this reference requires very
detailed knowledge about the causal relationship between instances and their
- This is always relative to the instance that contains the
format string. The semantics are similar to C++ namespace scoping semantics.
It starts at the path of the instance that contains the format string, tries
instance_path, and if that fails,
repeatedly goes one level up, until it is found. This enables references to
children, siblings, and parent instances without needing to specify absolute
paths. The special token "
PARENT" can be
used as an explicit inverse scope to reach parents without specifying the
parent's name. It can be specified multiple times, but only at the beginning
of the path.