getting rid of the target stack

getting rid of the target stack

[Jim Blandy]

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

Re: getting rid of the target stack

[Daniel Jacobowitz]

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

Re: getting rid of the target stack

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> I really like this proposal.  Where particularly were you thinking of
> starting?

No particular time.  This isn't even something that's related to any
internal Red Hat plan, unlike the thread-local storage, namespace
stuff, etc.  It just occurred to me how it could be done
incrementally.

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

It's on my schedule somewhere after thread-local storage and Dwarf 2
duplicate removal.  I don't remember the dates too well, but I think
that means I'll be able to start pitching in in Sept/Oct.

Re: getting rid of the target stack

[Andrew Cagney]

Just FYI,

The problem is that the current target stack implementation is serving 
two masters:

- a layer/stack of targets - thread on top of raw/remote.  This is a 
true stack.  As with a stack, each has an above and below and can 
propogate requests through it.  This part of the architecture works.

- the vineer - live, core, file - are all ``targets'' that can be 
switched between and mechanisms that allow GDB to fall back to other 
layers if one can't provide it.

Some incremental things that have been pointed out in the past include:

- making the targets true objects - eliminate that global state

- tighten/fix the target stack interfaces so that people don't keep 
bypassing them (or worse, as in the hw breakpoint stuff avoiding adding 
them to the vector).

Andrew

Namespaces; Was: getting rid of the target stack

[Andrew Cagney]

>> (and, hey, whatever happened to the namespace work we were discussing
>> earlier?)
> 
> 
> It's on my schedule somewhere after thread-local storage and Dwarf 2
> duplicate removal.  I don't remember the dates too well, but I think
> that means I'll be able to start pitching in in Sept/Oct.

Hmm, of all the new features GDB needs, the ability to handle namespace 
support, would have to be top of the list.  The bug database is littered 
with PRs related to this.

So things are really clear, I take it that while people have floated 
some interesting ideas, no one is working on this.  Remember, we need to 
be very careful to not give the impression that this task is under 
control (it isn't) and someone is already doing the work (the oposite is 
the truth - we need someone to step forward and do their ``worst'' :-).

enjoy,
Andrew