From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28178 invoked by alias); 20 Aug 2004 08:51:17 -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 28171 invoked from network); 20 Aug 2004 08:51:16 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by sourceware.org with SMTP; 20 Aug 2004 08:51:16 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1By570-0003C8-00; Fri, 20 Aug 2004 04:51:03 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 39A264B102; Fri, 20 Aug 2004 04:51:24 -0400 (EDT) Date: Fri, 20 Aug 2004 08:51:00 -0000 From: Michael Chastain To: manjo@austin.ibm.com Subject: Re: gdb.gdb/ testcase issues. Cc: gdb@sources.redhat.com Message-ID: <4125BB8B.nailJWP1FZGHJ@mindspring.com> References: <41251A45.nail58D215HD7@mindspring.com> In-Reply-To: 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-08/txt/msg00245.txt.bz2 Manoj Iyer wrote: > Will get back to you on that. Okay. I can't accept any patches larger than trivial without a copyright assignment, though. > The reason is, the GDB that is shipped in a distro is stripped, and I used > the --tool_exec= option to use this GDB that is installed in /usr/bin. Ah, that is a valid use case for testing a stripped gdb. First it would help to file a PR to track this issue. It would be nice to have some common code for this. 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. Michael