File: filter-expr.dox

package info (click to toggle)
ltt-control 2.14.0-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 21,860 kB
  • sloc: cpp: 192,012; sh: 28,777; ansic: 10,960; python: 7,108; makefile: 3,520; java: 109; xml: 46
file content (240 lines) | stat: -rw-r--r-- 6,777 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
\lt_var{EXPR} can contain references to the payload fields
of \lt_var{E} and to the current
\link #lttng_event_context_type context\endlink fields.

The expected syntax of \lt_var{EXPR} is similar to the syntax
of a C language conditional expression (an expression
which an \c if statement can evaluate), but there are a few
differences:

- A <code><em>NAME</em></code> expression identifies an event
  payload field named <code><em>NAME</em></code> (a
  C&nbsp;identifier).

  Use the C&nbsp;language dot and square bracket notations to
  access nested structure and array/sequence fields. You can
  only use a constant, positive integer number within square
  brackets. If the index is out of bounds, then
  \lt_var{EXPR} is \b false.

  The value of an enumeration field is an integer.

  When a field expression doesn't exist, \lt_var{EXPR} is
  \b false.

  Examples: <code>my_field</code>, <code>target_cpu</code>,
  <code>seq[7]</code>, <code>msg.user[1].data[2][17]</code>.

- A <code>$ctx.<em>TYPE</em></code> expression identifies the
  statically-known context field having the type
  <code><em>TYPE</em></code> (a C&nbsp;identifier).

  <code><em>TYPE</em></code> can be any of the
  statically known names in the “Field name” column
  of the table of #lttng_event_context_type (that is, excluding the
  #LTTNG_EVENT_CONTEXT_PERF_CPU_COUNTER,
  #LTTNG_EVENT_CONTEXT_PERF_THREAD_COUNTER,
  and #LTTNG_EVENT_CONTEXT_APP_CONTEXT rows).

  When a field expression doesn't exist, \lt_var{EXPR} is \b
  false.

  Examples: <code>$ctx.prio</code>,
  <code>$ctx.gid</code>,
  <code>$ctx.preemptible</code>.

- A <code>$app.<em>PROVIDER</em>:<em>TYPE</em></code>
  expression identifies the application-specific context field
  having the type <code><em>TYPE</em></code> (a
  C&nbsp;identifier) from the provider
  <code><em>PROVIDER</em></code> (a C&nbsp;identifier).

  When a field expression doesn't exist, \lt_var{EXPR} is \b
  false.

  Example: <code>$app.server:cur_user</code>.

- Compare strings, either string fields or string literals
  (double-quoted), with the <code>==</code> and
  <code>!=</code> operators.

  When comparing to a string literal, the <code>*</code>
  character means “match anything”. To match a literal
  <code>*</code> character, use <code>\\*</code>.

  Examples: <code>my_field&nbsp;==&nbsp;"user34"</code>,
  <code>my_field&nbsp;==&nbsp;my_other_field</code>,
  <code>my_field&nbsp;==&nbsp;"192.168.*"</code>.

