On Tue, Nov 12, 2013 at 1:40 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Fri, Sep 27, 2013 at 10:54 AM, Ian Lance Taylor <i...@google.com> wrote: >> The Go standard library has an interesting function named >> reflect.MakeFunc. It takes a Go function F that accepts and returns a >> slice of reflect.Value, and a function type T, and returns a pointer to >> a function of type T that converts its arguments to reflect.Value, calls >> F, and converts the returned reflect.Value into the appropriate return >> types. In effect this is the reverse of libffi: instead of describing a >> function and calling it, we describe a function and permit it to be >> called. >> >> For gccgo I tried to implement this generically using the builtin >> varargs functions, but that failed because I had no way to handle the >> return type. Many Go functions return multiple values, which in gccgo >> is represented as returning a struct, and, of course, in some cases a >> struct is returned by passing a hidden pointer as the first argument, >> and in other cases is handled by splitting up the struct into different >> register classes. So handling this generically is essentially >> impossible, at least without adding some more builtin functions to >> somehow handle the return value, builtin functions that I couldn't >> figure out how to even represent. >> >> So I gave up and went for a processor-specific approach. The idea is >> that processor-specific assembly code will save all the relevant >> registers into a struct, and pass them to processor-specific Go code >> which will implement the calling convention. This has the advantage >> that I only need to deal with Go types, which in particular means no >> worries about vector types. >> >> This patch implements this approach for x86_64. Bootstrapped and ran Go >> testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.8 >> branch. >> > > Hi Ian, > > TestMakeFunc failed on x32: > > FAIL: TestMakeFunc (0.00 seconds) > all_test.go:1457: Call returned 10, 20, 30, [40 0], 60, 70, 80; want 10, > 20, 30, [40, 50], 60, 70, 80 > > The difference in x32 is x32 puts 2 pointers (32-bit) in one 64-git > register. Somehow, the second pointer in > > type two [2]uintptr > > isn't returned properly.. Do you know what I should check for x32? >
type two [2]uintptr is an array. It should pass and return in memory for x32. -- H.J.
