1. 27 Sep, 2010 1 commit
  2. 13 Jul, 2010 1 commit
  3. 16 Dec, 2009 1 commit
    • howard_b_golden@yahoo.com's avatar
      FIX #2615 (linker scripts in .so files) · e020e387
      howard_b_golden@yahoo.com authored
      This patch does not apply to Windows. It only applies to systems with
      ELF binaries.
      This is a patch to rts/Linker.c to recognize linker scripts in .so
      files and find the real target .so shared library for loading.
  4. 04 Aug, 2008 2 commits
  5. 30 Jul, 2008 1 commit
  6. 12 Apr, 2007 1 commit
  7. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  8. 25 Oct, 2005 1 commit
    • wolfgang's avatar
      [project @ 2005-10-25 02:57:47 by wolfgang] · ee6e44cc
      wolfgang authored
      Mac OS X/Darwin PowerPC: Fix a problem introduced by the recent Darwin/x86
      Remember how we deliberately misaligned the .o file in memory to compensate
      for Mach-O's lax alignment rules.
      This should have been comitted along with Linker.c 1.203 about two weeks ago.
  9. 21 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-21 14:02:17 by simonmar] · 03a9ff01
      simonmar authored
      Big re-hash of the threaded/SMP runtime
      This is a significant reworking of the threaded and SMP parts of
      the runtime.  There are two overall goals here:
        - To push down the scheduler lock, reducing contention and allowing
          more parts of the system to run without locks.  In particular,
          the scheduler does not require a lock any more in the common case.
        - To improve affinity, so that running Haskell threads stick to the
          same OS threads as much as possible.
      At this point we have the basic structure working, but there are some
      pieces missing.  I believe it's reasonably stable - the important
      parts of the testsuite pass in all the (normal,threaded,SMP) ways.
      In more detail:
        - Each capability now has a run queue, instead of one global run
          queue.  The Capability and Task APIs have been completely
          rewritten; see Capability.h and Task.h for the details.
        - Each capability has its own pool of worker Tasks.  Hence, Haskell
          threads on a Capability's run queue will run on the same worker
          Task(s).  As long as the OS is doing something reasonable, this
          should mean they usually stick to the same CPU.  Another way to
          look at this is that we're assuming each Capability is associated
          with a fixed CPU.
        - What used to be StgMainThread is now part of the Task structure.
          Every OS thread in the runtime has an associated Task, and it
          can ask for its current Task at any time with myTask().
        - removed RTS_SUPPORTS_THREADS symbol, use THREADED_RTS instead
          (it is now defined for SMP too).
        - The RtsAPI has had to change; we must explicitly pass a Capability
          around now.  The previous interface assumed some global state.
          SchedAPI has also changed a lot.
        - The OSThreads API now supports thread-local storage, used to
          implement myTask(), although it could be done more efficiently
          using gcc's __thread extension when available.
        - I've moved some POSIX-specific stuff into the posix subdirectory,
          moving in the direction of separating out platform-specific
        - lots of lock-debugging and assertions in the runtime.  In particular,
          when DEBUG is on, we catch multiple ACQUIRE_LOCK()s, and there is
          also an ASSERT_LOCK_HELD() call.
      What's missing so far:
        - I have almost certainly broken the Win32 build, will fix soon.
        - any kind of thread migration or load balancing.  This is high up
          the agenda, though.
        - various performance tweaks to do
        - throwTo and forkProcess still do not work in SMP mode
  10. 17 Feb, 2005 1 commit
    • desrt's avatar
      [project @ 2005-02-17 16:58:18 by desrt] · cfc30307
      desrt authored
      LinkerInternals.h: all platforms: changed 'image' pointer in ObjectCode
                                        from (void *) to (char *).
      Linker.c: linux/ppc: added mremap() support to unbreak the build when
                           USE_MMAP is defined on linux/ppc (as it now is.)
  11. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      Recall that:
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      Actual changes:
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
       - the compiler's Makefile now generates
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
       - The Users's Guide is updated to mention *_HOST_* rather than
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      Thanks to Wolfgang Thaller for pointing me in the right direction.
  12. 27 Sep, 2004 1 commit
  13. 12 Sep, 2004 1 commit
  14. 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.
  15. 09 Jun, 2002 1 commit
  16. 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.
  17. 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.
  18. 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.
  19. 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
  20. 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.