This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wednesday 23 April 2008 09:03:10 Nick Roberts wrote:
>  > > Here's a patch to add the frame address to the output of -stack-info-frame
>  > > and -stack-list-frames and async output when execution stops.  It also
>  > > outputs the source language for -stack-info-frame, these change making it
>  > > more like "info frame":
>  > 
>  > Could you first clarify that is the purpose of said fields -- especially
>  > frame address?
> 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? 

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

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]