From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31676 invoked by alias); 24 Aug 2004 18:50:17 -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 31649 invoked from network); 24 Aug 2004 18:50:15 -0000 Received: from unknown (HELO us.ibm.com) (32.97.110.142) by sourceware.org with SMTP; 24 Aug 2004 18:50:15 -0000 Received: by us.ibm.com (Postfix, from userid 1000) id 0579E1117F; Tue, 24 Aug 2004 11:48:06 -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: Tue, 24 Aug 2004 18:50:00 -0000 User-Agent: KMail/1.6.2 Cc: Michael Chastain References: <200408181426.30208.pgilliam@us.ibm.com> <200408240913.38260.pgilliam@us.ibm.com> <412B7A5C.nailIQ211MRJW@mindspring.com> In-Reply-To: <412B7A5C.nailIQ211MRJW@mindspring.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408241148.06913.pgilliam@us.ibm.com> X-SW-Source: 2004-08/txt/msg00652.txt.bz2 Here is a diff between the two logs from where their difference is non-trivial: < Running target unix/-m32 --- > Running target unix/-m64 94,95c94,95 < "finish" not meaningful in the outermost frame. < (gdb) FAIL: gdb.base/call-sc.exp: finish foo; return call-sc-tc --- > Run till exit from #0 main () at ./gdb.base/call-sc.c:78 > FAIL: gdb.base/call-sc.exp: finish foo; return call-sc-tc (timeout) Here is the $64000 question: why did GDB recognize we were in the outermost frame for the 32-bit case and not for the 64-bit case? Is main() not the outermost frame for ppc64 but is for ppc32? Guess I'll have to break-down and check the API's. -=# Paul #=- On Tuesday 24 August 2004 10:26, Michael Chastain wrote: > Good logs! > > Both of the logs show similar de-synchronization. > > The problem starts here in ppc32.gdb.log: > > p/c L > $2 = 90 'Z' > (gdb) PASS: gdb.base/call-sc.exp: zed L for return; return call-sc-tc > return foo > Make fun return now? (y or n) y > reading register fpscr (#70): Input/output error. > (gdb) FAIL: gdb.base/call-sc.exp: return foo; return call-sc-tc > p/c L > $3 = 90 'Z' > (gdb) FAIL: gdb.base/call-sc.exp: value foo returned; return call-sc-tc > advance fun > main () at ./gdb.base/call-sc.c:78 > 78 L = fun (); > (gdb) FAIL: gdb.base/call-sc.exp: advance to fun for finish; return > call-sc-tc p/c L > > I presume the I/O error on fpscr is a bug in gdb. > After the bug happens, variable 'L' is not set to its new value. > And then "advance" starts from some de-synchronized place. > > ppc64.gdb.log has the same problem.