From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20000 invoked by alias); 8 Mar 2004 00:56:24 -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 19969 invoked from network); 8 Mar 2004 00:56:18 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 8 Mar 2004 00:56:18 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E47BE2B98; Sun, 7 Mar 2004 19:56:18 -0500 (EST) Message-ID: <404BC4B2.7000100@gnu.org> Date: Mon, 08 Mar 2004 00:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC References: <20040306231743.GA9379@nevyn.them.org> In-Reply-To: <20040306231743.GA9379@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00144.txt > Here's an updated version of a little hack I've been using since GDB 6.0. > If we are in a nested normal frame, i.e. something whose next frame is a > function that it called in the normal way, and we didn't find a saved PC, > we're going to be stuck in a loop. We might have been able to figure out > the frame size, but not where the return address was stored; as the comment > says, this happens in glibc's clone function. Of course the problem there > is that it _doesn't_ save $ra in the normal fashion; it won't return. > > Without this patch schedlock.exp falls apart, because backtraces continue > forever printing "clone()" on every line. > > OK? No! > + if (frame_relative_level (next_frame) >= 0 > + && get_frame_type (next_frame) == NORMAL_FRAME > + && !trad_frame_addr_p (info->saved_regs, NUM_REGS + PC_REGNUM)) The whole point of this recursive code is that you don't need to add hacks that look down the stack at the type of more inner frames :-/ Can you post the relevant assembler so that we can determine why the prologue analyzer is failing. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20000 invoked by alias); 8 Mar 2004 00:56:24 -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 19969 invoked from network); 8 Mar 2004 00:56:18 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 8 Mar 2004 00:56:18 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E47BE2B98; Sun, 7 Mar 2004 19:56:18 -0500 (EST) Message-ID: <404BC4B2.7000100@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC References: <20040306231743.GA9379@nevyn.them.org> In-Reply-To: <20040306231743.GA9379@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00144.txt.bz2 Message-ID: <20040319000900.E8VgPtdel3L57s_7pSw7oP1OBxSgpt4HVwyrI1dUSN0@z> > Here's an updated version of a little hack I've been using since GDB 6.0. > If we are in a nested normal frame, i.e. something whose next frame is a > function that it called in the normal way, and we didn't find a saved PC, > we're going to be stuck in a loop. We might have been able to figure out > the frame size, but not where the return address was stored; as the comment > says, this happens in glibc's clone function. Of course the problem there > is that it _doesn't_ save $ra in the normal fashion; it won't return. > > Without this patch schedlock.exp falls apart, because backtraces continue > forever printing "clone()" on every line. > > OK? No! > + if (frame_relative_level (next_frame) >= 0 > + && get_frame_type (next_frame) == NORMAL_FRAME > + && !trad_frame_addr_p (info->saved_regs, NUM_REGS + PC_REGNUM)) The whole point of this recursive code is that you don't need to add hacks that look down the stack at the type of more inner frames :-/ Can you post the relevant assembler so that we can determine why the prologue analyzer is failing. Andrew