Re: Runtime error using LLVM bitcode execution

3 Mar 2014

      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