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

[Nick Roberts <nickrob@snap.net.nz>]

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

It doesn't really matter how it was created.


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

(by frames you mean fields?)

Really?  In the output of -stack-list-frames what are the pc address field for
the outer frames used for?

 >...
 > Well, I still fail to see what further "understanding" the user might get
 > from that information, but I'd be happy to be told :-)

I've already given a reason why I think it would be useful.

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

If it was just a hex number, the concept of frame address presumably wouldn't
exist.  To me, it refers to the start of the frame and if a variable has an
address below that value, it belongs to that frame or a higher one.  Maybe on
some architectures, the stack grows in the other direction, and maybe there are
other anomalies, but a user could understand this and interpret such numbers.

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