Runtime error using LLVM bitcode execution

[Benzinger, Ralph]

Hello Simon,

Thanks for your suggestion!  I ran the LLVM mangler against the hfun.ll file, but it didn't make any changes to the code at all.  (My understanding is that I can leave the hfun_stub alone.)

Am I missing something?

Regards
Ralph


-----Original Message-----
From: Simon Marlow [mailto:marlowsd at gmail.com] 
Sent: Mittwoch, 26. Februar 2014 09:11
To: Benzinger, Ralph; ghc-devs at haskell.org
Subject: Re: Runtime error using LLVM bitcode execution

My guess is that this isn't working because GHC needs to post-process 
the assembly generated by LLVM to support tables-next-to-code.  You 
could extract this phase from GHC (it's just one module, in 
compiler/llvmGen/LlvmMangler.hs) and run it as a standalone program.

Cheers,
Simon

On 21/02/2014 16:02, Benzinger, Ralph wrote:
> Hello,
>
> My apologies in advance if this mailing list is not the appropriate
> address for posting my problem with the GHC runtime, but it seemed
> like the best option on the GHC home page.
>
> I'm trying to execute standalone Haskell functions exported via FFI
> and compiled as LLVM bitcode.  Unfortunately, all my efforts yield the
> following runtime error:
>
> lu003107:~/hs-bitcode> ./bce_so hsallinone.bc
> hs_init complete
> hs_add_root complete
> hsallinone: internal error: stg_ap_p_ret
>      (GHC version 7.6.3 for x86_64_unknown_linux)
>      Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> 0  bce_so               0x0000000000d6b310
> 1  bce_so               0x0000000000d6b53b
> 2  bce_so               0x0000000000d6ba1c
> 3  libpthread.so.0      0x00007f7683298800
> 4  libc.so.6            0x00007f7682592b35 gsignal + 53
> 5  libc.so.6            0x00007f7682594111 abort + 385
> 6  libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177
> 7  libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145
> 8  libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130
> Stack dump:
> 0.      Program arguments: ./bce_so hsallinone.bc
> Aborted
>
> This is what I do:
>
> I have a function hfun.hs that exports a function
>
>      foreign export ccall hfun :: CInt -> CInt
>
> and a wrapper cmain.c that calls this function:
>
>      #include <HsFFI.h>
>      #include "hfun_stub.h"
>      extern void __stginit_HFun(void);
>      #include <stdio.h>
>
>      int main(int argc, char *argv[])
>      {
> 	hs_init(&argc, &argv);
> 	printf("hs_init complete\n");
>
> 	hs_add_root(__stginit_HFun);
>      	printf("hs_add_root complete\n");
>
>      	int i = hfun(42);
>      	printf("hfun(42) = %d\n", i);
>
>      	hs_exit();
>      	return 0;
>      }
>
> To generate a callable bitcode file I use these commands:
>
>      $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs
>      $ llvm-as hfun.ll
>      $ cp /tmp/... hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c
>      $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c
>      $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc
>
> My main program "bce_so" loads the linked bitcode and feeds it to the
> LLVM execution engine.  All required Haskell runtime libraries are
> linked dynamically against bce_so.
>
> Could you kindly provide some insight on whether this runtime error is
> due to a bug with GHC (unlikely) or rather some negligence in my
> setup?  Or does the issue highlight some principal limitation in my
> (admittedly somewhat naive) approach of using LLVM -- threading
> support, maybe?
>
> Note that compiling hfun.hs/cmain.c into a .so and executing
> everything natively using ldload() works flawlessly.
>
> Regards
> Ralph
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hfun.ll
Type: application/octet-stream
Size: 42784 bytes
Desc: hfun.ll
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/42852ab9/attachment-0001.obj>