[libgo, arm64] Future of reflection

[Richard Henderson <rth at redhat dot com>]

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)
        }

Anyway, I thought I'd see what happens if I enable use of libffi for x86 too.
Even there, just --with-libffi doesn't actually do anything, since we still
have tests like

        switch runtime.GOARCH {
        case "amd64", "386":
                // Indirect Go func value (dummy) to obtain actual
                // code address. (A Go func value is a pointer to a C
                // function pointer. http://golang.org/s/go11func.)
                dummy := makeFuncStub
                code = **(**uintptr)(unsafe.Pointer(&dummy))
        default:
                code, ffi = makeFuncFFI(ftyp, fn)
        }

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.

One might be able to generate a similar value by Knowing Things about the
internals of libffi (and adjusting it as necessary to match our expectations).

(A thought occurs to me just now, which I haven't investigated: why don't we
compare the pointer of the receiver function, rather than the closure wrapper?)

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?

I've done this for arm64 (based on the 4.9 branch, since that's important
internally at the moment, and may be less invasive than backporting the libffi
code), and it at least passes the testsuite.

Thoughts?


r~

Attachment: commit-always-libffi
Description: Text document

Attachment: commit-reflect-amd64
Description: Text document