This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: getting rid of the target stack
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 27 Jun 2002 01:25:29 -0400
- Subject: Re: getting rid of the target stack
- References: <nphejp2tj1.fsf@zwingli.cygnus.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