On Wed, Oct 1, 2014 at 2:14 PM, Richard Henderson <r...@redhat.com> wrote:
>
> I've been looking at reflection, and support for non-x86 targets.
>
> In mainline, there's some support for using libffi, but I wasn't completely
> confident that things are working correctly. It doesn't help that the
> testsuite still has conditionals like
>
> func TestMakeFunc(t *testing.T) {
> switch runtime.GOARCH {
> case "amd64", "386":
> default:
> t.Skip("MakeFunc not implemented for " + runtime.GOARCH)
> }
Wait, what sources are you looking at? I took that out on July 19.
> So I decided to just rip out the non-libffi paths completely. Honestly, the
> result looks good from a maintenance standpoint:
>
> 17 files changed, 31 insertions(+), 1290 deletions(-)
>
> There's one really questionable portion in value.Pointer, where we really have
> nothing useful to return. There appears to be nothing that actually tests
> this, so it's hard to tell, but I believe this to have been broken before my
> patch when using libffi. Now, at least, the randomness of the value is
> apparent.
I think that value.Pointer is vaguely meaningful when applied to an
ordinary func value. I agree that it is useless when applied to a
function created by MakeFunc. I don't think there is any useful way
to use value.Pointer for a function value in any case.
> I do question why use of libffi wasn't unconditional in the first place. It
> seems to put non-x86 as second-class citizens. If a direct implementation is
> that much better, then why don't we just write them for the other targets?
Partly historical reasons. I wrote the x86 support because I didn't
know that libffi had closures. But then even using closures, the x86
support looks a lot nicer: it doesn't have to call mmap. All the mmap
stuff is elegant and is necessary for C style function pointers, but
it's not necessary for Go func values since they carry their own
closures anyhow. So, yes, I think we should write direct
implementations for other targets that we care about.
Ian
