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