[C2hs] Function Hooks and Calling Convention
duncan.coutts at worc.ox.ac.uk
Tue Sep 22 14:00:49 EDT 2009
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.
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
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.
More information about the C2hs