From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22334 invoked by alias); 21 Feb 2006 21:34:42 -0000 Received: (qmail 22315 invoked by uid 22791); 21 Feb 2006 21:34:41 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 21:34:39 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k1LLY3hl017839; Tue, 21 Feb 2006 22:34:03 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k1LLY3jc020417; Tue, 21 Feb 2006 22:34:03 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k1LLY3Sq028067; Tue, 21 Feb 2006 22:34:03 +0100 (CET) Date: Tue, 21 Feb 2006 21:53:00 -0000 Message-Id: <200602212134.k1LLY3Sq028067@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: sjackman@gmail.com, gdb-patches@sourceware.org In-reply-to: <20060221205748.GA31483@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 21 Feb 2006 15:57:48 -0500) Subject: Re: Fix a crash when stepping and unwinding fails 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> 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/msg00412.txt.bz2 > Date: Tue, 21 Feb 2006 15:57:48 -0500 > From: Daniel Jacobowitz > > 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? But get_current_frame() should be the innermost frame when we execute this code. So the prologue analyzer can't be involved here. However, yes, it seems that step_frame_idd can end up as null_frame_id, if get_current_frame() is also the outermost frame at the same time. > > > 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. Yes, it seems there are issues here. The frame ID is supposed to be unique for a particular frame, yet there's a possibility that two distinct frames both end up with the null frame ID. > 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. Mark