GHC: Ticket Queryhttp://ghc.haskell.org/trac/ghc/query?status=closed&component=Compiler+(FFI)&milestone=7.2.1&group=resolution&order=id
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.pnghttp://ghc.haskell.org/trac/ghc/query?status=closed&component=Compiler+(FFI)&milestone=7.2.1&group=resolution&order=id
Trac 1.0.1http://ghc.haskell.org/trac/ghc/ticket/3252
http://ghc.haskell.org/trac/ghc/ticket/3252#3252: having to call hs_add_root(__stginit_Foo) is a bit of a painThu, 21 May 2009 14:02:35 GMTduncan<p>
For C code calling C functions exported from Haskell code, it has to jump through a couple hoops first. The call to <tt>hs_init()</tt> is fair enough and is specified by the FFI, however GHC also makes us call:
</p>
<pre class="wiki">hs_add_root(__stginit_Foo);
</pre><p>
for the top level Haskell module that exports the function we're interested in. If there are multiple such modules and they don't depend on each other then presumably we have to call them all.
</p>
<p>
Doing this is a bit annoying. It's not just that we have to call it, but we have to work out which symbols we need exactly. Are there any ways we could automate it? If the <tt>__stginit_*</tt> functions are really cheap then can we just have them called as constructor functions using gcc's <tt>__attribute__ ((constructor))</tt> system. If they're slightly more expensive then perhaps they could be registered in a constructor and called by <tt>hs_init()</tt>. Or can we have them run lazily, eg have the exported C functions check that the module they're in has been initialised.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3252#changeloghttp://ghc.haskell.org/trac/ghc/ticket/5050
http://ghc.haskell.org/trac/ghc/ticket/5050#5050: Produces invalid assembly when using `peek' and -fvia-c with new binutils on amd64Sat, 26 Mar 2011 10:54:22 GMTlaney<p>
I noticed this when rebuilding happstack-util on Ubuntu. A mail sent to debian-haskell can be found at <a class="missing changeset" title="No changeset 0 in the repository">[0]</a>, but I've since produced a minimal test case, attached. To reproduce this you need a new binutils (the ones in Debian unstable and Ubuntu Natty are sufficient to trigger the bug).
</p>
<p>
When using peek from Foreign.Storable and compiling via C, GHC produces code which generates invalid assembly:
</p>
<pre class="wiki"> [1 of 1] Compiling Break ( break.hs, break.o )
/tmp/ghc4532_0/ghc4532_0.s: Assembler messages:
/tmp/ghc4532_0/ghc4532_0.s:73:0:
Error: .size expression does not evaluate to a constant
</pre><p>
<a class="missing changeset" title="No changeset 0 in the repository">[0]</a> <a class="ext-link" href="http://lists.debian.org/debian-haskell/2011/03/msg00088.html"><span class="icon">​</span>http://lists.debian.org/debian-haskell/2011/03/msg00088.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5050#changeloghttp://ghc.haskell.org/trac/ghc/ticket/5250
http://ghc.haskell.org/trac/ghc/ticket/5250#5250: SEGFAULT in FFI to C++ libraryFri, 10 Jun 2011 07:46:43 GMTacowley<p>
A binding to <a class="ext-link" href="http://opencv.willowgarage.com/wiki/"><span class="icon">​</span>OpenCV</a> 2.2 I've been developing works fine on Mac OS X 10.5 and 10.6, but segfaults in Ubuntu 11.04 (32-bit) and Windows 7. On both Ubuntu and Windows, building a Debug or RelWithDebInfo build of OpenCV 2.2 seems to fix the problem. On Ubuntu, OpenCV 2.1 does not have this issue; I have not tried 2.1 on Windows.
</p>
<p>
To separate the bindings as a source of trouble, I boiled a test case down to a C function <tt>void myDilate(void)</tt> that allocates two images which are then passed to an OpenCV image processing routine, <tt>cvDilate</tt>. The <tt>myDilate</tt> function is defined in <tt>MyWrap.c</tt>. A shell C program, <tt>CTest2.c</tt>, defines a main function that calls this function. Building that program with,
</p>
<p>
<tt>gcc MyWrap.c CTest2.c -lopencv_core -lopencv_imgproc -o a.out</tt>
</p>
<p>
or
</p>
<p>
<tt>ghc -no-hs-main MyWrap.c CTest2.c -lopencv_core -lopencv_imgproc -o a.out</tt>
</p>
<p>
produces an executable that runs to completion.
</p>
<p>
Replacing the C main function with a Haskell main, <tt>Test2.hs</tt>, that calls the same function imported via the FFI results in an executable that segfaults. GDB + heavy printf'ing lead to a first crash within OpenCV at an assignment to a local that invokes a copy constructor. Changing this line to some other kind of initialization moves the segfault to another seemingly innocuous location within OpenCV. On the Windows 7 test machine, the segfault occurs in a different place, but also in OpenCV.
</p>
<p>
I have tested this with GHC 7.0.3 and 7.0.3.20110531. The version of gcc on the linux machine is 4.5.2.
</p>
<p>
The OpenCV libraries are .dylib on Mac, .so on Linux, and .dll on Windows. Of note is that OpenCV underwent a fairly large reorganization between 2.1 and 2.2, and is ever more heavily based around templatized C++.
</p>
<p>
I realize that OpenCV is a large dependency for a ticket, so I am willing to run any suggested tests.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5250#changelog