Red Hat ENTERPRISE LINUX 3 - SECURITY GUIDE, Manual

Page: 363 / 410

Appendix E.
The GDB Agent Expression Mechanism
In some applications, it is not feasable for the debugger to interrupt the program’s execution long
enough for the developer to learn anything helpful about its behavior. If the program’s correctness
depends on its real-time behavior, delays introduced by a debugger might cause the program to fail,
even when the code itself is correct. It is useful to be able to observe the program’s behavior without
interrupting it.
Using GDB’s
trace
and
collect
commands, the user can specify locations in the program, and
arbitrary expressions to evaluate when those locations are reached. Later, using the
tfind
command,
she can examine the values those expressions had when the program hit the trace points. The expres-
sions may also denote objects in memory -- structures or arrays, for example -- whose values GDB
should record; while visiting a particular tracepoint, the user may inspect those objects as if they were
in memory at that moment. However, because GDB records these values without interacting with the
user, it can do so quickly and unobtrusively, hopefully not disturbing the program’s behavior.
When GDB is debugging a remote target, the GDB
agent code running on the target computes the
values of the expressions itself. To avoid having a full symbolic expression evaluator on the agent,
GDB translates expressions in the source language into a simpler bytecode language, and then sends
the bytecode to the agent; the agent then executes the bytecode, and records the values for GDB to
retrieve later.
The bytecode language is simple; there are forty-odd opcodes, the bulk of which are the usual vocab-
ulary of C operands (addition, subtraction, shifts, and so on) and various sizes of literals and memory
reference operations. The bytecode interpreter operates strictly on machine-level values -- various
sizes of integers and floating point numbers -- and requires no information about types or symbols;
thus, the interpreter’s internal data structures are simple, and each bytecode requires only a few na-
tive machine instructions to implement it. The interpreter is small, and strict limits on the memory
and time required to evaluate an expression are easy to determine, making it suitable for use by the
debugging agent in real-time applications.
E.1. General Bytecode Design
The agent represents bytecode expressions as an array of bytes. Each instruction is one byte long
(thus the term bytecode ). Some instructions are followed by operand bytes; for example, the
goto
instruction is followed by a destination for the jump.
The bytecode interpreter is a stack-based machine; most instructions pop their operands off the stack,
perform some operation, and push the result back on the stack for the next instruction to consume.
Each element of the stack may contain either a integer or a floating point value; these values are as
many bits wide as the largest integer that can be directly manipulated in the source language. Stack
elements carry no record of their type; bytecode could push a value as an integer, then pop it as a
floating point value. However, GDB will not generate code which does this. In C, one might define
the type of a stack element as follows:
union agent_val {
LONGEST l;
DOUBLEST d;
};
where
LONGEST
and
DOUBLEST
are
typedef
names for the largest integer and floating point types on
the machine.