[[project @ 2003-11-03 10:11:04 by simonmar]
simonmar**20031103101104
 merge rev. 1.9.6.1 to the HEAD (add overflown relocs bug)
] {
hunk ./ghc/docs/users_guide/bugs.sgml 253
+  <sect2 id="bugs-ghc">
+    <title>Bugs in GHC</title>
+
hunk ./ghc/docs/users_guide/bugs.sgml 259
-        patterns (see <xref linkend="options-sanity">, and usually
+        patterns (see <xref linkend="options-sanity">), and usually
hunk ./ghc/docs/users_guide/bugs.sgml 306
+	<para>GHC's inliner can be persuaded into non-termination
+        using the standard way to encode recursion via a data type:</para>
+<programlisting>
+  data U = MkU (U -> Bool)
+       
+  russel :: U -> Bool
+  russel u@(MkU p) = not $ p u
+  
+  x :: Bool
+  x = russel (MkU russel)
+</programlisting>
+
+        <para>We have never found another class of programs, other
+        than this contrived one, that makes GHC diverge, and fixing
+        the problem would impose an extra overhead on every
+        compilation.  So the bug remains un-fixed.  There is more
+        background in <ulink
+        url="http://research.microsoft.com/~simonpj/Papers/inlining">
+        Secrets of the GHC inliner</ulink>.</para>
+      </listitem>
+    </itemizedlist>
+  </sect2>
+
+  <sect2 id="bugs-ghci">
+    <title>Bugs in GHCi (the interactive GHC)</title>
+    <itemizedlist>
+      <listitem>
hunk ./ghc/docs/users_guide/bugs.sgml 353
-      <listitem>
-	<para>GHC's inliner can be persuaded into non-termination
-        using the standard way to encode recursion via a data type:</para>
+      <listitem> 
+      <para>On Windows, there's a GNU ld/BFD bug
+      whereby it emits bogus PE object files that have more than
+      0xffff relocations. When GHCi tries to load a package affected by this
+      bug, you get an error message of the form
hunk ./ghc/docs/users_guide/bugs.sgml 359
-  data U = MkU (U -> Bool)
-       
-  russel :: U -> Bool
-  russel u@(MkU p) = not $ p u
-  
-  x :: Bool
-  x = russel (MkU russel)
+  Loading package javavm ... linking ... Overflown relocs: 4
hunk ./ghc/docs/users_guide/bugs.sgml 361
-
-        <para>We have never found another class of programs, other
-        than this contrived one, that makes GHC diverge, and fixing
-        the problem would impose an extra overhead on every
-        compilation.  So the bug remains un-fixed.  There is more
-        background in <ulink
-        url="http://research.microsoft.com/~simonpj/Papers/inlining">
-        Secrets of the GHC inliner</ulink>.</para>
+      The last time we looked, this bug still
+      wasn't fixed in the BFD codebase, and there wasn't any
+      noticeable interest in fixing it when we reported the bug
+      back in 2001 or so.
+      </para>
+      <para>The workaround is to split up the .o files that make up
+      your package into two or more .o's, along the lines of
+      how the "base" package does it.</para>
hunk ./ghc/docs/users_guide/bugs.sgml 371
+  </sect2>
}