Re: Fix a crash when stepping and unwinding fails

[NZG <ngustavson at emacinc dot com>]

I don't understand a lot of this tecnical discussion, but I think I have a 
useful comment so I'm going to throw it out there. 
If it's stupid, please ignore.

I believe I recently battled this exact problem on the Coldfire architecture 
with gdb-6.2.
It didn't seem to have a way to know it had reached the end of it's frame list 
without consulting the dwarf symbol table, which didn't help before the code 
had actually entered into main.

My quick and dirty solution was to enable the use of 
deprecated_inside_entry_file 
which the comments warn against, but does seem to work at least in this 
situation.

Somehow this function succeeds in detecting the state is in the entry file and 
stops unwinding, perhaps it bears more investigation.

NZG

diff -Naur gdb-6.1/gdb/frame.c gdb-6.1-5282/gdb/frame.c
--- gdb-6.1/gdb/frame.c	2004-02-16 15:49:21.000000000 -0600
+++ gdb-6.1-5282/gdb/frame.c	2006-01-30 10:29:16.000000000 -0600
@@ -1880,7 +1880,10 @@
      normaly and following frames are treated as being inside the
      enttry file then.  This way, only the #0 frame is printed in the
      backtrace output.  */
-  if (0
+     /**NZG enabled for expermentation**/
+     
+     
+  if (1
       && this_frame->type != DUMMY_FRAME && this_frame->level >= 0
       && deprecated_inside_entry_file (get_frame_pc (this_frame)))
     {





On Wednesday 22 February 2006 4:00 pm, Daniel Jacobowitz wrote:
> 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.