haskell - Haskell FFI 中 "wrapper"包装器的实现

Question

根据Haskell Wiki ，在 Haskell FFI 中，我们可以使用“wrapper”包装器从 Haskell 函数中创建一个 C 函数:

foreign import ccall "wrapper" createFunPtr :: (Int -> Int) -> IO (FunPtr (Int -> Int))

如果我理解正确，这意味着 f <- createFunPtr (+ 42)在 do -block 给出函数指针 f类型 int (*)(int)在 C.

在 Haskell 中， Int -> Int 类型的函数内部可能有一些本地绑定(bind)(例如，lambda 表达式可能引用外部范围内的变量)，而在 C 中，函数指针仅仅是函数的内存地址，调用这些函数指针只是类似于原始跳转的东西。所以Haskell函数的附加数据没有别的地方住 FunPtr .

C++ 中的 Lambda 表达式是对象，并调用 operator()传递一个隐式 this指针。但是 FunPtr s 就像 C 中的普通函数指针一样被处理，因此不可能传递一些额外的参数。

那么 GHC 是如何实现这个“包装器”的包装器的呢？ (我猜想它可以通过直接向内存中的代码段写入指令来传递额外的参数来实现，但我记得，代码段通常是只读的。)

Answer 1

快速的 Google 搜索显示 the GHC commentary :

Occasionally, it is convenient to treat Haskell closures as C function pointers. This is useful, for example, if we want to install Haskell callbacks in an existing C library. This functionality is implemented with the aid of adjustor thunks.

An adjustor thunk is a dynamically allocated code snippet that allows Haskell closures to be viewed as C function pointers.

Stable pointers provide a way for the outside world to get access to, and evaluate, Haskell heap objects, with the RTS providing a small range of ops for doing so. So, assuming we've got a stable pointer in our hand in C, we can jump into the Haskell world and evaluate a callback procedure, say. This works OK in some cases where callbacks are used, but does require the external code to know about stable pointers and how to deal with them. We'd like to hide the Haskell-nature of a callback and have it be invoked just like any other C function pointer.

Enter adjustor thunks. An adjustor thunk is a little piece of code that's generated on-the-fly (one per Haskell closure being exported) that, when entered using some 'universal' calling convention (e.g., the C calling convention on platform X), pushes an implicit stable pointer (to the Haskell callback) before calling another (static) C function stub which takes care of entering the Haskell code via its stable pointer.

An adjustor thunk is allocated on the C heap, and is called from within Haskell just before handing out the function pointer to the Haskell (IO) action. User code should never have to invoke it explicitly.

An adjustor thunk differs from a C function pointer in one respect: when the code is through with it, it has to be freed in order to release Haskell and C resources. Failure to do so will result in memory leaks on both the C and Haskell side.

我记得在某处读过，包装器 FFI 导入实际上是 GHC 执行运行时代码生成的唯一地方。

我相信评论所说的是您的 createFunPtr在编译时被定义为类似这样(我设置 -ddump-simpl 以获取 createFunPtr 的核心，以下是我尝试将其反编译回 Haskell)

createFunPtr fun = do stable <- newStablePtr fun
                      pkg_ccall stable :: IO (FunPtr (Int -> Int))

newStablePtr 是 StablePtr 的一部分API，它允许 Haskell 将对 Haskell 对象的引用导出到外部代码。允许 GC 移动传递给 createFunPtr 的函数在创建了调整器 thunk 之后。因此，所述调整器需要对在 GC 之后仍然保持的函数的引用，并且该功能由稳定指针提供。
pkg_ccall (这实际上相当神奇)为 C 堆上的调整器 thunk 分配空间。稍后必须使用 freeHaskellFunPtr 释放此空间, 否则 C 堆(保存调整器)和 Haskell 堆(保存函数闭包，在释放稳定指针之前不能被 GC)上的内存泄漏。调整器的内容取决于平台以及 GHC 是否配置(在构建时)以使用 libffi 作为调整器。实际的汇编代码可以在 the comments in the relevant RTS file 中找到，但要点通常是:

int adjustor(int arg) {
  return zdmainzdTzdTzucreateAddPtr($stable, arg);
  // with stable "baked" into each adjustor, as a "push <constant>" instruction
}

zdmainzdTzdTzucreateAddPtr是取消引用给定稳定指针并调用那里产生的 Haskell 函数的 stub 。它是静态的，烘焙到二进制文件中，大致相当于:(如果你通过 GHC -v 和 -keep-tmp-files ，你应该能够找到包含真实定义的 ghc_<some_num>.c 文件，这需要做一些簿记。)

HsInt zdmainzdTzdTzucreateAddPtr(StgStablePtr ptr, HsInt a) {
  HaskellObj fun, arg, app, ret;
  fun = deRefStablePtr(ptr);
  arg = rts_mkInt(a);
  app = rts_apply(fun, arg);
  eval(app, &ret);
  return rts_getInt(ret);
}