[GHC] #7820: Installing profiling library BREAKS non-profiling executable

[Ryan Newton]

By the way, does anyone have a positive example of a package on hackage
that (1) uses foreign primops and (2) is robust across a wide variety of
platforms and build methods?  It would be great to work from such an
example.

Thanks,
  -Ryan



On Mon, Apr 8, 2013 at 10:57 AM, GHC <cvs-ghc at haskell.org> wrote:

> #7820: Installing profiling library BREAKS non-profiling executable
>
> --------------------------+-------------------------------------------------
> Reporter:  rrnewton       |          Owner:
>     Type:  bug            |         Status:  new
> Priority:  normal         |      Component:  Compiler
>  Version:  7.6.2          |       Keywords:  profiling
>       Os:  Linux          |   Architecture:  x86_64 (amd64)
>  Failure:  Runtime crash  |      Blockedby:
> Blocking:                 |        Related:
>
> --------------------------+-------------------------------------------------
>  I am trying to work through problems with different GHC "ways" so that I
>  can broadly deploy a library of foreign primops for lockfree data
>  structures.  Here's the package I am testing at the moment:
>
>  https://github.com/rrnewton/haskell-lockfree-
>  queue/tree/5d990fe43a983fc5ed32c3f58cb2e59df71b00b6/AtomicPrimops
>
>  Here is a recipe for reproducing the bug from within that directory.  Both
>  of these build modes work FINE:
>
>      (cabal install --enable-library-profiling; cd testing; make prof;
>  ./Test_prof.exe)
>      (cabal install --disable-library-profiling; cd testing; make;
>  ./Test_threaded.exe)
>
>  That is, building both library and executable with profiling, or without
>  profiling, works fine.  But then this creates an executable that
>  segfaults:
>
>      (cabal install --enable-library-profiling; cd testing; make;
>  ./Test_threaded.exe)
>
>  At runtime the call to the .cmm-defined foreign primop just returns zero,
>  and then the process segfaults when it tries to use that as a Haskell
>  value.
>
>  But my understanding is that --enable-library-profiling should just add
>  extra binaries to .cabal and NOT change the behavior of the non-profiling
>  binaries.
>
>  Yet I can confirm that I see slightly different binary sizes with the non-
>  profiling .o and .a files installed in ~/.cabal/lib depending on whether
>  --enable-library-profiling is activated.  Perhaps this in itself is a
>  cabal bug, but I haven't tracked down exactly what the difference is yet.
>
>  I have confirmed the above behavior under:
>    * Mac OS (ghc 7.4.2 and 7.6.2)
>    * Linux, RHEL 6 (ghc 7.4.2 and 7.6.2)
>
> --
> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7820>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130408/cea49798/attachment.htm>