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

Nick Roberts
2008-04-23T08:53:34Z

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