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