- FFI - Haskell.org

Re: Generating Function Prototypes
by Ashley Yakeley 08 Jul '02

08 Jul '02

At 2002-07-08 03:33, Alastair Reid wrote: >Instead of writing your own definition, you can #include HsFFI.h Yes of course, and I expect GHC does. I just put that in for an easy compile in lieu of the #include. -- Ashley Yakeley, Seattle WA

1 0

RE: Generating Function Prototypes
by Ashley Yakeley 08 Jul '02

08 Jul '02

At 2002-07-08 02:14, Simon Marlow wrote: >Sure, it's a problem, a bug in GHC, whatever. But I don't see a way >around it! We can't just generate prototypes because they might >conflict with prototypes already in scope. I see the problem now. This seems to compile (with a warning): typedef long long HsInt64; int foo (int); // annoying decl we want to ignore // foo :: Int64 -> IO Int64 inline HsInt64 call_foo (HsInt64 x) { static HsInt64 foo(HsInt64); return foo(x); }; I haven't actually tested it, but it may be a solution. -- Ashley Yakeley, Seattle WA

2 1

Re: Generating Function Prototypes
by Sven Panne 08 Jul '02

08 Jul '02

Simon Marlow wrote: > [...] But I don't see a way around it! [...] What's wrong with Alastair's suggestion to post-process the generated assembler code? We mangle it anyway with -f-via-C, and the additional mangling required looks quite stable and easy to implement. Cheers, S.

1 0

RE: Generating Function Prototypes
by Simon Marlow 08 Jul '02

08 Jul '02

> At 2002-07-05 01:17, Simon Marlow wrote: > > >> If specifying a header file with a function prototype is allowed to > >> affect the generated code (i.e., the calling convention), > then it is > >> clear that the Haskell type does not completely determine > the calling > >> convention. > > > >I claim that it is not. > > Well it does anyway, as my IO Int64 example shows. No it doesn't ;-) Your example works fine when compiled with the native code generator. I explained (in my previous message) that GHC needs header files and prototypes in order to generate correct foreign calls when compiling via C. This is, IMO, a GHC-specific issue and doesn't have anything to do with the FFI specification - although confusion could be avoided if the spec pointed out that some implementations might need access to header files/prototypes in order to compile the code. Cheers, Simon

2 1

RE: Generating Function Prototypes
by Ashley Yakeley 08 Jul '02

08 Jul '02

At 2002-07-07 09:28, Simon Marlow wrote: >Your example works fine when compiled with the native code generator. I >explained (in my previous message) that GHC needs header files and >prototypes in order to generate correct foreign calls when compiling via >C. OK >This is, IMO, a GHC-specific issue and doesn't have anything to do >with the FFI specification - although confusion could be avoided if the >spec pointed out that some implementations might need access to header >files/prototypes in order to compile the code. Wouldn't it be better if this were simply considered a bug in GHC? Doing -fvia-c really shouldn't affect program behaviour IMO, I don't see why the compiler can't create its own private prototype when compiling to its own private C, that guaranteed to behave the same way compiling directly to object code would. -- Ashley Yakeley, Seattle WA

1 0

RE: Generating Function Prototypes
by Ashley Yakeley 05 Jul '02

05 Jul '02

At 2002-07-05 01:17, Simon Marlow wrote: >> If specifying a header file with a function prototype is allowed to >> affect the generated code (i.e., the calling convention), then it is >> clear that the Haskell type does not completely determine the calling >> convention. > >I claim that it is not. Well it does anyway, as my IO Int64 example shows. -- Ashley Yakeley, Seattle WA

1 0

RE: Generating Function Prototypes
by Simon Marlow 05 Jul '02

05 Jul '02

> > Similarly, whether there is a prototype in scope or not > > should not affect the semantics of the call. The FFI spec doesn't > > say this explicitly, but I don't think it needs to. > > Yes If that is the intention, then it should say so explicitly. > And if that is not the intention then it should say that. > > What I believe I'm hearing from Manuel is that the presence of > function prototypes is allowed to affect code generation. This is > what ghc -fvia-C does but (by implication) not what GHC's native code > generator does. Even within a single compiler we find both > interpretations of the ffi spec... It can't be the case that prototypes affect the semantics, because it would be impossible to implement in a compiler that doesn't compile via C and doesn't understand C header files. Well, I suppose the compiler could compile wrappers with calls to the external functions using a separate C compiler... but I think the intention is that the calls should be compilable by a standalone Haskell compiler regardless of the compilation route. The fact that the existence of prototypes might affect the code generated under GHC with -fvia-C could be considered a bug, which is why we turn on the appropriate warnings from the C compiler and strongly recommend that people use prototypes and header files when compiling via C. There is still the possibility that the prototype can affect the calling convention when the prototype doesn't match the Haskell type, but I *think* you'll always get a warning in that case. Anyway, I still consider this an implementation issue. I guess the spec should clarify this point. > As someone who wants to be able to write portable ffi code (actually, > I want to be able to steal ffi code originally written for GHC :-), I > need to know what ffi code is portable and what is not. I have > attempted to describe what is currently portable between the different > implementations. I believe it is the job of the ffi to be clear about > what it can guarantee and what it cannot. To write portable code, personally I wouldn't ever use header file annotations in FFI declarations. Some implementations might require you to specify appropriate header files using a compiler-specific mechanism in order to generate correct code, but that's no worse than having to specify the right libraries from a portability point of view. > > I must have lost track of the discussion because I can't remember at > > which point someone said that the Haskell type does not completely > > specify the calling convention. > > If specifying a header file with a function prototype is allowed to > affect the generated code (i.e., the calling convention), then it is > clear that the Haskell type does not completely determine the calling > convention. I claim that it is not. The FFI spec might need to clarify this issue though. > And if it does not, let's remove header files from the spec. I won't comment on that one... Cheers, Simon

1 0

RE: Generating Function Prototypes
by Simon Marlow 05 Jul '02

05 Jul '02

> I just reread that section and can't see anything that contradicts the > idea that the FFI implementation ignores any header files provided. > For example, the phrase: > > "implements calls to C functions ... as if a function prototype for > the called functions is in scope" > > can be interpreted as meaning: > > 1) Will generate code (by generating machine code directly, by > generating C code which is then compiled, or by some other means) > which assumes the existence of a prototype _even if the user does > not supply one_. > > [I see this as the most obvious interpretation of the phrase.] > > 2) Will generate C code which #includes any header files the user has > provided. > > [I see this as a less likely interpretation but it seems to be the > one you intend?] Neither, I think. You're taking an operational interpretation of that phrase, when it is really just talking about the semantics of the call. For example: a C function which takes a float as an argument has two possible calling conventions: the argument may be promoted to double (used by the C compiler when no prototype is in scope), or it may be passed as a float (used by the C compiler when there is a prototype). The FFI spec simply says that it is the latter calling convention that is used. Whether a header file is supplied or not should not affect the semantics of the call (I'm pretty sure you agree with this, but we seem to have lost track of this central concept somewhere along the way...). Similarly, whether there is a prototype in scope or not should not affect the semantics of the call. The FFI spec doesn't say this explicitly, but I don't think it needs to. > My reading of the whole section is that every mention of users > providing header files and function prototypes refers to compiling the > C code being called not the Haskell code doing the calling. The > examples of using foreign import don't show the use of header files > though the second example needs a header file to compile correctly > with GHC. Only when -fvia-C is on. This is a compiler-specific issue, the FFI doesn't need to say anything about it. > If the intent is that any user-provided header files must be > obeyed, then > I think the spec should explicitly say: > > When a header file containing a function prototype is not provided, > the function calling convention employed is undefined. It may vary > between different operating systems, between different > Haskell compilers, > and between different functions. This is exactly what we *don't* want - the semantics should be specified by the FFI declaration alone, independent of any header files. Again, I'm sure you agree with this - but why do you think that supplying a header file should make a difference to the semantics? > I attach my rewording of the section. Note that I am trying to make > it quite clear that an ffi declaration is not portable unless you > provide function prototypes except in the special case that your C > compiler generates the same code with or without a prototype. I really don't think the FFI spec needs to say anything about this at all. If a particular compiler requires prototypes in order to generate correct code (such as GHC when going via C) then this is a matter for that compiler's documentation. Indeed, the GHC User's Guide does mention this. [ Heh. Now I remember why I didn't like being able to specify header files in the FFI declaration :-) ] > ps I still think we're better off removing header files completely and > having the Haskell type completely determine the calling convention > employed. But since I'm not getting any takers on that, I'll > settle for > pinning down the spec as tightly as possible. Aha! I must have lost track of the discussion because I can't remember at which point someone said that the Haskell type does not completely specify the calling convention. Cheers, Simon

2 1

Re: Generating Function Prototypes
by George Russell 05 Jul '02

05 Jul '02

Alistair wrote [snip] > ps I still think we're better off removing header files completely and > having the Haskell type completely determine the calling convention > employed. But since I'm not getting any takers on that, I'll settle for > pinning down the spec as tightly as possible. [snip] Perhaps I'm missing something here, but in that case how on earth is the poor user to find out if the Haskell type really corresponds to the C type, before the program coredumps? I see there is a problem here in that no such check can be carried out when the compilation is not done via C. Would it be possible for the compiler in such a case to spit out a C file which typechecks if and only if the Haskell and C prototypes match, and ask gcc to typecheck it? You could even use this approach in all cases, then C code compiled from Haskell would never need to include user-supplied header files.

2 1

RE: Generating Function Prototypes
by Simon Marlow 04 Jul '02

04 Jul '02

> >> Of course, this ignores the detail that while the C compilers are > >> generating correct code, they may also be generating warnings about > >> alleged type errors - which can be a bit disconcerting. > > > It is an error, not just a warning, if the prototypes don't match. > > GCC will complain loudly if there's a missing 'const' - it won't > > generate any code at all. > > Well, if you disable the warning by giving gcc a consistent story, > then the code is correct. (To give gcc a consistent story, don't > #include any user or system-supplied headers and make sure gcc doesn't > silently #include any of its own (as it likes to do).) I don't think it's possible to completely eliminate system headers from the transitive closure of stuff we include when compiling a .hc file. I've just taken a look at this, and it seems that while we can eliminate a lot of the stuff we include, there are some awkward ones: we need gmp.h for Integer operations, and that includes <stddef.h>, and HsFFI.h needs <stdint.h> to get the int-type limits (perhaps these could be autoconf'd). Cheers, Simon

3 3