From: Hoehle, Joerg-C. <Joe...@t-...> - 2006-04-26 16:44:19
|
Bernard Urban wrote: >The following program works fine on a =20 >Intel Xeon machine (used as a i686 machine),=20 >but fails on a different >machine with the same CPU, but used as a x86_64 machine. >the FFI tests on installation work ok even on x86_64 Did you compile CLISP 2.38 yourself or do you use some distribution? >struct projUV { > double u, v; >}; >struct projUV pj_fwd(struct projUV in, opaque proj) >Output from the i686 machine: >Problem passing argument #S(PROJUV :U 45.0d0 :V 67.0d0) ? >Input proj =3D 0x81ea530 u =3D 45 v =3D 67 >And from the x86_64 machine: >Problem passing argument #S(PROJUV :U 45.0d0 :V 67.0d0) ? >Input proj =3D 0x4046800000000000 u =3D 0 v =3D 0 >So there is something weird happening, related to pointer apparently. This looks like a bug in the ffcall library. It looks like ffcall did = not guess the correct calling convention for passing or returning this = struct. Is it possible for you to work with pointers to structs instead, as a = work-around? Sadly, I have no access to a 64bit machine. Could you add a test to ffcall/avcall/tests.c similar to the existing typedef struct { long l1; long l2; } J; J J_JiJ (J a, int b, J c) and report ffcall test results? That test shows that passing & returning a struct { long ; long } = works. struct { double; double } is untested and could make a difference. Regards, J=F6rg H=F6hle. |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2006-04-26 17:44:12
|
Bruno Haible wrote: >The ffcall library can not portably support passing or=20 >returning structs containing doubles or floats _by_value_. >Suggestions: Either write a wrapper around your function to pass or >return the structs by pointer. Or enhance clisp's foreign.d to=20 >deal with this case automatically. What is possible in CLISP's foreign.d except signaling an error? Regards, J=F6rg H=F6hle. |
From: Bruno H. <br...@cl...> - 2006-04-26 18:25:31
|
Joerg-Cyril Hoehle wrote: > >Suggestions: Either write a wrapper around your function to pass or > >return the structs by pointer. Or enhance clisp's foreign.d to > >deal with this case automatically. > > What is possible in CLISP's foreign.d except signaling an error? foreign.d could signal an error in that case. But foreign1.lisp should emit C code for a wrapper function that passes the struct by pointer. Bruno |
From: Bernard U. <Ber...@me...> - 2006-05-11 14:13:24
|
Bruno Haible <br...@cl...> writes: > Joerg-Cyril Hoehle wrote: >> >Suggestions: Either write a wrapper around your function to pass or >> >return the structs by pointer. Or enhance clisp's foreign.d to >> >deal with this case automatically. >> I recall the problem: on x86_64 (Red Hat) with stock clisp-2.38, in the FFI, passing by value structs (containing doubles) to a C function fails. I finally wrote a wrapper to work with pointer on structs, and it works fine now. Regards. -- Bernard Urban |
From: Sam S. <sd...@po...> - 2006-05-11 14:24:22
|
> * Bernard Urban <Ore...@zr...> [2006-05-11 16:13:18 +0200]: > > Bruno Haible <br...@cl...> writes: > >> Joerg-Cyril Hoehle wrote: >>> >Suggestions: Either write a wrapper around your function to pass or >>> >return the structs by pointer. Or enhance clisp's foreign.d to >>> >deal with this case automatically. >>> > > I recall the problem: on x86_64 (Red Hat) > with stock clisp-2.38, in the FFI, > passing by value structs (containing doubles) to a C function > fails. http://clisp.cons.org/impnotes/dffi.html#ffi-struct-arg do we need an FAQ entry on this too or it will be useless because no one reads FAQ anyway? -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux) http://openvotingconsortium.org http://dhimmi.com http://thereligionofpeace.com http://memri.org http://mideasttruth.com http://camera.org http://pmw.org.il Those who value Life above Freedom are destined to lose both. |
From: Bruno H. <br...@cl...> - 2006-04-26 17:38:10
|
> > struct projUV { > > double u, v; > > }; > > struct projUV pj_fwd(struct projUV in, opaque proj) The ffcall library can not portably support passing or returning structs containing doubles or floats _by_value_. Suggestions: Either write a wrapper around your function to pass or return the structs by pointer. Or enhance clisp's foreign.d to deal with this case automatically. > This looks like a bug in the ffcall library. It looks like ffcall did not > guess the correct calling convention for passing or returning this struct. Yes, but it will not be fixed. Bruno |
From: Bernard U. <Ber...@me...> - 2006-04-27 07:43:38
|
"Hoehle, Joerg-Cyril" <Joe...@t-...> writes: > Bernard Urban wrote: > >>The following program works fine on a=20=20 >>Intel Xeon machine (used as a i686 machine),=20 >>but fails on a different >>machine with the same CPU, but used as a x86_64 machine. >>the FFI tests on installation work ok even on x86_64 > > Did you compile CLISP 2.38 yourself or do you use some distribution? > I compiled myself (they are Red Hat machines); no special configure or gcc options used. >>struct projUV { >> double u, v; >>}; >>struct projUV pj_fwd(struct projUV in, opaque proj) > >>Output from the i686 machine: >>Problem passing argument #S(PROJUV :U 45.0d0 :V 67.0d0) ? >>Input proj =3D 0x81ea530 u =3D 45 v =3D 67 > >>And from the x86_64 machine: >>Problem passing argument #S(PROJUV :U 45.0d0 :V 67.0d0) ? >>Input proj =3D 0x4046800000000000 u =3D 0 v =3D 0 >>So there is something weird happening, related to pointer apparently. > > This looks like a bug in the ffcall library. It looks like ffcall did no= t guess the correct calling convention for passing or returning this struct. > Is it possible for you to work with pointers to structs instead, as a wor= k-around? I will try this (already required by cmucl anyway in 32 bits) and mail you the results. > > Sadly, I have no access to a 64bit machine. > Could you add a test to ffcall/avcall/tests.c similar to the existing > typedef struct { long l1; long l2; } J; > J J_JiJ (J a, int b, J c) > and report ffcall test results? =20 Ditto. > That test shows that passing & returning a struct { long ; long } works. > struct { double; double } is untested and could make a difference. > > Regards, > J=F6rg H=F6hle. > Sincerely. --=20 Bernard Urban |