Runtime error using LLVM bitcode execution

Nathan Howell nathan.d.howell at gmail.com
Mon Mar 3 07:58:24 UTC 2014


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
<ralph.benzinger at 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 at gmail.com]
> Sent: Freitag, 28. Februar 2014 10:43
> To: Benzinger, Ralph; ghc-devs at 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 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
> >>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140302/6df45231/attachment-0001.html>


More information about the ghc-devs mailing list