This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
getting rid of the target stack
- From: Jim Blandy <jimb at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: 27 Jun 2002 00:13:38 -0500
- Subject: getting rid of the target stack
(Probably Andrew has some document already written up about this, with
puzzling pictures and everything, but I'll describe the idea anyway.)
The target stack is a pain in the neck for a variety of reasons:
1) It's not a stack; we're always sticking things in the middle, and
shlorking them out again later.
2) The elements of the (non-)stack are modules, not objects. Each
layer has its own global variables and global state, which makes it
hard to see what's going on.
One model that seems nicer to me is one in which each thing like a
core file, a remote protocol connection, or a Linux inferior would be
an object, with hand-coded vtable, instance variables and all. All
their state would be encapsulated in the instance; you could have
several alive simultaneously; and so on. This would be part of the
support needed to have GDB talk to multiple processes simultaneously,
for example.
You'd get the layering effect the target stack gives you now by having
a constructor take a "backup" target object as an argument, to which
it would delegate method calls it didn't want to handle itself.
Rather than pushing layer A above layer B, you'd use B as A's "backup"
target object.
So assuming this is actually a good idea, how could you get to there
from here?
Well, you'd start with the target layers that currently always live at
the bottom of the stack. You could re-write them one at a time in the
more object-oriented style I described above, and use a compatibility
target layer to talk to them. Then you'd convert the next layers up.
Where the code now invokes the next lower target method or directly
calls a particular lower layer's functions, you'd replace that with an
operation on the "backup" object.
Eventually, you'd have all the different layers' state nicely
encapsulated, and that part of GDB would get a lot easier to
understand.