Re: Runtime error using LLVM bitcode execution
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
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: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
> >> #include "hfun_stub.h"
> >> extern void __stginit_HFun(void);
> >> #include
> >>
> >> 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
RE: Runtime error using LLVM bitcode execution
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
>> #include "hfun_stub.h"
>> extern void __stginit_HFun(void);
>> #include
>>
>> 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
Re: What does the DWARF information generated by your GHC branch look like?
I did get a language ID assigned a couple years ago, it should be in DWARF 5. Accepted: DW_LANG_Haskell assigned value 0x18. -- April 18.2012 http://dwarfstd.org/ShowIssue.php?issue=120218.1 On Fri, Feb 28, 2014 at 7:34 AM, Johan Tibell wrote: > On Fri, Feb 28, 2014 at 3:15 PM, Peter Wortmann wrote: > >> Johan Tibell wrote:> Lets try to get our name standardized and pushed >> into GDB. It's >> > hopefully as simple as sending an email to the GDB devs. >> >> Strictly speaking standardization is the job of the DWARF format >> committee, which seem to currently be in the process of specifying >> DWARF5[1]. Not quite sure we have a strong enough case, but if we wanted >> our own language ID these would probably be the right people to ask. >> > > I just emailed the DWARF discussion mailing list to sort this out. > > -- Johan > > > ___ > 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
Re: RC2 release imminent
> > New source distributions are available here: > http://www.haskell.org/ghc/dist/7.8.1-rc2/ Thanks! (I would have just called it RC3:) I have done a couple of testbuilds: http://koji.fedoraproject.org/koji/taskinfo?taskID=6586630 (built against ghc-7.6.3) and a build in my Fedora Copr ghc-7.8 repo for Fedora 20 http://copr.fedoraproject.org/coprs/petersen/ghc-7.8/ (against the original RC2) which gave the following testsuite results: * x86_64 Linux 0:17:38 spent to go through 3898 total tests, which gave rise to 12789 test cases, of which 9232 were skipped 48 had missing libraries 3448 expected passes 58 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: codeGen/should_run T8256 [exit code non-0] (normal) perf/compiler T4801 [stat not good enough] (normal) rts T8124 [exit code non-0] (normal) * i686 Linux 0:17:03 spent to go through 3898 total tests, which gave rise to 12789 test cases, of which 9236 were skipped 48 had missing libraries 3439 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 9 unexpected failures Unexpected failures: ../../libraries/base/tests T8766 [stat too good] (normal) codeGen/should_run T8256 [exit code non-0] (normal) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddockhaddock.Cabal [stat not good enough] (normal) perf/haddockhaddock.base [stat not good enough] (normal) perf/haddockhaddock.compiler [stat not good enough] (normal) rts T8124 [exit code non-0] (normal) Since there were some "unexpected failures" I thought I would post then here. I started a full production build on there now too, which might finish in 45min. Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
