From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29588 invoked by alias); 10 Sep 2004 18:30:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29569 invoked from network); 10 Sep 2004 18:30:09 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sourceware.org with SMTP; 10 Sep 2004 18:30:09 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1C5q9u-0002mf-00; Fri, 10 Sep 2004 14:30:06 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 057A14B102; Fri, 10 Sep 2004 14:30:31 -0400 (EDT) Date: Fri, 10 Sep 2004 18:30:00 -0000 From: Michael Chastain To: cagney@gnu.org Subject: Re: [patch/testsuite] revert return-type of gdb_file_cmd, gdb_load Cc: gdb-patches@sources.redhat.com Message-ID: <4141F2C7.nailIB81I9LLG@mindspring.com> References: <4140FD5A.nail2UI11H9ND@mindspring.com> <4141EFBF.2010009@gnu.org> In-Reply-To: <4141EFBF.2010009@gnu.org> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00170.txt.bz2 Andrew Cagney wrote: > What of two interfaces -> an existing one with preserved behavior and a > new one with extended behavior? In a way, that's what we have now. The "extended behavior" is to set the global variable gdb_file_cmd_debug_info. The problem with "two interfaces" is that there really are nine different procedures named gdb_load, and the caller does not know which of the nine procedures is active. So the new interface has to be compatible with the old, or I have to change nine implementations of "gdb_load" simultaneously. Also, if gdb.gdb/*.exp runs in an environment where the implementation of gdb_load does not provide this extended behavior, then it will see that gdb_file_cmd_debug_info is still set to "unset" and it can react appropriately. From inspection, I believe the only gdb_load that will *not* get the extended behavior is the stubby "not implemented yet" implementation in config/nind.exp. Michael