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 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


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