Hi,
I'm running into what looks like a bug in -var-update. Basically, I
create a
varobj with "&variable", then I enter a function that has a
variable with
the same name, and -var-update does not report anything.
Here's the code, and the gdb session.
int foo()
{
int i = 10;
++i;
return i;
}
int main()
{
int i = 10;
i = foo();
return i;
}
And here's the session
-break-insert a.cpp:12
^done,....
(gdb)
-break-insert a.cpp:5
^done,....
(gdb)
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",.....
(gdb)
-var-create TEST * &i
^done,name="TEST",numchild="1",type="int *"
(gdb)
-exec-continue
^running
(gdb)
*stopped,reason="breakpoint-hit",.......
(gdb)
-var-update *
^done,changelist=[]
(gdb)
The value of "&i" changes, but -var-update does not report this.
This can be
explained by the fact that varobjs are "bound" to the stack frame
where
they were created, but that "binding" is not mentioned in
documentation.
The problem I'm trying to solve is this:
1. In some frame, I create varobj for 'i'.
2. After continue, I see that there's local variable 'i', and I
want to find
out if previously-created varobj can be used to show this local
'i', or if
I should create new 'i'.
- I can't use frame ids because gdb only prints code address,
and two
different stack frames can have the same code address.
- I can't use -var-update, because it does not seem to report
anything
- I can't use -var-update on variable addresses, because of the
above
report
So, the only solution is to remove all varobjs, and create them
afresh,
which is contrary to the very purpose of varobjs.
Can somebody suggest the right fix? So far, I think that the simplest
approach is to make gdb print stack address of current frame, like
is done
on the Apple branch:
553^done,stack=[frame=
{level="0",addr="0x00003db0",fp="0xbffff2c0",......
That way, frontend can deal with the issue of frame stacks
themself, and
-var-update will be only used when single-stepping inside a given
frame.
Will patches to implement this be welcome?