This is the mail archive of the
mailing list for the GDB project.
Re: -var-update and address changes
- From: Jim Ingham <jingham at apple dot com>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 12 Apr 2006 09:37:04 -0700
- Subject: Re: -var-update and address changes
- References: <email@example.com>
On Apr 12, 2006, at 5:04 AM, Vladimir Prus wrote:
I'm running into what looks like a bug in -var-update. Basically, I
varobj with "&variable", then I enter a function that has a
the same name, and -var-update does not report anything.
Here's the code, and the gdb session.
int i = 10;
int i = 10;
i = foo();
And here's the session
-var-create TEST * &i
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
they were created, but that "binding" is not mentioned in
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,
different stack frames can have the same code address.
- I can't use -var-update, because it does not seem to report
- I can't use -var-update on variable addresses, because of the
So, the only solution is to remove all varobjs, and create them
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
on the Apple branch:
That way, frontend can deal with the issue of frame stacks
-var-update will be only used when single-stepping inside a given
Will patches to implement this be welcome?
That's what I would suggest. It seemed the simplest way to handle
this when we were first thinking about it.
And I still don't know what to do about variable shadowing inside a
I added another option to -stack-list-locals to print all the blocks
in a given function. Using this plus the option to have -stack-list-
locals return variable object, you will get all the shadowed
variables in the function as varobj's when you enter the function.
Then the varobj system will tell you which of these are in and out of
scope at any given PC. We also tell what the valid block is, but
Xcode doesn't use this info at present.
This all works in our branch if you want to see one example of how to