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 <[email protected]>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:[email protected]] > Sent: Freitag, 28. Februar 2014 10:43 > To: Benzinger, Ralph; [email protected] > 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:[email protected]] > > Sent: Mittwoch, 26. Februar 2014 09:11 > > To: Benzinger, Ralph; [email protected] > > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
