From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1842 invoked by alias); 1 Feb 2012 16:02:00 -0000 Received: (qmail 1832 invoked by uid 22791); 1 Feb 2012 16:01:59 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Feb 2012 16:01:42 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q11G1f6J025223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Feb 2012 11:01:41 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q11G1fAZ019222; Wed, 1 Feb 2012 11:01:41 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q11G1d0X026466; Wed, 1 Feb 2012 11:01:39 -0500 From: Tom Tromey To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: RFA: fix PR python/13351 References: Date: Wed, 01 Feb 2012 16:02:00 -0000 In-Reply-To: (Doug Evans's message of "Tue, 31 Jan 2012 15:13:50 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-02/txt/msg00013.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> I think a bit of discussion is needed. [Sorry!] No problem. Doug> Are we sure we want lookup_symbol to work when there is no frame? Doug> [it doesn't feel very clean to me, but maybe I just need to look at it Doug> differently] lookup_symbol already works without a frame, if you pass in a block. To me it seemed reasonable to extend this to search the global blocks. After all, even with a block argument it might return a symbol from a global block -- it is just that there is no way to request this from the start. That is, I didn't see a particular compelling reason for the current restriction. What is the point of this error? What seems not-clean to you? Actually I wonder whether this patch goes far enough. I think perhaps it should be possible to write lookup_symbol(block = None) to get the no-frame behavior; and also lookup_symbol(block = some_frame) to take the block from an explicit frame. Tom