This is the mail archive of the gdb-patches@sourceware.org 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 16:47:41 Nick Roberts wrote:
>  >...
>  > > 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.

Of course it does, because for 2 (which are those floating varobjs), the
concept of frame varobj belongs is fairly moot.

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

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

It's there so that you can know where you function is called from, in case the
caller is assembler and there's no other information about location.
 
>  >...
>  > 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.

You've said "it is possible to infer to which frame that variable belongs" but did 
not explain neither how it's possible, nor why it's 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.

Yes, stack surely grows in the other directions on other architectures. But that's
probably not the main issue. What is the case when a user wants to know which frame a
variable having address XXX belongs to? If that variable is varobj, GUI probably
already recorded the association between varobj and frame and is in position to
show that directly.

- Volodya


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