Runtime error using LLVM bitcode execution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Benzinger, Ralph
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

--
Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Simon Marlow-7
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
>

Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Benzinger, Ralph
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hfun.ll
Type: application/octet-stream
Size: 42784 bytes
Desc: hfun.ll
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140228/42852ab9/attachment-0001.obj>

Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Simon Marlow-7
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
>>

Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Benzinger, Ralph
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
>>

Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Nathan Howell-2
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>

Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Simon Marlow-7
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
> <ralph.benzinger at sap.com <mailto: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
>     <mailto:marlowsd at gmail.com>]
>     Sent: Freitag, 28. Februar 2014 10:43
>     To: Benzinger, Ralph; ghc-devs at haskell.org <mailto: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
>     <mailto:marlowsd at gmail.com>]
>      > Sent: Mittwoch, 26. Februar 2014 09:11
>      > To: Benzinger, Ralph; ghc-devs at haskell.org
>     <mailto: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 <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
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>


Reply | Threaded
Open this post in threaded view
|

Runtime error using LLVM bitcode execution

Mikhail Glushenkov-2
Hello Simon,

On 3 March 2014 09:39, Simon Marlow <marlowsd at gmail.com> wrote:
> 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?

IIUC, GHC can't take advantage of this yet, because global symbol
offsets [1] are not yet implemented. LLVM currently doesn't allow
arbitrary function prefix data, but requires prefix data to "begin
with a sequence of bytes which decode to a sequence of machine
instructions, [...] which transfer control to the point immediately
succeeding the prefix data" [2].

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html
[2] http://llvm.org/docs/LangRef.html#prefix-data