From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11977 invoked by alias); 12 Mar 2004 00:00:29 -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 11970 invoked from network); 12 Mar 2004 00:00:28 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 12 Mar 2004 00:00:28 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1a6F-0000KE-S6 for ; Thu, 11 Mar 2004 19:00:27 -0500 Date: Fri, 12 Mar 2004 00:00:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC Message-ID: <20040312000027.GA990@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20040306231743.GA9379@nevyn.them.org> <404BC4B2.7000100@gnu.org> <20040308032324.GA1325@nevyn.them.org> <20040308154814.GA17012@nevyn.them.org> <4050D13F.1040306@gnu.org> <20040311205751.GA28627@nevyn.them.org> <4050FA78.7020904@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050FA78.7020904@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00278.txt Message-ID: <20040312000000.nk0lDcDDHx3qz_a3BrIuLBZOXRantXAyhQxYPITmJTc@z> On Thu, Mar 11, 2004 at 06:47:04PM -0500, Andrew Cagney wrote: > >On Thu, Mar 11, 2004 at 03:51:11PM -0500, Andrew Cagney wrote: > > > >>>>>I hypothesize that if two consecutive frames, regardless of their type, > >>>>>claim to save the PC register at the same location, then unwinding is > >>>>>hosed. > >> > >>> > >>>It would need to do a deep analysis of the location (think about a > >>>register window architecture), hence I don't know that there's that much > >>>cost benefit. > > >>> Something simpler such as a list of functions known to > >>>terminate the stack might be more useful. > > > > > >Er, no. frame_unwind_register tells us where, relative to the current > >machine state, the register is saved. If it returns lval_register and > >real_regnum == O7_REGNUM, then that means it leaves in > >read_register(O7_REGNUM) at this moment, not that it did at some point > >in the past. Isn't that the point of the recursive unwinder? > > "Er, no". to which part? I'll assume the first half of the first half. > > I suspect you're violently agreeing with me here - you're describing > what I ment by a deep analysis of the location - tracking things all the > way back to where in the inferior the value is. The architecture > vector will need to be changed, the existing function deprecated, and > new methods implemented. The introduction of "struct location" (or > whatever) would then see it changed again. Given it is all for a > marginal edge case (and to cover up breakage in glibc), I don't see any > cost benefit in doing this. OK. It was just a thought :) It seems reasonable that whatever kind of location frame_unwind_register returns (which you're right, is likely to change) could naturally be returned by frame_unwind_pc also. But it would require playing with the interfaces pretty severely, so I'll just table the idea unless I run into this again somewhere else. > I think a more useful mechanism is for there to be a table of "start" > functions that the user could manipulate (but would default to values > specified by the OSABI). I'm not sure how useful that would really be; we seem to handle the entry points OK at the moment. And it couldn't be used for this case since we do want to backtrace past clone in some circumstances. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer