Red Hat ENTERPRISE LINUX 4 - DEVELOPER TOOLS GUIDE, Manual

Page: 372 / 410

362 Appendix E. The GDB Agent Expression Mechanism
E.6. Rationale
Some of the design decisions apparent above are arguable.
What about stack overflow/underflow?
GDB should be able to query the target to discover its stack size. Given that information, GDB
can determine at translation time whether a given expression will overflow the stack. But this
spec isn’t about what kinds of error-checking GDB ought to do.
Why are you doing everything in LONGEST?
Speed isn’t important, but agent code size is; using LONGEST brings in a bunch of support code
to do things like division, etc. So this is a serious concern.
First, note that you don’t need different bytecodes for different operand sizes. You can generate
code without knowing how big the stack elements actually are on the target. If the target only
supports 32-bit ints, and you don’t send any 64-bit bytecodes, everything just works. The obser-
vation here is that the MIPS and the Alpha have only fixed-size registers, and you can still get
C’s semantics even though most instructions only operate on full-sized words. You just need to
make sure everything is properly sign-extended at the right times. So there is no need for 32- and
64-bit variants of the bytecodes. Just implement everything using the largest size you support.
GDB should certainly check to see what sizes the target supports, so the user can get an error
earlier, rather than later. But this information is not necessary for correctness.
Why don’t you have
j
or
k
=
operators?
I want to keep the interpreter small, and we don’t need them. We can combine the
less_
opcodes
with
log_not
, and swap the order of the operands, yielding all four asymmetrical comparison
operators. For example,
(x
k
= y)
is
! (x
j
y)
, which is
! (y
k
x)
.
Why do you have
log_not
?
Why do you have
ext
?
Why do you have
zero_ext
?
These are all easily synthesized from other instructions, but I expect them to be used frequently,
and they’re simple, so I include them to keep bytecode strings short.
log_not
is equivalent to
const8 0 equal
; it’s used in half the relational operators.
ext
n
is equivalent to
const8
s-n
lsh const8
s-n
rsh_signed
, where
s
is the size of the
stack elements; it follows
ref
m
and
reg
bytecodes when the value should be signed. See the next
bulleted item.
zero_ext
n
is equivalent to
const
m mask
log_and
; it’s used whenever we push the value of
a register, because we can’t assume the upper bits of the register aren’t garbage.
Why not have sign-extending variants of the
ref
operators?
Because that would double the number of
ref
operators, and we need the
ext
bytecode anyway
for accessing bitfields.
Why not have constant-address variants of the
ref
operators?
Because that would double the number of
ref
operators again, and
const32
address
ref32
is only one byte longer.
Why do the
ref
n
operators have to support unaligned fetches?
GDB will generate bytecode that fetches multi-byte values at unaligned addresses whenever the
executable’s debugging information tells it to. Furthermore, GDB does not know the value the