This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libgo, arm64] Future of reflection

On Wed, Oct 1, 2014 at 2:14 PM, Richard Henderson <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]