1. 08 Oct, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-10-08 09:42:34 by wolfgang] · 2203c0ce
      wolfgang authored
      Mac OS X/PowerPC:
      Learn to cope with out-of-range relative jumps.
      PowerPC relative branch instructions have a 24 bit displacement field.
      As PPC code is always 4-byte-aligned, this yields a +-32MB range.
      If a particular imported symbol is outside this range, we have to redirect
      the jump to a short piece of new code that just loads the 32bit absolute
      address and jumps there.
  2. 09 Jun, 2002 1 commit
  3. 04 Sep, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-09-04 16:33:04 by sewardj] · 9c5f23d4
      sewardj authored
      Further linker fixes.  Record .bss space allocated, for the benefit of
      LOOKS_LIKE_GHC_INFO etc tests done by the GC.  In this commit, for
      Win32 only.
      Also some minor tweaks so that -package win32 can be loaded into GHCi.
  4. 29 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-29 15:12:21 by sewardj] · cb97b80d
      sewardj authored
      Make the PEi386 linker able to handle symbols in .bss sections
      (almost) correctly:
      * "Anonymous" bss sections (where something like
           static int a[10]
        lives) are given a calloc'd block of memory to live in.
      * Publically visible bss-resident symbols, such as
          int a[10]
        are each given their own calloc'd block.  The normal
        way of things is for identically-named symbols in different
        modules to be commoned up and allocated the largest stated
        size of any of the symbols.  We don't do that -- if two different
        .o files each declared  int a[10],  you'll get two independent
        lumps of memory.  Hence "almost" above.
      These calloc'd lumps (pseudo-bss spaces) are not added to the list
      of sections extracted for the benefit of the closure-vs-itbl pointer
      checks done by the garbage collector.  I don't think that matters.
      These fixes need to be propagated to other formats too (viz, ELF).
      This fixes the problem reported by ??? in which, on Windows,
         writeFile "foo" "bar" in GHCi gives a segfault.
      This bug was so horrible to track down and fix that I have instituted
      range checking in the relocation processing machinery.  The runtime
      linker checks all locations it is patching to ensure they are within
      a known segment before writing to them.  Hopefully this will pick up
      any future problems.  The performance impact of this, assessed by
      the time to start up GHCi, is unmeasureably small.
  5. 28 Feb, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-02-28 10:03:42 by sewardj] · af3063d6
      sewardj authored
      Yesterday's changes to the runtime linker:
      * Update the PEi386 stuff to compile in the new framework.
        Note!  Certainly will _not_ work properly as-is.
      * A conceptual cleanup for all platforms: only record, in the
        oc.symbols field, the names of symbols which have been put into the
        global symbol table, rather than (name, addr) pairs -- the addr
        is redundant.
  6. 12 Feb, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-02-12 12:46:23 by sewardj] · 4b6c8c65
      sewardj authored
      Teach the runtime linker about local symbols, so that we don't have to
      rely on batch linkers to resolve local symbols in libraries at
  7. 11 Feb, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-02-11 17:51:07 by simonmar] · 6d35596c
      simonmar authored
      Bite the bullet and make GHCi support non-optional in the RTS.  GHC
      4.11 should be able to build GHCi without any additional tweaks now.
      - the Linker is split into two parts: LinkerBasic.c, containing the
        routines required by the rest of the RTS, and Linker.c, containing
        the linker proper, which is not referred to from the rest of the RTS.
        Only Linker.c requires -ldl, so programs which don't make use of the
        linker (everything except GHC, in other words) won't need -ldl.