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.benzin...@sap.comwrote:
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:marlo...@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:marlo...@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 0x00d6b310
1 bce_so 0x00d6b53b
2 bce_so 0x00d6ba1c
3 libpthread.so.0 0x7f7683298800
4 libc.so.60x7f7682592b35 gsignal + 53
5 libc.so.60x7f7682594111 abort + 385
6 libHSrts-ghc7.6.3.so 0x7f7683f6ca21 rtsFatalInternalErrorFn +
177
7 libHSrts-ghc7.6.3.so 0x7f7683f6cce1 barf + 145
8 libHSrts-ghc7.6.3.so 0x7f7683f8a24a 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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs