Re: "static_wrapper" imports in the FFI

Hello, On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow wrote:

It seems hard to justify adding this to GHC, since it's really just syntactic convenience for a particular case.  Traditionally syntactic sugar for FFI declarations has been implemented in the preprocessing tools: c2hs and hsc2hs, whereas the FFI extension itself is purposefully minimal.

The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem. For example, SE Linux policies need to be adjusted for all GHC-compiled programs, even if run-time code generation never actually happens. I decided to implement this as a GHC patch because it seems more primitive then the "wrapper" imports: it is a simpler feature which---if it was available---would have been sufficient in all the situations where I have needed to use a "wrapper" import. Furthermore, the code that is called by the adjustor thunks is essentially the function that we are exposing in a "static_wrapper" import, so it seems plausible that "wrapper" imports can be implemented on top of this, although I have not done this. I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell types. Of course, I could have either hacked up a simple parser, or used some kind of a Haskell parsing library but that seemed very heavy-weight. Also, preprocessors tend to complicate the build system, result in confusing error messages, and make it difficult to work with modules in GHCi. As far as I can see, the notation that I used does not conflict with anything, except possibly importing a C function named "static_wrapper" without specifying a header file, which is already a problem with "wrapper" imports. This would not be the case if we used something which is not a valid C identifier (e.g., "static"). This seems like a small enough change to not require a separate flag. If we decided to use Tyson's suggested syntax, then we should probably add a flag. In any case, I think that moving away from executable data is important enough that I'd be happy with an extra flag. Thoughts? -Iavor

So at the moment we're slightly inclined not to put it in - but feel free to make a compelling case.  Note that as an extension in its own right it would need its own flag, documentation etc.

Cheers,        Simon

...

-Iavor

On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead  wrote:

...

On March 15, 2010 12:48:02 Iavor Diatchki wrote:

...

I have implemented a small extension to the FFI which allows for "static_wrapper" imports.  These are a variation on "wrapper" imports that do not use run-time code generation.  This is important in security sensitive contexts because it avoids executable data.  While "static_wrapper" imports are less general then "wrapper" imports, they can be used to install Haskell handlers in many C libraries where callbacks have an extra "user-data" parameter (e.g., GTK signal handlers).

Hi Iavor,

Would not the following also do what you want

 foreign export ccall "haskellCIntCInt" \   cbind :: CInt ->  StablePtr (CInt ->  IO CInt) ->  IO CInt

 cbind :: a ->  StablePtr (a->  IO b) ->  IO b  cbind x f = deRefStablePtr f>>= (\f_ ->  f_ x)

On the C side you would then have something like

 register_callback(haskellCIntInt,<wrapped haskell closure>)

where<wrapped haskell closure>  would be a stable pointer of type StablePtr (CInt ->  IO CInt) generated on the haskell side via

 newStablePtr<haskell closure>

and passed to the C code.

Cheers!  -Tyson

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users