This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Jim Ingham wrote:
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?
That's what I would suggest. It seemed the simplest way to handle this when we were first thinking about it.
FWIW, I've imp^H^H^Hkluged this by parsing the output of "info frame"
command. This gets me full frame id, but this should really be inside MI.
And I still don't know what to do about variable shadowing inside a single function.
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.
You mean, using -var-update and the "in_scope" attribute?
This all works in our branch if you want to see one example of how to do it.
Unfortunately, last time I tried it did not build on Linux.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |