From: Daniel Jacobowitz <drow@false.org>
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 23:27:00 -0000 [thread overview]
Message-ID: <20080423222414.GA23569@caradoc.them.org> (raw)
In-Reply-To: <18447.46315.956290.915310@kahikatea.snap.net.nz>
On Thu, Apr 24, 2008 at 10:15:07AM +1200, Nick Roberts wrote:
> But thats a good cas in point. If the frontend end is to operate in a
> stateless manner, as Vladimir has suggested, and varobjs are created in
> non-selected frames, it needs to know the frame addresses:
>
> -var-create - FRAME-ADDR EXPRESSION
No, it doesn't. We need to kill that interface. It needs to go away.
You gave a perfect example in your other reply, just now, of why front
ends should not have a frame address. If you are ever in the position
of dealing with a recursive function and you want to know which
instance a variable comes from, the frame address is insufficient.
For instance IA-64 can have stackless recursive functions; they
use only the separate register stack.
If you want to know which frame the varobj is associated with GDB
should supply some unique opaque identifier, and then the IDE can
use that to show the frame number in a tooltip or wherever.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-04-23 22:24 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 [this message]
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
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=20080423222414.GA23569@caradoc.them.org \
--to=drow@false.org \
--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