Thanks for the report & suggested fix. Your fix is
not right tho, since storing the return address in
the adjustor thunk is not a safe thing to do.
(i.e., what happens when a 'foreign export dynamic'
function end up invoking itself?)

I've committed a more general fix which should hopefully
fix your Haskell callback troubles.

--Sigbjorn

Sven Panne writes: 
> 
> Using the highly recommendable debugging tools ddd and 
> Knockando (13yrs %-}, I was finally able to track down
> the problems with the 'foreign export ccall dynamic'
> construct for constructing Haskell callbacks. The 
> dynamically built adjustor thunks for the ccall calling
> convention contained two bugs (see fptools/ghc/rts/Adjustor.c):
> 
>    * When calling the stub code, there were *two* return 
>      addresses on top of the stack: one for returning to
>      the adjustor thunk and one for returning to C-land.
>      Instead of modifying DsForeign.lhs to take this into
>      account, it's easier to temporarily remove the latter
>      address from the stack before calling the stub.
> 
>    * Register eax maybe contains a (part of) the return value 
>      of the stub, but the adjustor thunk destroyed it.
> 
> The stdcall section contains two (harmless) typos, too.
> Patch appended.
> 
> Hmmm, the standard GHC includes should contain prototypes for 
> createAdjustor and freeHaskellFunctionPtr somewhere, but I've
> got no clue about a nice place for them.
> 
> Cheers,
>    Sven
> 
> P.S. to Sigbjorn: Getting the stable pointer by peeking into 
> the machine
> code of the adjustor thunk is a quite cunning trick...   :-)
> 

Reply via email to