Re: getting rid of the target stack

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jun 27, 2002 at 12:13:38AM -0500, Jim Blandy wrote:
> 
> (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.

Hear hear!

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

I really like this proposal.  Where particularly were you thinking of
starting?

(and, hey, whatever happened to the namespace work we were discussing
earlier?)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer