>> > 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
This is exactly what I would suggest. > 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. True. Perhaps I'll try pushing the regparm3 patch to HEAD. The main issue is flexibility - it would be much better to support some sort of __attribute__() system so we don't have to manually ad regparmX for all reasonable values of X. >> >> 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? Yes > 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. I just made this and gcc accepts it without issue: ---- START enum.h ---- extern enum hello hello_fn(int); ---- END enum.h ---- This can be # included in any .c and gcc will compile it without complaint (even with -Wall). OTOH, c2hs will not parse such a file. Thomas _______________________________________________ C2hs mailing list C2hs@haskell.org http://www.haskell.org/mailman/listinfo/c2hs