"Integers" section.
Each basic type must specify its alignment, in bits. Examples of
-possible alignments are: bit-packed, byte-packed, or word-aligned. The
-choice depends on the architecture preference and compactness vs
-performance trade-offs of the implementation. Architectures providing
-fast unaligned write byte-packed basic types to save space, aligning
-each type on byte boundaries (8-bit). Architectures with slow unaligned
-writes align types on specific alignment values. If no specific
-alignment is declared for a type, it is assumed to be bit-packed for
-integers with size not multiple of 8 bits and for gcc bitfields. All
-other types are byte-packed. It is however recommended to always specify
-the alignment explicitly.
+possible alignments are: bit-packed (align = 1), byte-packed (align =
+8), or word-aligned (e.g. align = 32 or align = 64). The choice depends
+on the architecture preference and compactness vs performance trade-offs
+of the implementation. Architectures providing fast unaligned write
+byte-packed basic types to save space, aligning each type on byte
+boundaries (8-bit). Architectures with slow unaligned writes align types
+on specific alignment values. If no specific alignment is declared for a
+type, it is assumed to be bit-packed for integers with size not multiple
+of 8 bits and for gcc bitfields. All other basic types are byte-packed
+by default. It is however recommended to always specify the alignment
+explicitly. Alignment values must be power of two. Compound types are
+aligned as specified in their individual specification.
TSDL meta-data attribute representation of a specific alignment:
byte_order = native OR network OR be OR le; /* default native */
size = value; /* value in bits, no default */
align = value; /* value in bits */
+ /* based used for pretty-printing output, default: decimal. */
+ base = decimal OR dec OR OR d OR i OR u OR 10 OR hexadecimal OR hex OR x OR X OR p OR 16
+ OR octal OR oct OR o OR 8 OR binary OR b OR 2;
}
Example of type inheritance (creation of a uint32_t named type):
TSDL meta-data representation:
floating_point {
- exp_dig = value;
- mant_dig = value;
- byte_order = native OR network OR be OR le;
+ exp_dig = value;
+ mant_dig = value;
+ byte_order = native OR network OR be OR le;
+ align = value;
}
Example of type inheritance:
exp_dig = 8; /* sizeof(float) * CHAR_BIT - FLT_MANT_DIG */
mant_dig = 24; /* FLT_MANT_DIG */
byte_order = native;
+ align = 32;
} := float;
TODO: define NaN, +inf, -inf behavior.
+Bit-packed, byte-packed or larger alignments can be used for floating
+point values, similarly to integers.
+
4.1.8 Enumerations
Enumerations are a mapping between an integer type and a table of strings. The
...
}
+Alignment for a structure compound type can be forced to a minimum value
+by adding an "align" specifier after the declaration of a structure
+body. This attribute is read as: align(value). The value is specified in
+bits. The structure will be aligned on the maximum value between this
+attribute and the alignment required by the basic types contained within
+the structure. e.g.
+
+struct {
+ ...
+} align(32)
+
4.2.2 Variants (Discriminated/Tagged Unions)
A CTF variant is a selection between different types. A CTF variant must
always be defined within the scope of a structure or within fields
contained within a structure (defined recursively). A "tag" enumeration
field must appear in either the same lexical scope, prior to the variant
-field (in field declaration order), in an uppermost lexical scope (see
-Section 7.3.1), or in an uppermost dynamic scope (see Section 7.3.2).
-The type selection is indicated by the mapping from the enumeration
-value to the string used as variant type selector. The field to use as
-tag is specified by the "tag_field", specified between "< >" after the
+field (in field declaration order), in an upper lexical scope (see
+Section 7.3.1), or in an upper dynamic scope (see Section 7.3.2). The
+type selection is indicated by the mapping from the enumeration value to
+the string used as variant type selector. The field to use as tag is
+specified by the "tag_field", specified between "< >" after the
"variant" keyword for unnamed variants, and after "variant name" for
named variants.
struct {
enum : uint2_t { a, b, c } choice;
- variant example <choice> v[unsigned int];
+ unsigned int seqlen;
+ variant example <choice> v[seqlen];
}
Example of an unnamed variant:
uint8_t field_name[10];
+Arrays are always aligned on their element alignment requirement.
4.2.4 Sequences
-Sequences are dynamically-sized arrays. They start with an integer that specify
-the length of the sequence, followed by an array of "inner type" elements.
-The length is the number of elements in the sequence.
+Sequences are dynamically-sized arrays. They refer to a a "length"
+unsigned integer field, which must appear in either the same lexical scope,
+prior to the sequence field (in field declaration order), in an upper
+lexical scope (see Section 7.3.1), or in an upper dynamic scope (see
+Section 7.3.2). This length field represents the number of elements in
+the sequence. The sequence per se is an array of "inner type" elements.
-TSDL meta-data representation for a named sequence:
+TSDL meta-data representation for a sequence type definition:
-typedef elem_type name[length_type];
+struct {
+ unsigned int length_field;
+ typedef elem_type typename[length_field];
+ typename seq_field_name;
+}
-A nameless sequence can be declared as a field type, e.g.:
+A sequence can also be declared as a field type, e.g.:
-long field_name[int];
+struct {
+ unsigned int length_field;
+ long seq_field_name[length_field];
+}
-The length type follows the integer types specifications, and the sequence
-elements follow the "array" specifications.
+Multiple sequences can refer to the same length field, and these length
+fields can be in a different upper dynamic scope:
+
+e.g., assuming the stream.event.header defines:
+
+stream {
+ ...
+ id = 1;
+ event.header := struct {
+ uint16_t seq_len;
+ };
+};
+
+event {
+ ...
+ stream_id = 1;
+ fields := struct {
+ long seq_a[stream.event.header.seq_len];
+ char seq_b[stream.event.header.seq_len];
+ };
+};
+
+The sequence elements follow the "array" specifications.
4.2.5 Strings
string field_name; /* Use default UTF8 encoding */
+Strings are always aligned on byte size.
+
5. Event Packet Header
The event packet header consists of two parts: the "event packet header"
event {
name = event_name;
id = value; /* Numeric identifier within the stream */
- stream = stream_id;
+ stream_id = stream_id;
context := struct {
...
};
...
}
+struct {
+ ...
+} align(value)
+
variant {
...
}
keyword: is one of
+align
const
char
double
ll
LL
-hexadecimal-digit-sequence:
- hexadecimal-digit
- hexadecimal-digit-sequence hexadecimal-digit
-
enumeration-constant:
identifier
string-literal
typedef-name
ctf-type-specifier
+align-attribute:
+ align ( constant-expression )
+
struct-specifier:
- struct identifier-opt { struct-or-variant-declaration-list-opt }
- struct identifier
+ struct identifier-opt { struct-or-variant-declaration-list-opt } align-attribute-opt
+ struct identifier align-attribute-opt
struct-or-variant-declaration-list:
struct-or-variant-declaration
direct-declarator:
identifier
( declarator )
- direct-declarator [ type-specifier ]
+ direct-declarator [ unary-expression ]
direct-declarator [ constant-expression ]
abstract-declarator:
direct-abstract-declarator:
identifier-opt
( abstract-declarator )
- direct-abstract-declarator [ type-specifier ]
+ direct-abstract-declarator [ unary-expression ]
direct-abstract-declarator [ constant-expression ]
direct-abstract-declarator [ ]
projects / ctf.git / blobdiff