From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5942 invoked by alias); 25 Aug 2004 12:49:51 -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 5692 invoked from network); 25 Aug 2004 12:49:48 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 25 Aug 2004 12:49:48 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BzxDm-0006aP-5L; Wed, 25 Aug 2004 08:49:46 -0400 Date: Wed, 25 Aug 2004 12:49:00 -0000 From: Daniel Jacobowitz To: Manoj Iyer Cc: Michael Chastain , gdb@sources.redhat.com Subject: Re: [RFC] GDB testsuite patch. Message-ID: <20040825124945.GA25217@nevyn.them.org> Mail-Followup-To: Manoj Iyer , Michael Chastain , gdb@sources.redhat.com References: <41251A45.nail58D215HD7@mindspring.com> <4125BB8B.nailJWP1FZGHJ@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00364.txt.bz2 On Tue, Aug 24, 2004 at 11:29:12PM -0500, Manoj Iyer wrote: > > Hi all, > > Here is a patch to gdb/lib/gdb.exp, this patch handles the case when the > GDB that is tested is stripped and has no debugging information. > > I have created this patch according to Michael's recomendations (see > below). Michael wrote: > > Three of the four test scripts in gdb.gdb have their own 'setup_test', > > and the fourth script has another copy of the same code. I would like > > to see the common code factored into one place, lib/self-support.exp. > > > > Then setup_test calls gdb_load which calls gdb_file_cmd. You could get > > into gdb_file_cmd and detect "(no debugging symbols found)" and add a > > channel to return that information. Or, in setup_test, you could > > do something right after the call to gdb_load to check for debugging > > symbols. > > > > If there are no debugging symbols, then I think that the test script > > should return one UNRESOLVED result and not continue testing. > > > > I'm not sure UNRESOLVED is the right result. Perhaps UNTESTED would > > be better. But not UNSUPPORTED -- UNSUPPORTED means that a feature > > is missing in the system under test. That's not the same as what you've done. gdb_file_cmd should not always fail for objects without debugging information, since there are other tests that work OK without it. This only applies to the gdb.gdb/ tests. -- Daniel Jacobowitz