From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15840 invoked by alias); 5 Nov 2014 21:34:03 -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 15809 invoked by uid 89); 5 Nov 2014 21:34:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e9.ny.us.ibm.com Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 05 Nov 2014 21:33:54 +0000 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 5 Nov 2014 16:33:51 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 5 Nov 2014 16:33:49 -0500 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 62BBAC90042 for ; Wed, 5 Nov 2014 16:25:53 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sA5LXmff19923006 for ; Wed, 5 Nov 2014 21:33:48 GMT Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sA5LXl3I022493 for ; Wed, 5 Nov 2014 16:33:48 -0500 Received: from oc2602623110.ibm.com (oc2602623110.ibm.com.rchland.ibm.com [9.10.86.28]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sA5LXkxw022454; Wed, 5 Nov 2014 16:33:47 -0500 Message-ID: <545A97BA.3030507@linux.vnet.ibm.com> Date: Wed, 05 Nov 2014 21:34:00 -0000 From: "Lynn A. Boger" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Richard Henderson , gcc-patches@gcc.gnu.org CC: libffi-discuss@sourceware.org, gofrontend-dev@googlegroups.com Subject: Re: [PATCH 00/13] Go closures, libffi, and the static chain References: <1412973773-3942-1-git-send-email-rth@redhat.com> In-Reply-To: <1412973773-3942-1-git-send-email-rth@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14110521-0033-0000-0000-000000F62749 X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00180.txt.bz2 What about the libffi changes that are needed to make this work on other platforms, like PowerPC? On 10/10/2014 03:42 PM, Richard Henderson wrote: > Pardon the wide distribution, the obvious hacks, and the failure > to properly split up the largest of the libffi patches. > > The background here is my thread from last week[1], and Ian's reply[2], > wherein he rightly points out that not needing to play games with > mmap in order to implement closures for Go is a strong reason to > continue using custom code within libgo. > > While that thread did have a go at implementing that custom code for > aarch64, I still think that replicating libffi's calling convention > knowledge for every interesting target is a mistake. > > So instead I thought about how I'd add some support for Go directly > into libffi. After all, we've got some custom code in libffi for > Java, why couldn't Go have the same treatment? > > The stickler, as far as I could see, is __go_set_context. I didn't > like the idea of libffi needing a callback into libgo in order to > accomplish the goal. > > But the comment immediately before __go_set_closure itself says > that it would be better to use the static chain register. So I set > about to see how easy that would be to accomplish. (And not for > nothing such a change would make gccgo compiled programs faster > by avoiding the library calls.) > > The following patch set enables this for x86_64, i386, and aarch64[3]. > > The first two patches enable a static chain to be set by the front end > on CALL_EXPRs, and to be used with indirect function calls. The third > patch is a horrible hack to expose this feature to the C front end. > > The 4th patch changes gccgo to use the static chain. I don't bother > with checking to see that the target has one. All targets currently > supported by libgo have one, so I don't really see this as a stumbling > block. > > The 5th patch changes libgo to use the static chain. I admit that I > haven't tested this patch solo; I simply split it out of a larger patch > for clarity. > > The 6th patch adds interfaces to libffi for Go; these interfaces are > used within libgo in the 8th patch. > > Patches 7, 10, 11, 12, 13 are all enabling the new libffi interface on > the aforementioned targets. There's lots of cleanup in here, and I > owe the libffi list smaller reviewable changes. I ask that libffi > ignore patches 10 and 12 for now and comment on the meat instead. > > Before I go too much farther down this road, I wanted to get some > feedback. FWIW, a complete tree can be found at [4]. > > Thanks, > > > r~ > > > [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00098.html > [2] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00102.html > [3] Except that after rebasing the tree on yesterday's trunk, > I discovered that i386 and aarch64 both have bootstrap > problems on trunk. Ouch. > [4] git://github.com/rth7680/gcc.git rth/go-closure > > > Richard Henderson (13): > Make TARGET_STATIC_CHAIN allow a function type > Allow the front-end to create calls with a static chain > HACK! Allow the static chain to be set from C > Use the static chain as the closure parameter from Go > libgo: Use the static chain for the closure > libffi: Add entry points for interacting with Go > libffi: Support go closures on x86_64 > libgo: Use the new libffi interfaces for Go > libgo: Remove __go_get/set_closure > libffi: Rewrite aarch64 > libffi: Support go closures on aarch64 > libffi: Rewrite i386 sysv > libffi: Support go closures on i386 > > gcc/c-family/c-common.c | 1 + > gcc/c-family/c-common.h | 2 +- > gcc/c/c-parser.c | 29 + > gcc/calls.c | 14 +- > gcc/config/i386/i386.c | 19 +- > gcc/config/moxie/moxie.c | 5 +- > gcc/config/xtensa/xtensa.c | 2 +- > gcc/doc/tm.texi | 2 +- > gcc/gimple-fold.c | 21 + > gcc/gimplify.c | 17 +- > gcc/go/go-gcc.cc | 44 +- > gcc/go/gofrontend/backend.h | 7 +- > gcc/go/gofrontend/expressions.cc | 21 +- > gcc/go/gofrontend/gogo.cc | 29 +- > gcc/go/gofrontend/gogo.h | 14 + > gcc/go/gofrontend/runtime.def | 6 - > gcc/target.def | 6 +- > gcc/targhooks.c | 5 +- > gcc/testsuite/gcc.dg/static-chain.c | 31 + > gcc/tree-cfg.c | 22 +- > libffi/include/ffi.h.in | 16 + > libffi/src/aarch64/ffi.c | 1380 ++++++++++++++--------------------- > libffi/src/aarch64/ffitarget.h | 18 +- > libffi/src/aarch64/internal.h | 43 ++ > libffi/src/aarch64/sysv.S | 557 +++++++------- > libffi/src/x86/ffi.c | 1161 ++++++++++++----------------- > libffi/src/x86/ffi64.c | 103 ++- > libffi/src/x86/ffitarget.h | 112 ++- > libffi/src/x86/internal.h | 48 ++ > libffi/src/x86/sysv.S | 1003 +++++++++++++++---------- > libffi/src/x86/unix64.S | 319 ++++---- > libgo/go/reflect/makefunc.go | 49 +- > libgo/go/reflect/makefunc_386.S | 22 +- > libgo/go/reflect/makefunc_amd64.S | 13 +- > libgo/go/reflect/makefunc_ffi.go | 67 +- > libgo/go/reflect/makefunc_ffi_c.c | 68 +- > libgo/go/reflect/value.go | 3 + > libgo/runtime/go-reflect-call.c | 10 +- > libgo/runtime/malloc.goc | 8 - > libgo/runtime/mgc0.c | 3 +- > libgo/runtime/proc.c | 20 - > libgo/runtime/runtime.h | 4 - > libgo/runtime/time.goc | 3 +- > 43 files changed, 2624 insertions(+), 2703 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/static-chain.c > create mode 100644 libffi/src/aarch64/internal.h > create mode 100644 libffi/src/x86/internal.h >