From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51763 invoked by alias); 22 Jul 2015 17:58:14 -0000 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 Received: (qmail 51752 invoked by uid 89); 22 Jul 2015 17:58:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Jul 2015 17:58:12 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 40CB239146C; Wed, 22 Jul 2015 17:58:11 +0000 (UTC) Received: from pinnacle.lan (ovpn-113-75.phx2.redhat.com [10.3.113.75]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6MHwAHk002567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Wed, 22 Jul 2015 13:58:10 -0400 Date: Wed, 22 Jul 2015 17:58:00 -0000 From: Kevin Buettner To: Doug Evans Cc: gdb-patches@sourceware.org, Pierre-Marie de Rodat , Pedro Alves Subject: Re: [PATCH] Add proper handling for non-local references in nested functions Message-ID: <20150722105807.3cb5f418@pinnacle.lan> In-Reply-To: References: <54F47563.4050103@adacore.com> <54FF0D05.70907@redhat.com> <550C1170.9070208@adacore.com> <55685B60.3000004@redhat.com> <55775EB0.4080701@adacore.com> <55AF5F7E.5000600@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00616.txt.bz2 On Wed, 22 Jul 2015 07:26:02 -0700 Doug Evans wrote: > One thought that comes to mind when reading the patch is that > you introduce the term "static link", and it doesn't mean what > the casual reader will think it means. > > E.g., > > + This method is designed to work with static links (nested > functions > + handling). Static links are function properties whose > evaluation return > + the frame base address for the enclosing frame. > > I think we need something less ambiguous / more clear. Perhaps the term "static chain" is better? That term, "static chain", has been around for a long while to describe a technique for implementing lexically scoped functions. E.g, I've found it in one of my (very old) textbooks where it is used in a discussion of the implementation of lexically scoped subprograms in the ALGOL language. On the other hand, DWARF has the DW_AT_static_link attribute. Its value is a "location description that computes the frame base of the relevant instance of the subroutine that immediately encloses the subroutine or entry point." AFAICT, the terms "static link" and "static chain" mean the same thing in the context of lexically scoped functions. I think we should use one of these phrases unless someone knows of yet another term which is commonly used in this context. Kevin