From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18399 invoked by alias); 27 Jun 2002 05:25:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18392 invoked from network); 27 Jun 2002 05:25:33 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 27 Jun 2002 05:25:33 -0000 Received: from 01-051.118.popsite.net ([66.19.120.51] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17NRmb-0003Vu-00; Thu, 27 Jun 2002 00:25:30 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17NRmb-00044v-00; Thu, 27 Jun 2002 01:25:29 -0400 Date: Wed, 26 Jun 2002 22:25:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: getting rid of the target stack Message-ID: <20020627052529.GA15598@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00289.txt.bz2 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