Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames
Date: Wed, 23 Apr 2008 13:53:00 -0000	[thread overview]
Message-ID: <200804231703.25325.vladimir@codesourcery.com> (raw)
In-Reply-To: <18447.12269.389044.431822@kahikatea.snap.net.nz>

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


  parent reply	other threads:[~2008-04-23 13:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-23  5:33 Nick Roberts
2008-04-23  5:48 ` Vladimir Prus
2008-04-23  6:03   ` Nick Roberts
2008-04-23  6:16     ` Vladimir Prus
2008-04-23  9:50       ` Nick Roberts
2008-04-23 10:32         ` Vladimir Prus
2008-04-23 13:23           ` Nick Roberts
2008-04-23 13:44             ` Daniel Jacobowitz
2008-04-23 23:04               ` Nick Roberts
2008-04-23 23:27                 ` Daniel Jacobowitz
2008-04-24  0:40                   ` Bob Rossi
2008-04-24  1:45                     ` Nick Roberts
2008-04-24  1:31                   ` Nick Roberts
2008-04-24  1:48                     ` Nick Roberts
2008-04-24 10:24                     ` Daniel Jacobowitz
2008-04-25  1:48                       ` Nick Roberts
2008-04-25  2:03                         ` Daniel Jacobowitz
2008-04-25 11:41                           ` Nick Roberts
2008-04-23 13:53             ` Vladimir Prus [this message]
2008-04-23 23:23               ` Nick Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200804231703.25325.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox