From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25739 invoked by alias); 27 Jun 2002 14:44:02 -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 25638 invoked from network); 27 Jun 2002 14:43:59 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 27 Jun 2002 14:43:59 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2652D3C44; Thu, 27 Jun 2002 10:43:58 -0400 (EDT) Message-ID: <3D1B24AE.7060104@ges.redhat.com> Date: Thu, 27 Jun 2002 07:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: getting rid of the target stack References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00294.txt.bz2 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