From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22684 invoked by alias); 23 Aug 2004 21:11:03 -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 22672 invoked from network); 23 Aug 2004 21:11:01 -0000 Received: from unknown (HELO us.ibm.com) (32.97.110.142) by sourceware.org with SMTP; 23 Aug 2004 21:11:01 -0000 Received: by us.ibm.com (Postfix, from userid 1000) id 7F4921117F; Mon, 23 Aug 2004 14:08:53 -0700 (PDT) From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: gdb-patches@sources.redhat.com Subject: Re: Avoid timeouts in call-sc.exp Date: Mon, 23 Aug 2004 21:11:00 -0000 User-Agent: KMail/1.6.2 References: <200408181426.30208.pgilliam@us.ibm.com> <4125D3DA.nailK4211PQ8Y@mindspring.com> In-Reply-To: <4125D3DA.nailK4211PQ8Y@mindspring.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408231408.53088.pgilliam@us.ibm.com> X-SW-Source: 2004-08/txt/msg00631.txt.bz2 Michael, What is the purpose of 'try_finish'? I don't see how the test 'if (try_finish == 0)' will ever fail to be true. What am I missing? -=# Paul #=- On Friday 20 August 2004 03:35, Michael Chastain wrote: > Paul Gilliam wrote: > > The test "call-sc.exp" will attemt to "finish" from main if the prevous > > "return foo" failed. Here is what happens: > > > > 257 gdb_test_multiple "return foo" "${test}" { > > > > If this works, then we are in "main". If it doesn't work (say, due to a > > gdb bug) then we are left in the function "fun". > > First, can you post the gdb.log section for call-sc.exp on your > platform that is failing. Also, what system is it and what > compiler are you using to run the test suite? > > Good analysis, but I think your fix is too complicated and stateful. > I'd like a different approach to this. Rather than handling various > different places where the program counter could be, it would be > better to do this at the end of the "return foo" test. > Something like this: > > # If the previous test did not work, the program counter might > # still be inside foo() rather than main(). Get the program > # counter back to main(). > # > # This happens on [system] with [compiler]. > > set try_finish 0 > set test "return foo; synchronize pc to main" > gdb_test_multiple "backtrace 1" $test { > -re "#0.*main \\(\\).*$gdb_prompt $" { > pass $test > } > -re "#0.*fun \\(\\).*$gdb_prompt $" { > if { $try_finish == 0 } { > incr try_finish > gdb_test "finish" ".*" "" > exp_continue > } > fail $test > } > } > > Also there is a pre-existing cut-and-paste error in the body of > "Make fun return now": > > -re "Make fun return now.*y or n. $" { > gdb_test_multiple "y" "${test}" { > -re "L *= fun.*${gdb_prompt} $" { > # Need to step off the function call > gdb_test "next" "zed.*" "${test}" > } > -re "L[expr + 1] *= fun[expr + 1].*${gdb_prompt} $" { > pass "${test}" > } > } > } > > The second arm, "L[expr + 1] *= ...", is supposed to handle the case > where returning from "fun" lands on the line after the call to "fun". > This happens when the compiler generates code so that the last assembly > instruction in "L = fun ();" is the actual assembly-language call > instruction. But the regular expression is wrong, it was copied from > structs.exp and it was meant for structs.c and does not work with > call-sc.c. > > I'll make a patch for the cut-and-pasto first. If you want to turn > the code snippet with "try_finish" into a patch and do some testing, > that would be great. Or I could make that into a patch. > > Michael