Re: Fix a crash when stepping and unwinding fails

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Tue, 21 Feb 2006 15:57:48 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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