Skip to content
Snippets Groups Projects
  1. Oct 07, 2002
    • toy's avatar
      o Reinstate gray-streams support for read-sequence and write-sequence · 62c1a79b
      toy authored
        that was inadvertently deleted.  (Bug noted by Rudi Schlatte).
      o write-sequence was calling system:output-raw-bytes with the wrong
        args.  (Bug noted by Andras Simon)
      62c1a79b
    • toy's avatar
      From Gerd Moelmann, with minor additions for sparc: · 115b4086
      toy authored
      o max/min should check that a real number is given, even for the
        single-arg case instead of just returning the arg.
      115b4086
    • toy's avatar
      o Correct some spelling mistakes · 4fb3490d
      toy authored
      o Fix a few typos in code.
      o Delete a few unused symbols from various places
      o Use something better than %%RWSEQ-EOF%% for the eof marker.
      o Add target-foreign-linkage vars for the PPC and HPPA ports to aid
        cross-compilation.  (The values are very likely wrong, but they're
        not used yet.)
      
      Based on a larger patch from Eric Marsden.
      4fb3490d
  2. Oct 04, 2002
  3. Oct 02, 2002
  4. Oct 01, 2002
  5. Sep 19, 2002
  6. Sep 17, 2002
    • pmai's avatar
      The recent changes which made system:without-hemlock a simple progn if · 0becdc66
      pmai authored
      Hemlock wasn't present, caused the compiler to tail-call eliminate the
      function call in signal handlers defined via define-signal-handler.
      Besides causing problems for the debugger, which now sees a foreign
      function call land frame as the top of stack, this is also confusing
      to the end user, hence we turn up the debug optimization quality to
      prevent tail-call-elimination here.
      0becdc66
  7. Sep 12, 2002
  8. Sep 09, 2002
  9. Sep 07, 2002
  10. Sep 06, 2002
  11. Sep 05, 2002
  12. Sep 04, 2002
  13. Sep 03, 2002
    • toy's avatar
      o Moved the definitions of LOWTAG-BITS, LOWTAG-MASK, and LOWTAG-LIMIT · aa2fda27
      toy authored
        from compiler/generic/objdef.lisp to compiler/sparc/parms.lisp
        because cross-compiling on sparc loads parms after objdef, and parms
        uses these symbols.
      o Added TARGET-FOREIGN-LINKAGE-SPACE-START and
        TARGET-FOREIGN-LINKAGE-ENTRY-SIZE to parms.lisp to support the new
        linkage table stuff.  (Not yet implemented on sparc, so these values
        may be wrong.)
      aa2fda27
  14. Aug 28, 2002
    • pmai's avatar
      A number of smallish changes to the new linkage-table code: · cf055d22
      pmai authored
      o Conditionalized some code that is only used in linkage-table builds
        on :linkage-table and LINKAGE_TABLE respectively.
      o Modernized undefined_ff_tramp based on recent changes, and renamed
        it to undefined_foreign_symbol_trap, because it really isn't a
        trampoline.
      o Conditionalized a stray puts(...,dlerror()) in Linux-os.c on DEBUG
      o Installed an error reporter for UNDEFINED_FOREIGN_SYMBOL_ERROR,
        which for now signals a simple-program-error.  We might want to
        introduced a new condition UNDEFINED-FOREIGN-SYMBOL or something,
        which could also be used by the old foreign linkage code.
      cf055d22
    • moore's avatar
      · d31f5d1a
      moore authored
      Fix foregin object braindamage noted by Pierre Mai.
      d31f5d1a
  15. 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
Loading