From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31274 invoked by alias); 21 Feb 2006 20:57:53 -0000 Received: (qmail 31265 invoked by uid 22791); 21 Feb 2006 20:57:53 -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; Tue, 21 Feb 2006 20:57:51 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBeZw-0008E7-4J; Tue, 21 Feb 2006 15:57:48 -0500 Date: Tue, 21 Feb 2006 21:03: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: <20060221205748.GA31483@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602212050.k1LKowmP012208@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/msg00410.txt.bz2 On Tue, Feb 21, 2006 at 09:50:58PM +0100, Mark Kettenis wrote: > But if step_frame_id is equal to null_frame_id, we shouldn't be trying > to insert step-resume-breakpoints. It means that step_frame_id is > still uninitialized, since step_frame_id is initialized by: > > step_frame_id = get_frame_id (get_current_frame ()); > > (or equivalent code), and unwinding from sentinel frame shoud always > yield a frame ID that's different from null_frame_id. It's this assumption I don't think is right. I have plenty of anecdotal evidence from yesterday that it's not right, in fact. If the prologue analyzer can't handle the code at $pc, then what do you expect it to put into the frame ID? Or if it thinks we are in the outermost frame? > > That seems like a good change indeed, but probably wouldn't fix this > > problem. > > > > Hmm, what does frame_pc_unwind do when we've hit the last frame? I'm > > not sure it's meaningful. > > How can we hit the last frame? If we're hitting the last frame, where > did we come from? > > It may very well be that there are GDB bugs that make step_frame_id > equal to null_frame_id. If we can't trace those bugs right now, we > should probably sprinkle a few gdb_assert()'s around and try to solve > the issues when we hit those. We use the null frame ID to represent the outermost frame. If we can't find another frame outer to this one, then we assume this one is the outermost. 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. -- Daniel Jacobowitz CodeSourcery