On Tue, 2009-09-22 at 10:17 -0700, Thomas DuBuisson wrote: > > Though actually that might not help for the kernel headers because I > > think they do not declare the regparam calling convention and just rely > > on gcc flags when compiling. > > You are correct - the call convention has to be declared manually. > There is no reasonable way for c2hs to learn it.
Do you have any suggestion for that? The information would have to be supplied somehow. I guess as command line parameters to c2hs. I guess we just need to mirror gcc in that respect, to accept some of the gcc flags that globally modify the ABI. c2hs --gcc-abi-mode=-fregparam=3 or whatever. Of course it also needs ghc to support that FFI calling convention, which I understand you've made as a local ghc modification. The same applies to stdcall vs ccall however, so it's generally useful even if you never contribute the regparam calling convention. > >> In the end the solution I have is to manually write the above C > >> section and the foreign import call using a regparm3 calling > >> convention. This isn't to say c2hs isn't used - its still hugely > >> helpful (so long as the headers remain easy to convert to ANSI C), but > >> just my quick experience. > > > > BTW, what do you mean about ANSI C? > > I meant there exists at least one aspect (perhaps a bug) to the kernel > headers that cause an error when c2hs tries to parse the headers. In > the FC11 2.6.30 headers they use an enum when declaring an extern > function prototype - without declaring the enum (timers.h). The > solution is to #include <linux/hrtimers.h>, which contains the enum > declaration. Ah, and gcc accepts this without warning? Perhaps you can boil down a test case and submit it. I tried hard when making the C parser to cover all the GNU extensions and I ran it over all the kernel sources for some older kernel release. So it's worth fixing these things to maintain its usability. > > So yes, I think all these issues are solvable. As usual the difficulty > > is finding enough people with enough time to actually do the work. I > > think c2hs could become the standard Haskell ffi binding tool, taking > > over from hsc2hs, but it needs a bit of love. > > FWIW, hsc2hs is entirely unusable for this work as it builds a .c file > that will generate the .hs file. I couldn't get this to work for > kernel bindings as one build (the generating .c file) needs things > like stdlibs while the other (the kernel) absolutely can not have such > things. All sorts of conflicts occur, such as redefinition of basic > type by the kernel headers. That's an interesting point I had not though of before. It's a bit like cross-compilation really, which is another case where in principle c2hs should do fine but where hsc2hs cannot help. Duncan _______________________________________________ C2hs mailing list C2hs@haskell.org http://www.haskell.org/mailman/listinfo/c2hs
