在Linux / ARM上使用带有C函数回调的pinvoke进行F＃委托

Question

Can you help me use a C function, from F#, that expects a callback? I am using F#, mono and Arch Linux, on the ARM processor based Raspberry Pi 2.

My original problem, understanding the signature to use for the callback, was answered which you can read for more context.

I have reached an impasse. When using the library, the program crashes with a segmentation fault.

I believe that this is because of a marshalling mismatch. The "the clr supports only the std calling convention for marshalling function pointers" according to the book Expert F# 3.0 . The CLR assumes that the callee will clean the stack (StdCall) and the C library expects that the caller will clean the stack (Cdecl) according to the definition on MSDN . Hence the memory leak.

Sadly, I can find no way to make the CLR use Cdecl for this delegate nor for C to use StdCall on an ARM processor. I haven't written the C library but I do have access to the source code.

Here is the function signature in C

int wiringPiISR (int pin, int edgeType,  void (*function)(void)) ;

and part of my F# code:

type ISRCallback = delegate of unit -> unit

[<DllImport(wiringPiLib, EntryPoint = "wiringPiISR", CallingConvention = CallingConvention.Cdecl, SetLastError=true)>]
    extern int wiringPiISR(int pin, int mode, [<MarshalAs(UnmanagedType.FunctionPtr)>]ISRCallback callBack);

Decorating the delegate with [<UnmanagedFunctionPointer(CallingConvention.Cdecl)>] doesn't help. The compiler silently ignores it, which I think is how these attributes are designed to work.

Is there another way to do this - perhaps editing the C code, or wrapping it in another way? (C++ perhaps?)

Note: there is an interesting article on the mono-project website titled Interop with Native Libraries

In the meantime, I have written a little loop to poll the GPIO pins. Not ideal but it works.

EDIT: I was wrong in my memory leak assumption but, thanks to the comments and the research it prompted, I learnt a lot and found answers.

Answer 1

The segmentation fault, as noted in the comments and as suggested in the answer to my original question, is caused by the garbage collection of the callback function.

Adding GC.StayAlive (MyFunctionDoingCallBack) at the right place in my code makes it clear to anyone reviewing the code - me - when it is safe for the callback garbage collected. This solution was easier than working out why the callback was going out of scope and thus how to keep it in scope. I realise this reflects badly on me as a programmer ;-(.

This answer explains why SetLastError=false is correct. The native code definitely does not return a Win32 Error, it's running on Linux anyway, so I'd only be getting garbage from the error code.

Setting CallingConvention.Cdecl on the DLLImport attribute works. Perhaps the quote " The clr supports only the std calling convention for marshalling function pointers " is wrong for my system (mono on Linux) or I misunderstood the quote.

Setting [<UnmanagedFunctionPointer(CallingConvention.Cdecl)>] on the delegate appears to be redundant as is EntryPoint = "wiringPiISR" part of the DLLImport attribute. For clarity I removed both.

There is a series of articles about DDLImport and DLLExport on the OldNewThing blog at MSDN

Thanks @FyodorSoikin, @ildjarn, @BentTranberg, @CurtNichols and @vcsjones