- The
  <a href="https://en.wikipedia.org/wiki/Order_of_operations">precedence table</a>
  of the operators which are supported in
  \lt_var{EXPR} is as follows. In this table, the highest
  precedence is&nbsp;1:

  <table>
    <tr>
      <th>Precedence
      <th>Operator
      <th>Description
      <th>Associativity
    <tr>
      <td>1
      <td><code>-</code>
      <td>Unary minus
      <td>Right-to-left
    <tr>
      <td>1
      <td><code>+</code>
      <td>Unary plus
      <td>Right-to-left
    <tr>
      <td>1
      <td><code>!</code>
      <td>Logical NOT
      <td>Right-to-left
    <tr>
      <td>1
      <td><code>~</code>
      <td>Bitwise NOT
      <td>Right-to-left
    <tr>
      <td>2
      <td><code>&lt;&lt;</code>
      <td>Bitwise left shift
      <td>Left-to-right
    <tr>
      <td>2
      <td><code>&gt;&gt;</code>
      <td>Bitwise right shift
      <td>Left-to-right
    <tr>
      <td>3
      <td><code>&amp;</code>
      <td>Bitwise AND
      <td>Left-to-right
    <tr>
      <td>4
      <td><code>^</code>
      <td>Bitwise XOR
      <td>Left-to-right
    <tr>
      <td>5
      <td><code>|</code>
      <td>Bitwise OR
      <td>Left-to-right
    <tr>
      <td>6
      <td><code>&lt;</code>
      <td>Less than
      <td>Left-to-right
    <tr>
      <td>6
      <td><code>&lt;=</code>
      <td>Less than or equal to
      <td>Left-to-right
    <tr>
      <td>6
      <td><code>&gt;</code>
      <td>Greater than
      <td>Left-to-right
    <tr>
      <td>6
      <td><code>&gt;=</code>
      <td>Greater than or equal to
      <td>Left-to-right
    <tr>
      <td>7
      <td><code>==</code>
      <td>Equal to
      <td>Left-to-right
    <tr>
      <td>7
      <td><code>!=</code>
      <td>Not equal to
      <td>Left-to-right
    <tr>
      <td>8
      <td><code>&amp;&amp;</code>
      <td>Logical AND
      <td>Left-to-right
    <tr>
      <td>9
      <td><code>||</code>
      <td>Logical OR
      <td>Left-to-right
  </table>

  Parentheses are supported to bypass the default order.

  @attention
      Unlike the C&nbsp;language, the bitwise AND and OR
      operators (<code>&amp;</code> and <code>|</code>) in
      \lt_var{EXPR} take precedence over relational
      operators (<code>&lt;&lt;</code>, <code>&lt;=</code>,
      <code>&gt;</code>, <code>&gt;=</code>, <code>==</code>,
      and <code>!=</code>). This means the expression
      <code>2&nbsp;&&nbsp;2&nbsp;==&nbsp;2</code>
      is \b true while the equivalent C&nbsp;expression
      is \b false.

  The arithmetic operators are :not: supported.

  LTTng first casts all integer constants and fields to signed
  64-bit integers. The representation of negative integers is
  two's complement. This means that, for example, the signed
  8-bit integer field 0xff (-1) becomes 0xffffffffffffffff
  (still&nbsp;-1) once casted.

  Before a bitwise operator is applied, LTTng casts all its
  operands to unsigned 64-bit integers, and then casts the
  result back to a signed 64-bit integer. For the bitwise NOT
  operator, it's the equivalent of this C&nbsp;expression:

  @code
  (int64_t) ~((uint64_t) val)
  @endcode

  For the binary bitwise operators, it's the equivalent of those
  C&nbsp;expressions:

  @code
  (int64_t) ((uint64_t) lhs >> (uint64_t) rhs)
  (int64_t) ((uint64_t) lhs << (uint64_t) rhs)
  (int64_t) ((uint64_t) lhs & (uint64_t) rhs)
  (int64_t) ((uint64_t) lhs ^ (uint64_t) rhs)
  (int64_t) ((uint64_t) lhs | (uint64_t) rhs)
  @endcode

  If the right-hand side of a bitwise shift operator
  (<code>&lt;&lt;</code> and <code>&gt;&gt;</code>) is not in
  the [0,&nbsp;63] range, then \lt_var{EXPR} is \b false.

@note
    See \ref api_proc_filter to allow or disallow processes to
    record LTTng events based on their attributes
    instead of using equivalent statically-known context
    fields in \lt_var{EXPR} like <code>$ctx.pid</code>.
    The former method is much more efficient.

\lt_var{EXPR} examples:

@code{.unparsed}
msg_id == 23 && size >= 2048
@endcode

@code{.unparsed}
$ctx.procname == "lttng*" && (!flag || poel < 34)
@endcode

@code{.unparsed}
$app.my_provider:my_context == 17.34e9 || some_enum >= 14
@endcode

@code{.unparsed}
$ctx.cpu_id == 2 && filename != "*.log"
@endcode

@code{.unparsed}
eax_reg & 0xff7 == 0x240 && x[4] >> 12 <= 0x1234
@endcode