Hallo Simon, Oh, I see ... Well, that's unfortunate, as we're working with the .ll files rather than the .s files. I guess I'll try to create my own mangler that will work on the .ll files instead, if that's feasible ... Regards Ralph -----Original Message----- From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: Freitag, 28. Februar 2014 10:43 To: Benzinger, Ralph; ghc-devs@haskell.org Subject: Re: Runtime error using LLVM bitcode execution You need to run it against the assembly file (.s) that LLVM generates, not the .ll file. Cheers, Simon On 28/02/2014 08:48, Benzinger, Ralph wrote:
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@gmail.com] Sent: Mittwoch, 26. Februar 2014 09:11 To: Benzinger, Ralph; ghc-devs@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
#include "hfun_stub.h" extern void __stginit_HFun(void); #include 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