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
