This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix a crash when stepping and unwinding fails


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]