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

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > 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).

 > > 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.

 >                                                  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.

-- 
Nick http://www.inet.net.nz/~nickrob