From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6035 invoked by alias); 23 Apr 2012 15:05:41 -0000 Received: (qmail 6016 invoked by uid 22791); 23 Apr 2012 15:05:39 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_NIX_SPAM,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Apr 2012 15:05:25 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M2X00M00TSJYC00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 23 Apr 2012 18:05:17 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.249.186]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M2X00MPVTWSUS40@a-mtaout21.012.net.il>; Mon, 23 Apr 2012 18:05:17 +0300 (IDT) Date: Mon, 23 Apr 2012 16:00:00 -0000 From: Eli Zaretskii Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) In-reply-to: <4F95630D.1000202@redhat.com> To: Phil Muldoon Cc: tromey@redhat.com, sivachandra@google.com, dje@google.com, ratmice@gmail.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83vckqfpzb.fsf@gnu.org> References: <831unms3jy.fsf@gnu.org> <4F8F187D.3050402@redhat.com> <878vhsojgd.fsf@fleche.redhat.com> <87sjfyi5rj.fsf@fleche.redhat.com> <87lilmh9jf.fsf@fleche.redhat.com> <4F95595A.8080106@redhat.com> <83y5pmft8k.fsf@gnu.org> <4F95630D.1000202@redhat.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00748.txt.bz2 > Date: Mon, 23 Apr 2012 15:11:25 +0100 > From: Phil Muldoon > CC: tromey@redhat.com, sivachandra@google.com, dje@google.com, > ratmice@gmail.com, gdb-patches@sourceware.org > > I am just not sure we should have compatibility warnings that the > content/structure of these blocks may change in some undefined way, > at some future time. With that I agree. Saying such things in a manual is never a good idea, unless we also describe in detail what exactly can go wrong, how to detect that, and how to work around.