This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] -stack-info-frame/-stack-list-frames
> > 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.