From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2960 invoked by alias); 3 Jan 2008 04:18:48 -0000 Received: (qmail 2951 invoked by uid 22791); 3 Jan 2008 04:18:48 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Jan 2008 04:18:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B22212A9633 for ; Wed, 2 Jan 2008 23:18:22 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FbxfE0XCtT9A for ; Wed, 2 Jan 2008 23:18:22 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E6BE22A95F8 for ; Wed, 2 Jan 2008 23:18:21 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id A1B79E7ACB; Wed, 2 Jan 2008 20:18:14 -0800 (PST) Date: Thu, 03 Jan 2008 04:18:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA] no frame needed when computing address of subprogram Message-ID: <20080103041814.GF15903@adacore.com> References: <20080101134652.GB3770@adacore.com> <20080102125718.GB30490@caradoc.them.org> <20080102134910.GE15903@adacore.com> <20080102140228.GA30326@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080102140228.GA30326@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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: 2008-01/txt/msg00030.txt.bz2 > > Still, your question still stands, who sets the block? I found > > inside write_var_or_type the following code: > > > > if (block == NULL) > > block = expression_context_block; > > > > Which at first sight would seem reasonable. This code predates me, > > so I'm not sure of the consequence of removing it. And there might > > be some other places down the road where we actually do the same. > > I will investigate more. Mamia mia, mucho complicacion if you remove this code... The function relies on the block being set properly to do the lookup. For instance, just slightly further down in that function, you have the following code: nsyms = ada_lookup_symbol_list (encoded_name, block, VAR_DOMAIN, &syms); If the block is not set, then the local symbols will not be found. There may be other places where we have the same issue, I didn't look further. Sooooo.... > Yes, I agree; the patch is OK. I just wanted to understand the > difference for Ada. ... Thanks! I checked the patch in. -- Joel