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

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

I believe the problem is that we can't represent the output of the mangler in LLVM's intermediate language as it stands. Although I think it may now be possible to do this with LLVM 3.4: http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html GHC's code generator needs to be updated to take advantage of this. Is anyone interested in looking into it? Cheers, Simon On 03/03/14 07:58, Nathan Howell wrote:

Slightly related... is it possible to implement the evil mangler as an LLVM MC optimization instead of a standalone post-processor? Seems like it could be faster.

On Sun, Mar 2, 2014 at 11:39 PM, Benzinger, Ralph mailto:ralph.benzinger@sap.com> wrote:

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 mailto:marlowsd@gmail.com] Sent: Freitag, 28. Februar 2014 10:43 To: Benzinger, Ralph; ghc-devs@haskell.org mailto: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 mailto:marlowsd@gmail.com] > Sent: Mittwoch, 26. Februar 2014 09:11 > To: Benzinger, Ralph; ghc-devs@haskell.org mailto: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 http://libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177 >> 7 libHSrts-ghc7.6.3.so http://libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145 >> 8 libHSrts-ghc7.6.3.so http://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 >> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs