This is the mail archive of the gdb@sources.redhat.com 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: Further cache generating if PC is 0?


On Jun 23 14:27, Jason Molenda wrote:
> 
> On Jun 23, 2005, at 2:13 PM, Mark Kettenis wrote:
> 
> >   cf http://sources.redhat.com/ml/gdb-patches/2005-06/msg00060.html
> >
> >Well, I still seem to remember that at one moment in time, around the
> >time the i386 was converted to using the new frame unwinding code,
> >there was a fairly common case on Linux systems where the assumption
> >that there MUST be a frame didn't hold.
> 
> With my patch, if a function could be potentially frameless and we  
> can't parse the prologue or we don't know where the function starts,  
> I assume it's frameless.  If the function must have set up a frame, I  
> assume it set up a frame using the standard save-the-caller's-ebp idiom.
> 
> It's entirely reasonable to argue that my assumptions are incorrect.   
> But if -fomit-frame-pointer code exists on the stack, *no*  
> assumptions are correct.  The current code isn't correct, my code  
> isn't correct.  The only correct thing to do is abort the stack  
> backtrace and insist that gdb can't continue.

That's basically what I was asking.  As long as the current code
doesn't undergo a major rewrite as mentioned in the above thread,
I'd say that something as

  cache->pc = frame_func_unwind (next_frame);
  if (!cache->pc)
    {
      cache->base = 0;
      return cache;
    }

would be more correct.  However, the above thread implies that it's
too late to worry about it ;-)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.


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