From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24089 invoked by alias); 28 Aug 2004 05:50:20 -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 24071 invoked from network); 28 Aug 2004 05:50:18 -0000 Received: from unknown (HELO e33.co.us.ibm.com) (32.97.110.131) by sourceware.org with SMTP; 28 Aug 2004 05:50:18 -0000 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7S5oHDD611574; Sat, 28 Aug 2004 01:50:17 -0400 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7S5kEhs129202; Fri, 27 Aug 2004 23:50:17 -0600 Received: from lazy.austin.ibm.com (lazy.austin.ibm.com [9.53.94.97]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i7RG67Rn037052; Fri, 27 Aug 2004 11:06:07 -0500 Date: Sat, 28 Aug 2004 05:50:00 -0000 From: Manoj Iyer X-X-Sender: manjo@lazy To: Michael Chastain cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] GDB testsuite patch. (revised version) In-Reply-To: <412F5AC5.nail34Y11MNPE@mindspring.com> Message-ID: References: <41251A45.nail58D215HD7@mindspring.com> <4125BB8B.nailJWP1FZGHJ@mindspring.com> <20040825124945.GA25217@nevyn.them.org> <412C98BD.nail10P1YTPHK@mindspring.com> <412F49BA.nailEDT11A0NY@mindspring.com> <412F5AC5.nail34Y11MNPE@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-08/txt/msg00762.txt.bz2 Yes that looks cool. I will wait for you to commit, and I shall send a patch to that effect. Thanks Michael ----- Manjo +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Cognito ergo sum + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Fri, 27 Aug 2004, Michael Chastain wrote: > Manoj Iyer wrote: > > The problem is that there are other tests that run just fine even if no > > debugging symbols are found. This means if you change gdb_load to check if > > no debugging symbols are found and return a -ive value this might harm the > > other testcase. > > Right. You tried that, and Daniel pointed out that it was wrong, > and I agreed. > > > I will be happy to submit that patch, and see if you like my idea. > > It's such a good idea, I already started implementing something > like that. > > Here is the new header for gdb_file_cmd: > > # Load a file into the debugger. > # The return value is a list with the following information: > # > # { message word ... } > # > # MESSAGE has the following values: > # > # "" file was loaded successfully > # "..." file was not loaded successfully. > # An error or perror has been generated with MESSAGE. > # > # If the MESSAGE is "", then there is an optional set of words. > # The words may be: > # > # nodebug this file does not contain debug information > # > # TODO: gdb.base/sepdebug.exp and gdb.stabs/weird.exp might > # be able to use this if they can get more information > # in the return value. > > TCL is all about lists and strings, and it makes life a lot > easier to return a nice list of strings. > > If this still looks like a good idea in a few hours, and I commit it, > then you can write gdb.gdb/*.exp like this: > > set oldtimeout $timeout > set timeout 600 > verbose "Timeout is now $timeout seconds" 2 > > set status [gdb_load $executable] > > set timeout $oldtimeout > verbose "Timeout is now $timeout seconds" 2 > > if { [lindex $status 0] != "" } then { > # Error has already been printed. > return -1 > } > > if { [lsearch -exact [lreplace $status 0 0] "nodebug"] } then { > untested "no debugging information for $executable" > return -1 > } > > Or something like that. > > How does that look? >