Nick, Daniel, thanks much for your comments.

My test case wasn't simple enough. Now, I hope it's more clear:

newtest.c:
---------------------------------------------
int f11(int b)
{
  int a;

  a = b + 1;
  return a;   /* <- BP set here.  */
}

int main()
{
  int a = 1;

  a = f11(a);
  a = f11(a);
 
  return a;
}

MI commands used (CMD):
----------------------------------------------
100-interpreter-exec console echo
file exe
200-break-insert newtest.c:6
run
300-var-create - * a
301-var-create - * b
302-var-evaluate-expression var1
303-var-evaluate-expression var2
400-exec-continue
500-var-update var1
501-var-update var2
502-var-evaluate-expression var1
503-var-evaluate-expression var2
kill
quit

Debuggers ran with commands:
xt-gdb -q -nw --interpreter=mi <CMD >XTENSA.log
gdb -q -nw --interpreter=mi <CMD >NATIVE.log

The outputs are attached.

 > Aren't the variables associated with a particular frame ID? I thought
 > we'd decided that it was the right thing to take them out of scope.

This seems to be an answer to my question. The behavior has changed
probably since somewhere around 6.3. Now, variable objects are associated
with the frame, not with the function. As you can see in gdb 6.3 case
( NATIVE.log ), variables "var1" and "var2" were successfully reused,
when new frame was allocated after hitting the breakpoint second time.
In 6.5+ (XTENSA.log), we have to recreate variable objects every time
we have a new frame because the old variables are out of scope.

Correct ?

How about efficiency ? What if we have to create hundreds of variable
objects at every breakpoint hit ?

We kept staying with GNU gdb 5.2.1 for too long. So it looks like
we might have missed this important change, which is already in the
past for the majority of GNU gdb users.

-- Maxim


Nick Roberts wrote:
>  > >  >     - Are we supposed to recreate variables each time we enter the 
>  > >  > function ?
>  > >  >     - Is this efficient ?
>  > > 
>  > > Well the variables themselves are reallocated from the stack, so there's
>  > > a chance that they're not the same variables.  At the moment, however
>  > > GDB assumes that they are the same and you don't have to recreate them.
>  > 
>  > Aren't the variables associated with a particular frame ID?  I thought
>  > we'd decided that it was the right thing to take them out of scope.
>
> Maxim hadn't posted the test case when I replied.  Even now I'm not sure what
> the chain of events are.  If the second instance is when f11 is called by f1,
> then I agree it should be out of scope, and I think it always has been.  If it
> refers to the second time f11 is called from main (and the transcript seems to
> suggest this, although I've not looked too carefully) then GDB still considers
> this to be in scope.
>
>
>
>