From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14568 invoked by alias); 27 Jun 2002 05:13:41 -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 14561 invoked from network); 27 Jun 2002 05:13:39 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 27 Jun 2002 05:13:39 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 87C9F5EA11; Thu, 27 Jun 2002 00:13:38 -0500 (EST) To: gdb@sources.redhat.com Subject: getting rid of the target stack From: Jim Blandy Date: Wed, 26 Jun 2002 22:13:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00288.txt.bz2 (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.