This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: -var-update and address changes
On Saturday 15 April 2006 00:09, Daniel Jacobowitz wrote:
> On Fri, Apr 14, 2006 at 01:04:22PM -0700, Jim Ingham wrote:
> > If you have a disassembly view showing, and you are clicking around
> > on the stack, Xcode fetches enough code to fill the disassembly
> > window around the pc of the frame you've selected on the stack.
> > Having the pc returned with the stack frame eliminates one round
> > trip. People tend to nervously click around on the stack for no
> > apparent reason while they are thinking about the problem they are
> > working on. So this needs to be somewhat quick, though this one
> > round trip is probably negligible. OTOH the fewer things you have to
> > do by "send a request, wait for the reply, do the next request" the
> > easier it is to program on the client side. I wouldn't lean too hard
> > on this one way or another.
>
> Let me rephrase.
>
> This is the PC associated with the frame, right now. It's not the PC
> in the frame ID at all. That PC is the start of the function
> containing the frame.
And that PC is of some use too. I some distant future, I want to make KDevelop
remember the state of variables tree for a specific frame. Say, you've
entered function 'foo' and switched display format for variable 'mask' from
'natural' to 'binary'. You probably want binary format to be used whenever
you enter 'foo' next time. Using frame PC is one way to capture the current
frame. It's not ideal, since frame address can change on recompilation, but
on the other hand, the worst thing that will happen is that you'll use wrong
format for a variable, which is not big problems.
So, I think frame PC is useful on it's own.
- Volodya