This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH 00/13] Go closures, libffi, and the static chain
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libffi-discuss at sourceware dot org, gcc-patches at gcc dot gnu dot org, gofrontend-dev at googlegroups dot com
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Thu, 11 Dec 2014 10:06:23 +0100
- Subject: Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Authentication-results: sourceware.org; auth=none
- References: <1412973773-3942-1-git-send-email-rth at redhat dot com>
- Reply-to: libffi-discuss at sourceware dot org
On Fri, Oct 10, 2014 at 01:42:40PM -0700, Richard Henderson wrote:
> 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.
...
> But the comment immediately before __go_set_closure itself says
> that it would be better to use the static chain register.
...
> Before I go too much farther down this road, I wanted to get some
> feedback. FWIW, a complete tree can be found at [4].
...
> [4] git://github.com/rth7680/gcc.git rth/go-closure
1)
On s390x, the static chain register cannot be used for passing the
Go closure pointer to a function: According to the Abi, the
dynamic linker is allowed to destroy the contents of r0 (static
chain register) eventually causing a crash if libgo is linked
dynamically. The assumption that the static chain register can be
used to pass information to a function is wrong for s390x.
2)
With this branch, the reflection tests on amd64 crash:
$ cd <gcc source tree>/build
# build gcc
$ cd <targetdir>/libgo
$ make reflect/check
-->
-- snip --
Aborted
reflect.call
../../../libgo/runtime/go-reflect-call.c:216
reflect.call.N13_reflect.Value
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/value.go:579
reflect.Call.N13_reflect.Value
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/value.go:412
reflect_test.TestCallWithStruct
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/all_test.go:1490
testing.tRunner
../../../libgo/go/testing/testing.go:422
goroutine 16 [chan receive]:
testing.RunTests
../../../libgo/go/testing/testing.go:505
testing.Main
../../../libgo/go/testing/testing.go:435
main.main
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/_testmain.go:124
created by main
../../../libgo/runtime/go-main.c:42
goroutine 18 [finalizer wait]:
created by runtime_createfing
../../../libgo/runtime/mgc0.c:2572
goroutine 53 [sleep]:
reflect_test.selectWatcher
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/all_test.go:1377
created by reflect_test.$nested2
GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/all_test.go:1107
FAIL: reflect
make: *** [reflect/check] Error 1
-- snip --
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany