[project @ 2003-11-03 10:11:04 by simonmar]

merge rev. 1.9.6.1 to the HEAD (add overflown relocs bug)

diff --git a/ghc/docs/users_guide/bugs.sgml b/ghc/docs/users_guide/bugs.sgml
index 60cadd5..fa4abc8 100644 (file)
--- a/ghc/docs/users_guide/bugs.sgml
+++ b/ghc/docs/users_guide/bugs.sgml
@@ -250,10 +250,13 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
     listed above, GHC has the following known bugs or
     infelicities.</para>
 
+  <sect2 id="bugs-ghc">
+    <title>Bugs in GHC</title>
+
     <itemizedlist>
       <listitem>
        <para> GHC can warn about non-exhaustive or overlapping
-        patterns (see <xref linkend="options-sanity">, and usually
+        patterns (see <xref linkend="options-sanity">), and usually
         does so correctly.  But not always.  It gets confused by
         string patterns, and by guards, and can then emit bogus
         warnings.  The entire overlap-check code needs an overhaul
@@ -300,6 +303,33 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
       </listitem>
 
       <listitem>
+       <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>
        <para>GHCi does not respect the <literal>default</literal>
         declaration in the module whose scope you are in.  Instead,
         for expressions typed at the command line, you always get the
@@ -320,28 +350,25 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
         expression.</para>
       </listitem>
 
-      <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
 <programlisting>
-  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
 </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>
+      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>
       </listitem>
     </itemizedlist>
+  </sect2>
   </sect1>
 
 </chapter>