This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] -stack-info-frame/-stack-list-frames
On Wednesday 23 April 2008 12:52:52 you wrote:
> > > The frame address is probably of more interest than the pc address, at
> > > least for frames other than the current one. If the call stack includes
> > > the frame address for each frame and the watch window gives the variable's
> > > address then it is possible to infer to which frame that variable belongs.
> >
> > What do you mean by "watch window" here, and how the information about frame
> > a variable belongs to is useful?
>
> I mean the window showing a variable's value (represented in Gdb as a variable
> object).
Does that window shows:
1. Value of variable named XXX in the frame where that variable was
added to the window?
2. Value of variable named XXX in the current frame
3. Something else?
>
> > > In any case, the extra field comes at almost no cost and a frontend can
> > > choose to ignore it.
> >
> > I supposed you don't plan to write documentation that say "these fields are
> > just in case you need them, feel free to ignore"?
>
> Not really because that applies equally to all the other fields, already
> present, that a front end might not use.
Well, for other frames I know what they are used for.
> > I'm trying to understand
> > what is *your* intended use of this information, so that I can make up my
> > mind as to best way to do that. We talked about frame ids before, I think
> > Dan prefers frame ids, if exposed, to be totally opaque. You appear to
> > suggest some smart uses of frame addresses, on the other hand, and I don't
> > understand exactly what uses.
>
> I'm just intending to present the frame address to the user to help him
> understand what he's looking at, not use it as a frame id in any rigorous way.
> I see that the Totalview debugger presents this information in their call stack
> (which they call stack trace) window and I think this would be useful, for the
> reason, I've given too.
Well, I still fail to see what further "understanding" the user might get
from that information, but I'd be happy to be told :-)
My biggest worry about this is that we'll be providing some information which
is highly compiler dependent and which we cannot document in any way other that
"it is hex number". I don't think a random frontend author knows what DWARF CFI
is :-)
- Volodya