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

GHC cvs-ghc at haskell.org
Mon Apr 8 16:57:57 CEST 2013


#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



More information about the ghc-tickets mailing list