From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9570 invoked by alias); 24 Aug 2004 18:55:40 -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 9551 invoked from network); 24 Aug 2004 18:55:39 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sourceware.org with SMTP; 24 Aug 2004 18:55:39 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BzgSJ-0000G0-00; Tue, 24 Aug 2004 14:55:40 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id B44254B102; Tue, 24 Aug 2004 14:55:35 -0400 (EDT) Date: Tue, 24 Aug 2004 18:55:00 -0000 From: Michael Chastain To: pgilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: Avoid timeouts in call-sc.exp Message-ID: <412B8F25.nail1SD15JH17@mindspring.com> References: <200408181426.30208.pgilliam@us.ibm.com> <200408240913.38260.pgilliam@us.ibm.com> <412B7A5C.nailIQ211MRJW@mindspring.com> <200408241148.06913.pgilliam@us.ibm.com> In-Reply-To: <200408241148.06913.pgilliam@us.ibm.com> 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/msg00655.txt.bz2 Paul Gilliam wrote: > 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? Two things at a time. The problem in call-sc.exp is that it assumes that the inferior program is at a well-defined location after 'return'. When that's not true, it derails. I want to get that fixed. The problem in gdb is that 'return' is the I/O error on fpscr. It's yet another issue about recognizing the outermost frame on different ports, and I'm not going to care about that now.