From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8519 invoked by alias); 7 Jul 2006 16:12:31 -0000 Received: (qmail 8508 invoked by uid 22791); 7 Jul 2006 16:12:30 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Jul 2006 16:12:27 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 16F1D48CF32; Fri, 7 Jul 2006 12:12:25 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21928-01-8; Fri, 7 Jul 2006 12:12:24 -0400 (EDT) Received: from takamaka.act-europe.fr (S0106000625ac85e1.vs.shawcable.net [70.71.27.110]) by nile.gnat.com (Postfix) with ESMTP id AE6D548CF2E; Fri, 7 Jul 2006 12:12:24 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id E29CD47EFA; Fri, 7 Jul 2006 09:12:23 -0700 (PDT) Date: Fri, 07 Jul 2006 16:12:00 -0000 From: Joel Brobecker To: Andrew STUBBS Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New substitute-path commands Message-ID: <20060707161223.GB971@adacore.com> References: <20060705215606.GF3580@adacore.com> <20060705230129.GA1145@nevyn.them.org> <20060706044733.GC673@adacore.com> <1152198199.6282.63.camel@dufur.beaverton.ibm.com> <20060706162952.GB24631@nevyn.them.org> <20060707052219.GA971@adacore.com> <44AE38B7.7060706@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AE38B7.7060706@st.com> User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00058.txt.bz2 > I think the suggested interface allowed a FROM argument for removing > that substitution alone. I still think this feature would be nice to have. Currently, we only provide one substitution rule, so the extra argument at this moment is not needed. My understanding is that, should more than one rule be needed, the plan is to provide this through a different type of interface - See Daniel's message. -- Joel