From: Eli Zaretskii <eliz@gnu.org>
To: Siva Chandra <sivachandra@google.com>
Cc: tromey@redhat.com, dje@google.com, gdb-patches@sourceware.org
Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks
Date: Fri, 27 Apr 2012 15:38:00 -0000 [thread overview]
Message-ID: <83pqatgp9k.fsf@gnu.org> (raw)
In-Reply-To: <CAGyQ6gzqGh=ABfs9a5nnjAw0SyyONx+OGdEKGMcEmcOFom=yEA@mail.gmail.com>
> Date: Fri, 27 Apr 2012 16:33:06 +0530
> From: Siva Chandra <sivachandra@google.com>
> Cc: Tom Tromey <tromey@redhat.com>, Doug Evans <dje@google.com>, gdb-patches@sourceware.org
>
> On Thu, Apr 26, 2012 at 7:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Maybe I simply miss something important here. Â The text in question
> > says this:
> >
> > Â A @code{gdb.Block} is iterable. Â The iterator returns the symbols
> > Â (@pxref{Symbols In Python}) local to the block. Â Users using this
> > Â feature should keep in mind that future improvements to the internal
> > Â representation, of symbols and symbol tables, can move symbols across
> > Â blocks within a symbol table.
> >
> > Are you saying that future changes will prevent the possibility to
> > get the symbols local to the block by iterating it? Â That's not what
> > the last sentence above seems to say. Â It says that the symbols might
> > be found in a different block, or something to that effect. Â At least
> > that's what I understand from reading it. Â If my understanding is
> > correct, how would my Python program that works today break with
> > future versions of GDB?
>
> This is my thought: Take Tom's example of current 'globals' ending up
> in a namespace block due to a future change. Now, this is just an
> example. Meaning, a future existence of a namespace block is a
> speculation now. Since it is a speculation, it could eventually so
> happen that we will not have a namespace block but something else or
> nothing at all. Hence, how things would change are unknown now, but
> there is a chance that things will change. What Doug and Tom are
> trying to say is that, "It is OK to use the API now and for some time
> in future, but keep an eye out for changes and change accordingly."
> Also, since how things would change in future is unknown now, it is
> probably not possible to specify now as to how exactly would a Python
> program break in future.
OK, thanks. Then how about the following text?
A @code{gdb.Block} is iterable. The iterator returns the symbols
(@pxref{Symbols In Python}) local to the block. Python programs
should not assume that a specific block object will always contain a
given symbol, since changes in @value{GDBN} features and
infrastructure may cause symbols move across blocks in a symbol
table.
next prev parent reply other threads:[~2012-04-27 15:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 8:13 Siva Chandra
2012-04-25 9:02 ` Eli Zaretskii
2012-04-25 20:02 ` Tom Tromey
2012-04-25 21:02 ` Eli Zaretskii
2012-04-26 14:04 ` Tom Tromey
2012-04-26 14:17 ` Eli Zaretskii
2012-04-27 13:15 ` Siva Chandra
2012-04-27 15:38 ` Eli Zaretskii [this message]
2012-04-27 16:59 ` Doug Evans
2012-04-27 17:33 ` Eli Zaretskii
2012-04-27 17:46 ` Doug Evans
2012-04-27 19:42 ` Siva Chandra
2012-04-28 7:15 ` Eli Zaretskii
2012-04-30 19:20 ` Siva Chandra
2012-05-02 17:32 ` Siva Chandra
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=83pqatgp9k.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=sivachandra@google.com \
--cc=tromey@redhat.com \
/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