getting rid of the target stack

[Jim Blandy <jimb at redhat dot com>]

(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.