Commit | Line | Data |
---|---|---|
f418dd93 | 1 | @c \input texinfo |
c906108c | 2 | @c %**start of header |
f418dd93 DJ |
3 | @c @setfilename agentexpr.info |
4 | @c @settitle GDB Agent Expressions | |
5 | @c @setchapternewpage off | |
c906108c SS |
6 | @c %**end of header |
7 | ||
16d1a084 DJ |
8 | @c This file is part of the GDB manual. |
9 | @c | |
782b2b07 | 10 | @c Copyright (C) 2003, 2004, 2005, 2006, 2009 |
16d1a084 DJ |
11 | @c Free Software Foundation, Inc. |
12 | @c | |
13 | @c See the file gdb.texinfo for copying conditions. | |
14 | ||
f418dd93 DJ |
15 | @node Agent Expressions |
16 | @appendix The GDB Agent Expression Mechanism | |
c906108c | 17 | |
d3e8051b | 18 | In some applications, it is not feasible for the debugger to interrupt |
c906108c SS |
19 | the program's execution long enough for the developer to learn anything |
20 | helpful about its behavior. If the program's correctness depends on its | |
21 | real-time behavior, delays introduced by a debugger might cause the | |
22 | program to fail, even when the code itself is correct. It is useful to | |
23 | be able to observe the program's behavior without interrupting it. | |
24 | ||
25 | Using GDB's @code{trace} and @code{collect} commands, the user can | |
26 | specify locations in the program, and arbitrary expressions to evaluate | |
27 | when those locations are reached. Later, using the @code{tfind} | |
28 | command, she can examine the values those expressions had when the | |
29 | program hit the trace points. The expressions may also denote objects | |
30 | in memory --- structures or arrays, for example --- whose values GDB | |
31 | should record; while visiting a particular tracepoint, the user may | |
32 | inspect those objects as if they were in memory at that moment. | |
33 | However, because GDB records these values without interacting with the | |
34 | user, it can do so quickly and unobtrusively, hopefully not disturbing | |
35 | the program's behavior. | |
36 | ||
37 | When GDB is debugging a remote target, the GDB @dfn{agent} code running | |
38 | on the target computes the values of the expressions itself. To avoid | |
39 | having a full symbolic expression evaluator on the agent, GDB translates | |
40 | expressions in the source language into a simpler bytecode language, and | |
41 | then sends the bytecode to the agent; the agent then executes the | |
42 | bytecode, and records the values for GDB to retrieve later. | |
43 | ||
44 | The bytecode language is simple; there are forty-odd opcodes, the bulk | |
45 | of which are the usual vocabulary of C operands (addition, subtraction, | |
46 | shifts, and so on) and various sizes of literals and memory reference | |
47 | operations. The bytecode interpreter operates strictly on machine-level | |
48 | values --- various sizes of integers and floating point numbers --- and | |
49 | requires no information about types or symbols; thus, the interpreter's | |
50 | internal data structures are simple, and each bytecode requires only a | |
51 | few native machine instructions to implement it. The interpreter is | |
52 | small, and strict limits on the memory and time required to evaluate an | |
53 | expression are easy to determine, making it suitable for use by the | |
54 | debugging agent in real-time applications. | |
55 | ||
56 | @menu | |
57 | * General Bytecode Design:: Overview of the interpreter. | |
58 | * Bytecode Descriptions:: What each one does. | |
59 | * Using Agent Expressions:: How agent expressions fit into the big picture. | |
60 | * Varying Target Capabilities:: How to discover what the target can do. | |
c906108c SS |
61 | * Rationale:: Why we did it this way. |
62 | @end menu | |
63 | ||
64 | ||
65 | @c @node Rationale | |
66 | @c @section Rationale | |
67 | ||
68 | ||
69 | @node General Bytecode Design | |
70 | @section General Bytecode Design | |
71 | ||
72 | The agent represents bytecode expressions as an array of bytes. Each | |
73 | instruction is one byte long (thus the term @dfn{bytecode}). Some | |
74 | instructions are followed by operand bytes; for example, the @code{goto} | |
75 | instruction is followed by a destination for the jump. | |
76 | ||
77 | The bytecode interpreter is a stack-based machine; most instructions pop | |
78 | their operands off the stack, perform some operation, and push the | |
79 | result back on the stack for the next instruction to consume. Each | |
80 | element of the stack may contain either a integer or a floating point | |
81 | value; these values are as many bits wide as the largest integer that | |
82 | can be directly manipulated in the source language. Stack elements | |
83 | carry no record of their type; bytecode could push a value as an | |
84 | integer, then pop it as a floating point value. However, GDB will not | |
85 | generate code which does this. In C, one might define the type of a | |
86 | stack element as follows: | |
87 | @example | |
88 | union agent_val @{ | |
89 | LONGEST l; | |
90 | DOUBLEST d; | |
91 | @}; | |
92 | @end example | |
93 | @noindent | |
94 | where @code{LONGEST} and @code{DOUBLEST} are @code{typedef} names for | |
95 | the largest integer and floating point types on the machine. | |
96 | ||
97 | By the time the bytecode interpreter reaches the end of the expression, | |
98 | the value of the expression should be the only value left on the stack. | |
99 | For tracing applications, @code{trace} bytecodes in the expression will | |
100 | have recorded the necessary data, and the value on the stack may be | |
101 | discarded. For other applications, like conditional breakpoints, the | |
102 | value may be useful. | |
103 | ||
104 | Separate from the stack, the interpreter has two registers: | |
105 | @table @code | |
106 | @item pc | |
107 | The address of the next bytecode to execute. | |
108 | ||
109 | @item start | |
110 | The address of the start of the bytecode expression, necessary for | |
111 | interpreting the @code{goto} and @code{if_goto} instructions. | |
112 | ||
113 | @end table | |
114 | @noindent | |
115 | Neither of these registers is directly visible to the bytecode language | |
116 | itself, but they are useful for defining the meanings of the bytecode | |
117 | operations. | |
118 | ||
119 | There are no instructions to perform side effects on the running | |
120 | program, or call the program's functions; we assume that these | |
121 | expressions are only used for unobtrusive debugging, not for patching | |
122 | the running code. | |
123 | ||
124 | Most bytecode instructions do not distinguish between the various sizes | |
125 | of values, and operate on full-width values; the upper bits of the | |
126 | values are simply ignored, since they do not usually make a difference | |
127 | to the value computed. The exceptions to this rule are: | |
128 | @table @asis | |
129 | ||
130 | @item memory reference instructions (@code{ref}@var{n}) | |
131 | There are distinct instructions to fetch different word sizes from | |
132 | memory. Once on the stack, however, the values are treated as full-size | |
133 | integers. They may need to be sign-extended; the @code{ext} instruction | |
134 | exists for this purpose. | |
135 | ||
136 | @item the sign-extension instruction (@code{ext} @var{n}) | |
137 | These clearly need to know which portion of their operand is to be | |
138 | extended to occupy the full length of the word. | |
139 | ||
140 | @end table | |
141 | ||
142 | If the interpreter is unable to evaluate an expression completely for | |
143 | some reason (a memory location is inaccessible, or a divisor is zero, | |
144 | for example), we say that interpretation ``terminates with an error''. | |
145 | This means that the problem is reported back to the interpreter's caller | |
146 | in some helpful way. In general, code using agent expressions should | |
147 | assume that they may attempt to divide by zero, fetch arbitrary memory | |
148 | locations, and misbehave in other ways. | |
149 | ||
150 | Even complicated C expressions compile to a few bytecode instructions; | |
151 | for example, the expression @code{x + y * z} would typically produce | |
152 | code like the following, assuming that @code{x} and @code{y} live in | |
153 | registers, and @code{z} is a global variable holding a 32-bit | |
154 | @code{int}: | |
155 | @example | |
156 | reg 1 | |
157 | reg 2 | |
158 | const32 @i{address of z} | |
159 | ref32 | |
160 | ext 32 | |
161 | mul | |
162 | add | |
163 | end | |
164 | @end example | |
165 | ||
166 | In detail, these mean: | |
167 | @table @code | |
168 | ||
169 | @item reg 1 | |
170 | Push the value of register 1 (presumably holding @code{x}) onto the | |
171 | stack. | |
172 | ||
173 | @item reg 2 | |
174 | Push the value of register 2 (holding @code{y}). | |
175 | ||
176 | @item const32 @i{address of z} | |
177 | Push the address of @code{z} onto the stack. | |
178 | ||
179 | @item ref32 | |
180 | Fetch a 32-bit word from the address at the top of the stack; replace | |
181 | the address on the stack with the value. Thus, we replace the address | |
182 | of @code{z} with @code{z}'s value. | |
183 | ||
184 | @item ext 32 | |
185 | Sign-extend the value on the top of the stack from 32 bits to full | |
186 | length. This is necessary because @code{z} is a signed integer. | |
187 | ||
188 | @item mul | |
189 | Pop the top two numbers on the stack, multiply them, and push their | |
190 | product. Now the top of the stack contains the value of the expression | |
191 | @code{y * z}. | |
192 | ||
193 | @item add | |
194 | Pop the top two numbers, add them, and push the sum. Now the top of the | |
195 | stack contains the value of @code{x + y * z}. | |
196 | ||
197 | @item end | |
198 | Stop executing; the value left on the stack top is the value to be | |
199 | recorded. | |
200 | ||
201 | @end table | |
202 | ||
203 | ||
204 | @node Bytecode Descriptions | |
205 | @section Bytecode Descriptions | |
206 | ||
207 | Each bytecode description has the following form: | |
208 | ||
209 | @table @asis | |
210 | ||
211 | @item @code{add} (0x02): @var{a} @var{b} @result{} @var{a+b} | |
212 | ||
213 | Pop the top two stack items, @var{a} and @var{b}, as integers; push | |
214 | their sum, as an integer. | |
215 | ||
216 | @end table | |
217 | ||
218 | In this example, @code{add} is the name of the bytecode, and | |
219 | @code{(0x02)} is the one-byte value used to encode the bytecode, in | |
d3e8051b | 220 | hexadecimal. The phrase ``@var{a} @var{b} @result{} @var{a+b}'' shows |
c906108c SS |
221 | the stack before and after the bytecode executes. Beforehand, the stack |
222 | must contain at least two values, @var{a} and @var{b}; since the top of | |
223 | the stack is to the right, @var{b} is on the top of the stack, and | |
224 | @var{a} is underneath it. After execution, the bytecode will have | |
225 | popped @var{a} and @var{b} from the stack, and replaced them with a | |
226 | single value, @var{a+b}. There may be other values on the stack below | |
227 | those shown, but the bytecode affects only those shown. | |
228 | ||
229 | Here is another example: | |
230 | ||
231 | @table @asis | |
232 | ||
233 | @item @code{const8} (0x22) @var{n}: @result{} @var{n} | |
234 | Push the 8-bit integer constant @var{n} on the stack, without sign | |
235 | extension. | |
236 | ||
237 | @end table | |
238 | ||
239 | In this example, the bytecode @code{const8} takes an operand @var{n} | |
240 | directly from the bytecode stream; the operand follows the @code{const8} | |
241 | bytecode itself. We write any such operands immediately after the name | |
242 | of the bytecode, before the colon, and describe the exact encoding of | |
243 | the operand in the bytecode stream in the body of the bytecode | |
244 | description. | |
245 | ||
246 | For the @code{const8} bytecode, there are no stack items given before | |
247 | the @result{}; this simply means that the bytecode consumes no values | |
248 | from the stack. If a bytecode consumes no values, or produces no | |
249 | values, the list on either side of the @result{} may be empty. | |
250 | ||
251 | If a value is written as @var{a}, @var{b}, or @var{n}, then the bytecode | |
252 | treats it as an integer. If a value is written is @var{addr}, then the | |
253 | bytecode treats it as an address. | |
254 | ||
255 | We do not fully describe the floating point operations here; although | |
256 | this design can be extended in a clean way to handle floating point | |
257 | values, they are not of immediate interest to the customer, so we avoid | |
258 | describing them, to save time. | |
259 | ||
260 | ||
261 | @table @asis | |
262 | ||
263 | @item @code{float} (0x01): @result{} | |
264 | ||
265 | Prefix for floating-point bytecodes. Not implemented yet. | |
266 | ||
267 | @item @code{add} (0x02): @var{a} @var{b} @result{} @var{a+b} | |
268 | Pop two integers from the stack, and push their sum, as an integer. | |
269 | ||
270 | @item @code{sub} (0x03): @var{a} @var{b} @result{} @var{a-b} | |
271 | Pop two integers from the stack, subtract the top value from the | |
272 | next-to-top value, and push the difference. | |
273 | ||
274 | @item @code{mul} (0x04): @var{a} @var{b} @result{} @var{a*b} | |
275 | Pop two integers from the stack, multiply them, and push the product on | |
276 | the stack. Note that, when one multiplies two @var{n}-bit numbers | |
277 | yielding another @var{n}-bit number, it is irrelevant whether the | |
278 | numbers are signed or not; the results are the same. | |
279 | ||
280 | @item @code{div_signed} (0x05): @var{a} @var{b} @result{} @var{a/b} | |
281 | Pop two signed integers from the stack; divide the next-to-top value by | |
282 | the top value, and push the quotient. If the divisor is zero, terminate | |
283 | with an error. | |
284 | ||
285 | @item @code{div_unsigned} (0x06): @var{a} @var{b} @result{} @var{a/b} | |
286 | Pop two unsigned integers from the stack; divide the next-to-top value | |
287 | by the top value, and push the quotient. If the divisor is zero, | |
288 | terminate with an error. | |
289 | ||
290 | @item @code{rem_signed} (0x07): @var{a} @var{b} @result{} @var{a modulo b} | |
291 | Pop two signed integers from the stack; divide the next-to-top value by | |
292 | the top value, and push the remainder. If the divisor is zero, | |
293 | terminate with an error. | |
294 | ||
295 | @item @code{rem_unsigned} (0x08): @var{a} @var{b} @result{} @var{a modulo b} | |
296 | Pop two unsigned integers from the stack; divide the next-to-top value | |
297 | by the top value, and push the remainder. If the divisor is zero, | |
298 | terminate with an error. | |
299 | ||
300 | @item @code{lsh} (0x09): @var{a} @var{b} @result{} @var{a<<b} | |
301 | Pop two integers from the stack; let @var{a} be the next-to-top value, | |
302 | and @var{b} be the top value. Shift @var{a} left by @var{b} bits, and | |
303 | push the result. | |
304 | ||
f418dd93 | 305 | @item @code{rsh_signed} (0x0a): @var{a} @var{b} @result{} @code{(signed)}@var{a>>b} |
c906108c SS |
306 | Pop two integers from the stack; let @var{a} be the next-to-top value, |
307 | and @var{b} be the top value. Shift @var{a} right by @var{b} bits, | |
308 | inserting copies of the top bit at the high end, and push the result. | |
309 | ||
310 | @item @code{rsh_unsigned} (0x0b): @var{a} @var{b} @result{} @var{a>>b} | |
311 | Pop two integers from the stack; let @var{a} be the next-to-top value, | |
312 | and @var{b} be the top value. Shift @var{a} right by @var{b} bits, | |
313 | inserting zero bits at the high end, and push the result. | |
314 | ||
315 | @item @code{log_not} (0x0e): @var{a} @result{} @var{!a} | |
316 | Pop an integer from the stack; if it is zero, push the value one; | |
317 | otherwise, push the value zero. | |
318 | ||
319 | @item @code{bit_and} (0x0f): @var{a} @var{b} @result{} @var{a&b} | |
320 | Pop two integers from the stack, and push their bitwise @code{and}. | |
321 | ||
322 | @item @code{bit_or} (0x10): @var{a} @var{b} @result{} @var{a|b} | |
323 | Pop two integers from the stack, and push their bitwise @code{or}. | |
324 | ||
325 | @item @code{bit_xor} (0x11): @var{a} @var{b} @result{} @var{a^b} | |
326 | Pop two integers from the stack, and push their bitwise | |
327 | exclusive-@code{or}. | |
328 | ||
329 | @item @code{bit_not} (0x12): @var{a} @result{} @var{~a} | |
330 | Pop an integer from the stack, and push its bitwise complement. | |
331 | ||
332 | @item @code{equal} (0x13): @var{a} @var{b} @result{} @var{a=b} | |
333 | Pop two integers from the stack; if they are equal, push the value one; | |
334 | otherwise, push the value zero. | |
335 | ||
336 | @item @code{less_signed} (0x14): @var{a} @var{b} @result{} @var{a<b} | |
337 | Pop two signed integers from the stack; if the next-to-top value is less | |
338 | than the top value, push the value one; otherwise, push the value zero. | |
339 | ||
340 | @item @code{less_unsigned} (0x15): @var{a} @var{b} @result{} @var{a<b} | |
341 | Pop two unsigned integers from the stack; if the next-to-top value is less | |
342 | than the top value, push the value one; otherwise, push the value zero. | |
343 | ||
344 | @item @code{ext} (0x16) @var{n}: @var{a} @result{} @var{a}, sign-extended from @var{n} bits | |
345 | Pop an unsigned value from the stack; treating it as an @var{n}-bit | |
346 | twos-complement value, extend it to full length. This means that all | |
347 | bits to the left of bit @var{n-1} (where the least significant bit is bit | |
348 | 0) are set to the value of bit @var{n-1}. Note that @var{n} may be | |
349 | larger than or equal to the width of the stack elements of the bytecode | |
350 | engine; in this case, the bytecode should have no effect. | |
351 | ||
352 | The number of source bits to preserve, @var{n}, is encoded as a single | |
353 | byte unsigned integer following the @code{ext} bytecode. | |
354 | ||
355 | @item @code{zero_ext} (0x2a) @var{n}: @var{a} @result{} @var{a}, zero-extended from @var{n} bits | |
356 | Pop an unsigned value from the stack; zero all but the bottom @var{n} | |
357 | bits. This means that all bits to the left of bit @var{n-1} (where the | |
358 | least significant bit is bit 0) are set to the value of bit @var{n-1}. | |
359 | ||
360 | The number of source bits to preserve, @var{n}, is encoded as a single | |
361 | byte unsigned integer following the @code{zero_ext} bytecode. | |
362 | ||
363 | @item @code{ref8} (0x17): @var{addr} @result{} @var{a} | |
364 | @itemx @code{ref16} (0x18): @var{addr} @result{} @var{a} | |
365 | @itemx @code{ref32} (0x19): @var{addr} @result{} @var{a} | |
366 | @itemx @code{ref64} (0x1a): @var{addr} @result{} @var{a} | |
367 | Pop an address @var{addr} from the stack. For bytecode | |
368 | @code{ref}@var{n}, fetch an @var{n}-bit value from @var{addr}, using the | |
369 | natural target endianness. Push the fetched value as an unsigned | |
370 | integer. | |
371 | ||
372 | Note that @var{addr} may not be aligned in any particular way; the | |
373 | @code{ref@var{n}} bytecodes should operate correctly for any address. | |
374 | ||
375 | If attempting to access memory at @var{addr} would cause a processor | |
376 | exception of some sort, terminate with an error. | |
377 | ||
378 | @item @code{ref_float} (0x1b): @var{addr} @result{} @var{d} | |
379 | @itemx @code{ref_double} (0x1c): @var{addr} @result{} @var{d} | |
380 | @itemx @code{ref_long_double} (0x1d): @var{addr} @result{} @var{d} | |
381 | @itemx @code{l_to_d} (0x1e): @var{a} @result{} @var{d} | |
382 | @itemx @code{d_to_l} (0x1f): @var{d} @result{} @var{a} | |
383 | Not implemented yet. | |
384 | ||
385 | @item @code{dup} (0x28): @var{a} => @var{a} @var{a} | |
386 | Push another copy of the stack's top element. | |
387 | ||
388 | @item @code{swap} (0x2b): @var{a} @var{b} => @var{b} @var{a} | |
389 | Exchange the top two items on the stack. | |
390 | ||
391 | @item @code{pop} (0x29): @var{a} => | |
392 | Discard the top value on the stack. | |
393 | ||
394 | @item @code{if_goto} (0x20) @var{offset}: @var{a} @result{} | |
395 | Pop an integer off the stack; if it is non-zero, branch to the given | |
396 | offset in the bytecode string. Otherwise, continue to the next | |
397 | instruction in the bytecode stream. In other words, if @var{a} is | |
398 | non-zero, set the @code{pc} register to @code{start} + @var{offset}. | |
399 | Thus, an offset of zero denotes the beginning of the expression. | |
400 | ||
401 | The @var{offset} is stored as a sixteen-bit unsigned value, stored | |
402 | immediately following the @code{if_goto} bytecode. It is always stored | |
f821f325 | 403 | most significant byte first, regardless of the target's normal |
c906108c SS |
404 | endianness. The offset is not guaranteed to fall at any particular |
405 | alignment within the bytecode stream; thus, on machines where fetching a | |
406 | 16-bit on an unaligned address raises an exception, you should fetch the | |
407 | offset one byte at a time. | |
408 | ||
409 | @item @code{goto} (0x21) @var{offset}: @result{} | |
410 | Branch unconditionally to @var{offset}; in other words, set the | |
411 | @code{pc} register to @code{start} + @var{offset}. | |
412 | ||
413 | The offset is stored in the same way as for the @code{if_goto} bytecode. | |
414 | ||
415 | @item @code{const8} (0x22) @var{n}: @result{} @var{n} | |
416 | @itemx @code{const16} (0x23) @var{n}: @result{} @var{n} | |
417 | @itemx @code{const32} (0x24) @var{n}: @result{} @var{n} | |
418 | @itemx @code{const64} (0x25) @var{n}: @result{} @var{n} | |
419 | Push the integer constant @var{n} on the stack, without sign extension. | |
420 | To produce a small negative value, push a small twos-complement value, | |
421 | and then sign-extend it using the @code{ext} bytecode. | |
422 | ||
423 | The constant @var{n} is stored in the appropriate number of bytes | |
424 | following the @code{const}@var{b} bytecode. The constant @var{n} is | |
425 | always stored most significant byte first, regardless of the target's | |
426 | normal endianness. The constant is not guaranteed to fall at any | |
427 | particular alignment within the bytecode stream; thus, on machines where | |
428 | fetching a 16-bit on an unaligned address raises an exception, you | |
429 | should fetch @var{n} one byte at a time. | |
430 | ||
431 | @item @code{reg} (0x26) @var{n}: @result{} @var{a} | |
432 | Push the value of register number @var{n}, without sign extension. The | |
433 | registers are numbered following GDB's conventions. | |
434 | ||
435 | The register number @var{n} is encoded as a 16-bit unsigned integer | |
436 | immediately following the @code{reg} bytecode. It is always stored most | |
f821f325 | 437 | significant byte first, regardless of the target's normal endianness. |
c906108c SS |
438 | The register number is not guaranteed to fall at any particular |
439 | alignment within the bytecode stream; thus, on machines where fetching a | |
440 | 16-bit on an unaligned address raises an exception, you should fetch the | |
441 | register number one byte at a time. | |
442 | ||
443 | @item @code{trace} (0x0c): @var{addr} @var{size} @result{} | |
444 | Record the contents of the @var{size} bytes at @var{addr} in a trace | |
445 | buffer, for later retrieval by GDB. | |
446 | ||
447 | @item @code{trace_quick} (0x0d) @var{size}: @var{addr} @result{} @var{addr} | |
448 | Record the contents of the @var{size} bytes at @var{addr} in a trace | |
449 | buffer, for later retrieval by GDB. @var{size} is a single byte | |
450 | unsigned integer following the @code{trace} opcode. | |
451 | ||
452 | This bytecode is equivalent to the sequence @code{dup const8 @var{size} | |
453 | trace}, but we provide it anyway to save space in bytecode strings. | |
454 | ||
455 | @item @code{trace16} (0x30) @var{size}: @var{addr} @result{} @var{addr} | |
456 | Identical to trace_quick, except that @var{size} is a 16-bit big-endian | |
457 | unsigned integer, not a single byte. This should probably have been | |
458 | named @code{trace_quick16}, for consistency. | |
459 | ||
460 | @item @code{end} (0x27): @result{} | |
461 | Stop executing bytecode; the result should be the top element of the | |
462 | stack. If the purpose of the expression was to compute an lvalue or a | |
463 | range of memory, then the next-to-top of the stack is the lvalue's | |
464 | address, and the top of the stack is the lvalue's size, in bytes. | |
465 | ||
466 | @end table | |
467 | ||
468 | ||
469 | @node Using Agent Expressions | |
470 | @section Using Agent Expressions | |
471 | ||
782b2b07 SS |
472 | Agent expressions can be used in several different ways by @value{GDBN}, |
473 | and the debugger can generate different bytecode sequences as appropriate. | |
474 | ||
475 | One possibility is to do expression evaluation on the target rather | |
476 | than the host, such as for the conditional of a conditional | |
477 | tracepoint. In such a case, @value{GDBN} compiles the source | |
478 | expression into a bytecode sequence that simply gets values from | |
479 | registers or memory, does arithmetic, and returns a result. | |
480 | ||
481 | Another way to use agent expressions is for tracepoint data | |
482 | collection. @value{GDBN} generates a different bytecode sequence for | |
483 | collection; in addition to bytecodes that do the calculation, | |
484 | @value{GDBN} adds @code{trace} bytecodes to save the pieces of | |
485 | memory that were used. | |
c906108c SS |
486 | |
487 | @itemize @bullet | |
488 | ||
489 | @item | |
490 | The user selects trace points in the program's code at which GDB should | |
491 | collect data. | |
492 | ||
493 | @item | |
494 | The user specifies expressions to evaluate at each trace point. These | |
495 | expressions may denote objects in memory, in which case those objects' | |
496 | contents are recorded as the program runs, or computed values, in which | |
497 | case the values themselves are recorded. | |
498 | ||
499 | @item | |
500 | GDB transmits the tracepoints and their associated expressions to the | |
501 | GDB agent, running on the debugging target. | |
502 | ||
503 | @item | |
a5832c8f | 504 | The agent arranges to be notified when a trace point is hit. |
c906108c SS |
505 | |
506 | @item | |
507 | When execution on the target reaches a trace point, the agent evaluates | |
508 | the expressions associated with that trace point, and records the | |
509 | resulting values and memory ranges. | |
510 | ||
511 | @item | |
512 | Later, when the user selects a given trace event and inspects the | |
513 | objects and expression values recorded, GDB talks to the agent to | |
514 | retrieve recorded data as necessary to meet the user's requests. If the | |
515 | user asks to see an object whose contents have not been recorded, GDB | |
516 | reports an error. | |
517 | ||
518 | @end itemize | |
519 | ||
520 | ||
521 | @node Varying Target Capabilities | |
522 | @section Varying Target Capabilities | |
523 | ||
524 | Some targets don't support floating-point, and some would rather not | |
525 | have to deal with @code{long long} operations. Also, different targets | |
526 | will have different stack sizes, and different bytecode buffer lengths. | |
527 | ||
528 | Thus, GDB needs a way to ask the target about itself. We haven't worked | |
529 | out the details yet, but in general, GDB should be able to send the | |
530 | target a packet asking it to describe itself. The reply should be a | |
531 | packet whose length is explicit, so we can add new information to the | |
532 | packet in future revisions of the agent, without confusing old versions | |
533 | of GDB, and it should contain a version number. It should contain at | |
534 | least the following information: | |
535 | ||
536 | @itemize @bullet | |
537 | ||
538 | @item | |
539 | whether floating point is supported | |
540 | ||
541 | @item | |
542 | whether @code{long long} is supported | |
543 | ||
544 | @item | |
545 | maximum acceptable size of bytecode stack | |
546 | ||
547 | @item | |
548 | maximum acceptable length of bytecode expressions | |
549 | ||
550 | @item | |
551 | which registers are actually available for collection | |
552 | ||
553 | @item | |
554 | whether the target supports disabled tracepoints | |
555 | ||
556 | @end itemize | |
557 | ||
c906108c SS |
558 | @node Rationale |
559 | @section Rationale | |
560 | ||
561 | Some of the design decisions apparent above are arguable. | |
562 | ||
563 | @table @b | |
564 | ||
565 | @item What about stack overflow/underflow? | |
566 | GDB should be able to query the target to discover its stack size. | |
567 | Given that information, GDB can determine at translation time whether a | |
568 | given expression will overflow the stack. But this spec isn't about | |
569 | what kinds of error-checking GDB ought to do. | |
570 | ||
571 | @item Why are you doing everything in LONGEST? | |
572 | ||
573 | Speed isn't important, but agent code size is; using LONGEST brings in a | |
574 | bunch of support code to do things like division, etc. So this is a | |
575 | serious concern. | |
576 | ||
577 | First, note that you don't need different bytecodes for different | |
578 | operand sizes. You can generate code without @emph{knowing} how big the | |
579 | stack elements actually are on the target. If the target only supports | |
580 | 32-bit ints, and you don't send any 64-bit bytecodes, everything just | |
581 | works. The observation here is that the MIPS and the Alpha have only | |
582 | fixed-size registers, and you can still get C's semantics even though | |
583 | most instructions only operate on full-sized words. You just need to | |
584 | make sure everything is properly sign-extended at the right times. So | |
585 | there is no need for 32- and 64-bit variants of the bytecodes. Just | |
586 | implement everything using the largest size you support. | |
587 | ||
588 | GDB should certainly check to see what sizes the target supports, so the | |
589 | user can get an error earlier, rather than later. But this information | |
590 | is not necessary for correctness. | |
591 | ||
592 | ||
593 | @item Why don't you have @code{>} or @code{<=} operators? | |
594 | I want to keep the interpreter small, and we don't need them. We can | |
595 | combine the @code{less_} opcodes with @code{log_not}, and swap the order | |
596 | of the operands, yielding all four asymmetrical comparison operators. | |
597 | For example, @code{(x <= y)} is @code{! (x > y)}, which is @code{! (y < | |
598 | x)}. | |
599 | ||
600 | @item Why do you have @code{log_not}? | |
601 | @itemx Why do you have @code{ext}? | |
602 | @itemx Why do you have @code{zero_ext}? | |
603 | These are all easily synthesized from other instructions, but I expect | |
604 | them to be used frequently, and they're simple, so I include them to | |
605 | keep bytecode strings short. | |
606 | ||
607 | @code{log_not} is equivalent to @code{const8 0 equal}; it's used in half | |
608 | the relational operators. | |
609 | ||
610 | @code{ext @var{n}} is equivalent to @code{const8 @var{s-n} lsh const8 | |
611 | @var{s-n} rsh_signed}, where @var{s} is the size of the stack elements; | |
612 | it follows @code{ref@var{m}} and @var{reg} bytecodes when the value | |
613 | should be signed. See the next bulleted item. | |
614 | ||
615 | @code{zero_ext @var{n}} is equivalent to @code{const@var{m} @var{mask} | |
616 | log_and}; it's used whenever we push the value of a register, because we | |
617 | can't assume the upper bits of the register aren't garbage. | |
618 | ||
619 | @item Why not have sign-extending variants of the @code{ref} operators? | |
620 | Because that would double the number of @code{ref} operators, and we | |
621 | need the @code{ext} bytecode anyway for accessing bitfields. | |
622 | ||
623 | @item Why not have constant-address variants of the @code{ref} operators? | |
624 | Because that would double the number of @code{ref} operators again, and | |
625 | @code{const32 @var{address} ref32} is only one byte longer. | |
626 | ||
627 | @item Why do the @code{ref@var{n}} operators have to support unaligned fetches? | |
628 | GDB will generate bytecode that fetches multi-byte values at unaligned | |
629 | addresses whenever the executable's debugging information tells it to. | |
630 | Furthermore, GDB does not know the value the pointer will have when GDB | |
631 | generates the bytecode, so it cannot determine whether a particular | |
632 | fetch will be aligned or not. | |
633 | ||
634 | In particular, structure bitfields may be several bytes long, but follow | |
635 | no alignment rules; members of packed structures are not necessarily | |
636 | aligned either. | |
637 | ||
638 | In general, there are many cases where unaligned references occur in | |
639 | correct C code, either at the programmer's explicit request, or at the | |
640 | compiler's discretion. Thus, it is simpler to make the GDB agent | |
641 | bytecodes work correctly in all circumstances than to make GDB guess in | |
642 | each case whether the compiler did the usual thing. | |
643 | ||
644 | @item Why are there no side-effecting operators? | |
645 | Because our current client doesn't want them? That's a cheap answer. I | |
646 | think the real answer is that I'm afraid of implementing function | |
647 | calls. We should re-visit this issue after the present contract is | |
648 | delivered. | |
649 | ||
650 | @item Why aren't the @code{goto} ops PC-relative? | |
651 | The interpreter has the base address around anyway for PC bounds | |
652 | checking, and it seemed simpler. | |
653 | ||
654 | @item Why is there only one offset size for the @code{goto} ops? | |
655 | Offsets are currently sixteen bits. I'm not happy with this situation | |
656 | either: | |
657 | ||
658 | Suppose we have multiple branch ops with different offset sizes. As I | |
659 | generate code left-to-right, all my jumps are forward jumps (there are | |
660 | no loops in expressions), so I never know the target when I emit the | |
661 | jump opcode. Thus, I have to either always assume the largest offset | |
662 | size, or do jump relaxation on the code after I generate it, which seems | |
663 | like a big waste of time. | |
664 | ||
665 | I can imagine a reasonable expression being longer than 256 bytes. I | |
666 | can't imagine one being longer than 64k. Thus, we need 16-bit offsets. | |
667 | This kind of reasoning is so bogus, but relaxation is pathetic. | |
668 | ||
669 | The other approach would be to generate code right-to-left. Then I'd | |
670 | always know my offset size. That might be fun. | |
671 | ||
672 | @item Where is the function call bytecode? | |
673 | ||
674 | When we add side-effects, we should add this. | |
675 | ||
676 | @item Why does the @code{reg} bytecode take a 16-bit register number? | |
677 | ||
5e35df8e | 678 | Intel's IA-64 architecture has 128 general-purpose registers, |
c906108c SS |
679 | and 128 floating-point registers, and I'm sure it has some random |
680 | control registers. | |
681 | ||
682 | @item Why do we need @code{trace} and @code{trace_quick}? | |
683 | Because GDB needs to record all the memory contents and registers an | |
684 | expression touches. If the user wants to evaluate an expression | |
685 | @code{x->y->z}, the agent must record the values of @code{x} and | |
686 | @code{x->y} as well as the value of @code{x->y->z}. | |
687 | ||
688 | @item Don't the @code{trace} bytecodes make the interpreter less general? | |
689 | They do mean that the interpreter contains special-purpose code, but | |
690 | that doesn't mean the interpreter can only be used for that purpose. If | |
691 | an expression doesn't use the @code{trace} bytecodes, they don't get in | |
692 | its way. | |
693 | ||
694 | @item Why doesn't @code{trace_quick} consume its arguments the way everything else does? | |
695 | In general, you do want your operators to consume their arguments; it's | |
696 | consistent, and generally reduces the amount of stack rearrangement | |
697 | necessary. However, @code{trace_quick} is a kludge to save space; it | |
698 | only exists so we needn't write @code{dup const8 @var{SIZE} trace} | |
699 | before every memory reference. Therefore, it's okay for it not to | |
700 | consume its arguments; it's meant for a specific context in which we | |
701 | know exactly what it should do with the stack. If we're going to have a | |
702 | kludge, it should be an effective kludge. | |
703 | ||
704 | @item Why does @code{trace16} exist? | |
705 | That opcode was added by the customer that contracted Cygnus for the | |
706 | data tracing work. I personally think it is unnecessary; objects that | |
707 | large will be quite rare, so it is okay to use @code{dup const16 | |
708 | @var{size} trace} in those cases. | |
709 | ||
710 | Whatever we decide to do with @code{trace16}, we should at least leave | |
711 | opcode 0x30 reserved, to remain compatible with the customer who added | |
712 | it. | |
713 | ||
714 | @end table |