Re: [RFC] Prints the frame id when target stops

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jan 17, 2007 at 02:34:34AM +0300, Vladimir Prus wrote:
> On Wednesday 17 January 2007 00:12, Nick Roberts wrote:
> >  > > We'd like to avoid refreshing the thread and the frame view when the user
> >  > > perform a step (or a next) and when the program stops in the same thread
> >  > > and in the same frame.  In the stop reason we got the current thread id,
> >  > > but we are missing something to identify the frame.  That patch lets gdb
> >  > > emits on the MI output a string that could be used to easily identify the
> >  > > current frame.  If you are ok with this approach then I'll update the
> >  > > testsuite.
> >  > 
> >  > Would not a better approach be to modify -stack-list-frames and friends,
> >  > so that they check frame id internally, and it has not changed, just
> >  > return the same result? Such approach will uniformly help all frontends,
> >  > and won't expose new concepts in the interface.
> > 
> > It would change the behviour of those commands but I guess it could be added
> > as an option.  
> 
> It actually won't. If -stack-list-frames is changed to return cached result
> when it's absolutely clear that the stack did not change, you have no behaviour
> change, just better performance.

But Nick is right - it is very hard to determine whether two frames
with the same frame ID are the same frame across an operation.  It'd be
nice if that weren't the case.  The hard case for this is unfortunately
very hard - but if the front end knows that it did a single step, then
it's very unlikely to be wrong if the ID is unchanged.  I really don't
know what the right thing to do here is.  Guessing based on what the
last execution was (step, next, vs continue or C-c) might be the best
we can do :-(

Here's how it can happen:

int foo()
{
  return 1;
}

int bar()
{
  char buf[SIZE1];
  return foo();
}

int bar2()
{
  char buf[SIZE2];
  return foo();
}

int bar3()
{
  char buf[SIZE3];
  return bar2();
}

int main()
{
  bar();
  bar3();
}

The backtrace is different in an interesting way here if you set a
breakpoint on foo and continue twice, but if you choose your buffer
sizes just right, then you can get the two calls to foo to have the
same ID.  If your IDE doesn't refresh its stack display, you're
going to have a stale call trace.

Apple implemented a very high performance, light weight unwinder that
just does frame IDs - on PPC this happens to be quite easy.  We could
make other targets do the same thing.  That probably helps here.

-- 
Daniel Jacobowitz
CodeSourcery