On Fri, Dec 12, 2014 at 10:14:21AM -0800, Richard Henderson wrote: > On 12/12/2014 04:06 AM, Dominik Vogt wrote: > > I'm not sure I've posted the missing patch anywhere yet, so it's > > attached to this message. At the moment it enables > > FFI_TYPE_COMPLEX only for s390[x], but eventually this should be > > used unconditionally. > > Thanks for that. I'd been meaning to get around to that. I'll change the > test > to use FFI_TARGET_HAS_COMPLEX_TYPE and apply it to my branch.
Good. I'm not sure whether it's a good idea to expose FFI_TARGET_HAS_COMPLEX_TYPE as part of the libffi interface though. It was meant as a temporary thing to be removed once all platforms supported by libffi have implemented complex support. A while ago I've posted a patch to change the macro's name to begin with an underscore to make that clearer. > > (This still leaves the dynamic linking issue if we do not use > > libffi for reflection calls with x86* and s390[x]. Is the plan to > > remove the platform specific abi code for the few platforms that > > have it? I see no way to make them work with the static chain > > patch anyway.) > > Well, the x86 paths were updated to work with the static chain, but indeed > that > required assembly rather than cheating and using C as you did. > > But removing all of that was always my goal. Indeed, my branch now has a > patch > to remove all of the target-specific code. Fine with that. I wouldn't have written the s390 specific Abi code in Go if libffi had been an option back then. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
