Re: [PATCH] -stack-info-frame/-stack-list-frames

[Vladimir Prus <vladimir@codesourcery.com>]

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