From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21178 invoked by alias); 22 Feb 2006 22:00:36 -0000 Received: (qmail 21170 invoked by uid 22791); 22 Feb 2006 22:00:35 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 22 Feb 2006 22:00:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FC229-0000iC-M8; Wed, 22 Feb 2006 17:00:29 -0500 Date: Thu, 23 Feb 2006 02:04:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: sjackman@gmail.com, gdb-patches@sourceware.org Subject: Re: Fix a crash when stepping and unwinding fails Message-ID: <20060222220029.GA2609@nevyn.them.org> Mail-Followup-To: Mark Kettenis , sjackman@gmail.com, gdb-patches@sourceware.org References: <20060220220331.GA29363@nevyn.them.org> <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> <20060221202833.GA30161@nevyn.them.org> <200602212050.k1LKowmP012208@elgar.sibelius.xs4all.nl> <20060221205748.GA31483@nevyn.them.org> <200602212134.k1LLY3Sq028067@elgar.sibelius.xs4all.nl> <20060221215216.GA440@nevyn.them.org> <200602222154.k1MLsOxa008001@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602222154.k1MLsOxa008001@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00423.txt.bz2 On Wed, Feb 22, 2006 at 10:54:24PM +0100, Mark Kettenis wrote: > > Are there? I think there's only one - the outermost. We've only got > > that and the sentinel frame, and the sentinel frame I think doesn't > > have an ID. > > If we can't unwind from a frame for some reason, then its frame ID > will also be null_frame_id. And in multi-threaded programs there can > be multiple outermost frames. I suppose, but we should never ever ever be comparing frame IDs that belong to different threads, anyway. Admittedly they'll all normally be different, so equality tests would "normally" behave, but e.g. inner/outer would have no meaning. > > Perhaps part of the problem here is that step_frame_id is set to > > null_frame_id when it is invalid; maybe we should keep that separate. > > Not sure; it might not be necessary if we generate a proper frame ID > for the outermost frame. I don't think there is any way to do this. If we use the stack pointer, the frame ID will change as we single-step; and we can't use the frame pointer (because if we could, we could unwind). > > I don't think it would help me though. Perhaps the real problem is the > > use of null_frame_id for both the outermost frame and completely > > unknown frames. It would be nice if we could tell here: > > > > if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) > > > > that frame_unwind_id has returned something completely invalid instead > > of the outermost frame > > Indeed. > > > One way to do that in our current representation would be to check that > > the frame ID for the current frame is not null_ptid. > > Yes, I think it makes sense to punt trying to insert a step-resume > breakpoint earlier than you do in your patch. OK, that makes sense to me too. I'll give it a try! > > > > Just to sketch out my example a bit more: the embedded OS I'm debugging > > > > lives in ROM. The application I've supplied to GDB lives in RAM. In > > > > some later stage of the project, hopefully, I will have GDB magically > > > > load some other ELF files (that I don't have yet) to cover the ROM > > > > code; but right now I can't do that and there's no guarantee I'll have > > > > debug info covering all of it anyway. So we're executing code way > > > > out in the boondocks. GDB doesn't have any way on this platform > > > > (ARM Thumb) to guess where the start of a function is if it doesn't > > > > have a symbol table; so it can't be sure that we've really reached the > > > > first instruction of a function, so it has no idea whether $lr is valid > > > > or not. > > > > > > But that really means that we shouldn't be messing with step-resume > > > breakpoints here. The whole notion of functions that can be stepped > > > into isn't there. > > > > Yes, it is. I've executed "step" in a place where I do have symbol > > information (and working unwinders). It's taken me into a place where > > I don't (a DLL in ROM). Since I don't have debug information any more > > GDB would like to step back out to the call site, except it fails > > because we've moved out of its known area. > > Ah, ok. But that means that step_frame_id really shouldn't be equal > to null_frame_id. It will certainly not be null_frame_id if it isn't > the outermost frame. And whether the place where you issued "step" is > the outermost frame or not should not influence GDB's behaviour here. At the moment I believe I stepped from the outermost frame to a non-unwindable frame. So they're going to appear to have the same ID :-( This bit I'm going to have to think about some more. -- Daniel Jacobowitz CodeSourcery