From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30032 invoked by alias); 7 Nov 2014 23:55:04 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 30009 invoked by uid 89); 7 Nov 2014 23:55:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f46.google.com Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Nov 2014 23:55:01 +0000 Received: by mail-pa0-f46.google.com with SMTP id lf10so4474124pab.33 for ; Fri, 07 Nov 2014 15:54:59 -0800 (PST) X-Received: by 10.68.98.131 with SMTP id ei3mr7412390pbb.127.1415404499587; Fri, 07 Nov 2014 15:54:59 -0800 (PST) Received: from bubble.grove.modra.org (CPE-58-160-155-134.oycza5.sa.bigpond.net.au. [58.160.155.134]) by mx.google.com with ESMTPSA id ns3sm9730569pbb.75.2014.11.07.15.54.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Nov 2014 15:54:58 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 95A8DEA4722; Sat, 8 Nov 2014 10:24:46 +1030 (ACDT) Date: Fri, 07 Nov 2014 23:55:00 -0000 From: Alan Modra To: Ian Taylor Cc: Richard Henderson , "Lynn A. Boger" , gcc-patches , libffi-discuss@sourceware.org, "gofrontend-dev@googlegroups.com" , Ian Lance Taylor Subject: Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain Message-ID: <20141107235446.GE3990@bubble.grove.modra.org> Mail-Followup-To: Ian Taylor , Richard Henderson , "Lynn A. Boger" , gcc-patches , libffi-discuss@sourceware.org, "gofrontend-dev@googlegroups.com" , Ian Lance Taylor References: <1412973773-3942-1-git-send-email-rth@redhat.com> <545A97BA.3030507@linux.vnet.ibm.com> <545B1C44.3000306@redhat.com> <20141106124838.GJ30857@bubble.grove.modra.org> <545B71D1.1090406@redhat.com> <545C770A.9040100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014/txt/msg00205.txt.bz2 On Fri, Nov 07, 2014 at 08:06:52AM -0800, Ian Taylor wrote: > Closures exist only for nested functions and for functions created by > reflect.MakeFunc and friends. > > Storing a top-level function into a variable will give you something > that looks like it has a closure, but the closure will always be empty > and it will never be used. The indirect call will set the closure > value in the static chain register, but the register will not be used > by the function being called. Good, this was something I was still worried about, because the mere fact that a call is indirect doesn't guarantee it won't hit a plt stub. Many ABIs define the address of a non-local function in an executable to be the address of the plt stub code for that function. So it is quite possible for an indirect call to bounce through a plt stub. Various linker optimisations make this fairly uncommon, for instance the GNU powerpc linkers won't do this unless the function address is taken in the executable by non-PIC (see pointer_equality_needed in BFD code). -- Alan Modra Australia Development Lab, IBM