Skip to content
Snippets Groups Projects
  1. Jan 21, 2011
  2. Apr 20, 2010
  3. Mar 19, 2010
  4. Oct 10, 2009
  5. Jun 11, 2009
  6. Sep 07, 2008
  7. Apr 26, 2006
    • rtoy's avatar
      src/save.lisp: · 29b5082e
      rtoy authored
      o Add new search-list "ld-library-path:" which contains the value of
        the environment variable "LD_LIBRARY_PATH".
      
      src/foreign.lisp:
      o Modify LOAD-FOREIGN so that we will try to load a single file as a
        shared library first.  If that fails, we try loading it as an object
        file.  We do not try to see if the library exists (via probe-file or
        anything).  Instead we let dlopen do whatever it would normally do
        to find the file, including searching LD_LIBRARY_PATH.
      
      o REINITIALIZE-GLOBAL-TABLE now has a few restarts to allow the user
        to decide what to do if a shared library cannot be found.  The
        restarts are ignoring the problem, trying to reload the file again,
        or specifying a new path.
      
      o REINITIALIZE-GLOBAL-TABLE is placed on
        EXT:*AFTER-SAVE-INITIALIZATIONS* now.
      29b5082e
  8. Sep 21, 2005
  9. Jul 07, 2005
  10. Jun 20, 2005
  11. Jul 25, 2004
    • pmai's avatar
      This commit adds the remainder of the outstanding PPC/Darwin port merge. · 2ff25623
      pmai authored
      Besides support for Darwin foreign loading, and updates to the ppc-vm
      and bsd-os files, this commit removes unix:unix-errno as a foreign variable
      and replaces it with a function named unix-errno, and a (setf unix-errno).
      This makes both glibc support cleaner, and enables ports like PPC/Darwin
      (and the upcoming win32 port) which have no easy way of accessing errno as
      a foreign variable able to support this functionality at all.
      
      The current implementation of this is rather make-shift, it would likely
      be much cleaner to go the SBCL way and mediate all access to errno via
      defined functions in the C runtime.
      
      As an interim feature, the frobbing of the float-trap-modes is currently
      commented out for Darwin because of ongoing breakage.
      2ff25623
  12. Jul 07, 2004
  13. Jun 13, 2004
    • emarsden's avatar
      · 2e1e9491
      emarsden authored
      Fixes to REINITIALIZE-GLOBAL-TABLE: ignore invalid entries in the
      *GLOBAL-TABLE*, and reload files in the same order as they were initially
      loaded.
      
      From Lynn Quamm.
      2e1e9491
  14. Jun 01, 2004
  15. Apr 28, 2004
    • emarsden's avatar
      · 7df69e0b
      emarsden authored
      On Linux/AMD64, we need to tell the platform linker to use the 32-bit
      linking mode instead of the default 64-bit mode. This can be done either
      via the LDEMULATION environment variable, or via the "-m" command-line
      option.
      
        - in EXT:LOAD-FOREIGN, add LDEMULATION=elf_i386 to the environment
          inherited by the linker
      
      This assumes that the LDEMULATION environment variable will be ignored by
      the platform linker on Linux/i386 platforms.
      7df69e0b
  16. Apr 22, 2004
    • emarsden's avatar
      · f2b840db
      emarsden authored
      Change the behaviour of EXT:LOAD-FOREIGN when called with a single shared
      library: call SYS::LOAD-OBJECT-FILE directly, without invoking the linker as
      previously. This should make it possible to support the reloading of dependent
      shared libraries upon startup of a saved image.
      
      The new behaviour requires a function FILE-SHARED-LIBRARY-P to be defined. I
      have provided an implementation that works for ELF platforms. This has been
      tested with Linux/x86 and Solaris/SPARC, but is also enabled by
      conditionalization for :bsd (should include FreeBSD and OpenBSD).
      
      Also removed pmax support. IRIX and HPPA platforms will need to provide a
      definition for F-S-L-P.
      f2b840db
  17. May 26, 2003
  18. Jan 21, 2003
  19. Aug 28, 2002
    • moore's avatar
      · d31f5d1a
      moore authored
      Fix foregin object braindamage noted by Pierre Mai.
      d31f5d1a
  20. Aug 27, 2002
    • moore's avatar
      · bf84be07
      moore authored
      On x86 FreeBSD and Linux, change the way foreign symbol addresses are resolved.
      They now go through a table -- effectively a new space in the core file.
      Function references are resolved lazily, data references are resolved on startup
      and when a .so is loaded.  The end result is that cores can be dumped that
      contain references to symbols in shared libraries.  Also, the dependence of the core on addresses in the Lisp runtime is broken.
      
      The linkage table feature is controlled by :linkage-table and LINKAGE_TABLE in C
      runtime.  Several foreign symbols are now Lisp static symbols, so a cross
      compile is required whether or not the new stuff is used.  I've checked in
      boot4-cross-foreign-linkage.lisp that builds the compiler for linkage table; do whatever you usually do for the non-linkage table case:)  Seriously, lets start
      a discussion on standardizing "cross compilation," not to mention the general
      build procedure.
      bf84be07
  21. May 06, 2002
    • pmai's avatar
      Changed the OpenBSD port to use dlopen+ld for FFI linkage, like · 956ce339
      pmai authored
      current Linux and FreeBSD/ELF do, although OpenBSD is still non-ELF.
      Also changed the handling of leading underscores in alien names, by
      moving the underscore addition to extern-alien-name, where it belongs,
      and not foreign-symbol-address-aux.  This brings the x86 port in line
      with the other ports, modulo the PVE_stub_ magic.  The changes
      necessitate some bootstrapping code for BSD non-ELF platforms.
      956ce339
  22. Mar 15, 2002
    • moore's avatar
      · 3dc4a6aa
      moore authored
      Fixed #+ conditional so object file loading for the Elf static FreeBSD case
      isn't built on other OSs.
      3dc4a6aa
  23. Mar 13, 2002
    • moore's avatar
      · c90d3517
      moore authored
      Support for dynamic loading in FreeBSD 4.0 and later.  This involves moving
      the static space up, so a cross-compile is required to bootstrap these changes.
      c90d3517
  24. Feb 13, 2002
  25. Jan 28, 2002
    • pmai's avatar
      Added specialised port to NetBSD (1.5.2) on x86. Since the code-base · 4ea11535
      pmai authored
      was already cleaned up with the OpenBSD port, this doesn't require
      massive changes.
      
      Since current NetBSD is ELF-based by default, we don't make use of the
      ELF feature, or in other words:  The presence of the NetBSD feature
      implies ELF, since there is no support for non-ELF NetBSD.
      4ea11535
  26. Dec 06, 2001
    • pmai's avatar
      Added specialised port to OpenBSD (2.9). Many parts of the original · 195461c1
      pmai authored
      code which were previously conditionalized on :FreeBSD, are now
      conditionalized on :BSD instead, with the :BSD feature now implying a
      4.4BSD(lite2) derived OS.  This should make future BSD-ports easier.
      FreeBSD and OpenBSD are differentiated by having either :FreeBSD or
      :OpenBSD on the features list.
      
      Currently the OpenBSD port does not have working ELF support, because
      OpenBSD 2.9 is still non-ELF by default.  So don't put ELF on the
      features list when building for OpenBSD, or fix the code to work
      correctly in this case instead.
      195461c1
  27. Oct 30, 2001
    • pmai's avatar
      This change causes archives passed as a file argument to load-foreign · 184c40f3
      pmai authored
      to be loaded in-full, which is the only useful behaviour when trying
      to link with static libraries.  Currently this change only corrects
      the situation for Linux and Solaris, since I don't know the relevant
      flags for other platforms, and/or don't have access to machines for
      testing.
      184c40f3
  28. May 14, 2001
  29. Jan 05, 2001
  30. Sep 27, 2000
  31. Apr 19, 2000
  32. Aug 30, 1998
    • dtc's avatar
      Revise the address map to better utilise the address space, allowing · 0d71a1cd
      dtc authored
      larger heaps and stacks:
      
      * There is now the potential for up to 2.75GB dynamic space on
      FreeBSD, and 1.75GB on linux.  Since GENCGC statically allocates page
      tables the default size is set at just 1GB.
      
      * The Read-only and Static spaces have been increased to 256MB
      allowing larger heaps to be purified. The Read-only and Static spaces
      are in the same locations for both the FreeBSD and Linux ports to
      avoid unnecessary binary incompatibility.
      
      * The Control stack and Binking stack now have room for upto 128MB,
      supporting deeply nested algorithms, and potentially giving room for
      subdivision for thread stacks.
      
      * There is a reserve for the FreeBSD static libraries in the event
      that the FreeBSD lisp binary is dynamically linked, and the foreign
      segment size for FreeBSD is now 32MB, up from just 4MB.
      
      * There is now significantly more room for C allocated memory, roughly
      128M on Linux and 224M on FreeBSD.
      0d71a1cd
  33. May 01, 1998
  34. Nov 15, 1997
  35. Nov 11, 1997
  36. Oct 25, 1997
    • pw's avatar
      From: Timothy Miller <tsm@cs.brown.edu> · 9a08b1c8
      pw authored
      Ok, here are the updated patches to make the same cmucl lisp.core work
      across OS versions under irix, still by making tzname resolved at runtime
      (on irix only).
      9a08b1c8
  37. Aug 23, 1997
    • pw's avatar
      I just finished making load-foreign work on SGIs, along with fixing calling of · efd9aa3b
      pw authored
      foreign functions taking floating-point arguments after integer arguments but
      before the fourth argument (more or less; mips has unusual C calling
      conventions), and making cmucl work on IRIX 6.2 on the Onyx (where the system
      page size has changed). I've included the patches below, along with some
      discussion of the changes and a couple of problems with cmucl's interaction with
      dynamic loading. Also, there's a misc change to make ioctls work (I'm not sure
      for what version the released code worked, but it doesn't work on anything I
      have). The patches do not fix the R10000; cmucl continues to not work on it (O2
      and Octane).
      
      The fixes make cmucl on the sgi use shared libraries so it can use dlopen et al
      in load-foreign; this is based on the solaris implementation. The problem with
      this is that the addresses of foreign variables are included directly in the
      dumped lisp image (without relocation on loading), which might result in a
      problem if cmucl is run with newer shared libraries than those it was compiled
      and dumped with. As far as I can tell, for the SGI at least, this does not
      affect function calls because the addresses used (and included in the dumped
      image) are those of stub routines that jump to the actual routines, thus are
      located in the executable proper rather than in the shared libraries, and so
      shouldn't be changed by a new version of the shared library.
      
      Unfortunately, this is not the case for global variables. Fortunately, there
      appear to only be two foreign variables used by cmucl in any of its system code
      winding up in the dumped image: errno and tzname. Apparently, Solaris relocates
      data references in dsos to match the program, while IRIX relocates data
      references in the program to match the dso. Thus, on Solaris, you don't need to
      do anything special for cmucl to work with a newer runtime libc, but on IRIX it
      gets the wrong value of errno and tzname. Unfortunately, the address of errno is
      different between irix 6.2, 6.3, and 6.4 (all of which we have to have because
      SGI doesn't have a single cross-platform OS version yet), which would require a
      different lisp.core for each machine (you just need to run mk-lisp, not
      recompile) if it weren't for the hack below. But fortunately again, a lisp
      compiled for one version seems to be able to run on another version well enough
      to generate the new lisp.core (presumably the worst that would happen is that
      error messages could be confusing). It would be really nice to avoid this
      problem. Perhaps some kind of relocation table could be added to the dumped
      image format? I don't know enough about the system to know how possible or
      ridiculous that suggestion is, unfortunately. Is the Solaris behavior guaranteed
      to be the same in future releases? If not, or if any other platforms have the
      irix behavior, this might become a more general problem. In the meantime, we use
      a hack: we *define* errno in undefineds.c rather than just referencing it; this
      results in warnings from the linker, but it resolves the conflict in favor of
      the definition in the program, relocating libc to match, thus fixing this
      problem for errno. The other global variables, tzname et al, can't be fixed this
      way as easily because they're listed as weak symbols, essentially aliases for
      the real symbol, so redefining them wouldn't cause libc to reference the new
      version. Thus, as long as you don't use tzname, there's no problem right now
      (although there may be if any other library global variables are used in cmucl
      in the future). The definition of tzname is in a progn preceeded by a comment
      which says not to use it, so hopefully it's not in fact used and therefore not a
      problem.
      
      
      These patches have been tested on an R5000 O2 running irix 6.3 and a dual R4400
      Onyx running irix 6.2. A previous version of these patches (for 17f) was tested
      on the onyx when it was running 5.3 (I think, maybe 5.2). The patches here are
      from the main branch of the CVS tar as of August 13. Incidentally, it was quite
      painful figuring out how to compile and bootstrap the current sources under the
      distributed irix 18a binary, even without trying :new-random or :signed-array
      (which I haven't tried to do yet); it might be nice to put a newer binary up...
      efd9aa3b
  38. Aug 05, 1997
  39. May 05, 1997
  40. Jan 18, 1997
Loading