Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tom Tromey <tromey@redhat.com>
Cc: sivachandra@google.com, gdb-patches@sourceware.org
Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks
Date: Thu, 26 Apr 2012 14:17:00 -0000	[thread overview]
Message-ID: <83fwbqinsw.fsf@gnu.org> (raw)
In-Reply-To: <87397qa9a0.fsf@fleche.redhat.com>

> From: Tom Tromey <tromey@redhat.com>
> Cc: sivachandra@google.com, gdb-patches@sourceware.org
> Date: Thu, 26 Apr 2012 07:54:15 -0600
> 
> I think the idea is to warn Python developers that they should test
> their code with future versions if they use this feature.
> Normally we try to maintain compatibility, even when we've made mistakes.
> But in this case, we suspect we may make changes and we don't want to
> promise compatibility; but nor do we want to block this feature until
> the symbol tables are changed, since that may not happen for some time.

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?


  reply	other threads:[~2012-04-26 14:14 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 [this message]
2012-04-27 13:15           ` Siva Chandra
2012-04-27 15:38             ` Eli Zaretskii
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=83fwbqinsw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --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