that this merely obscures, not solves, the underlying problem; as and when
underlying problems are fixed, it would be worth trying again to provoke
this problem.
+
+288: fundamental cross-compilation issues (from old UGLINESS file)
+ 288a: Using host floating point numbers to represent target
+ floating point numbers, or host characters to represent
+ target characters, is theoretically shaky. (The characters
+ are OK as long as the characters are in the ANSI-guaranteed
+ character set, though, so they aren't a real problem as
+ long as the sources don't need anything but that.)
+ 288b: The compiler still makes assumptions about cross-compilation-host
+ implementation of ANSI CL:
+ 288b1: Simple bit vectors are distinct from simple vectors (in
+ DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure*
+ that things would really break if this weren't so, but I
+ strongly suspect that they would.)
+ 288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is
+ in a sense just one aspect of bug 288a.)
obscure ANSI requirements
changes in sbcl-0.8.4 relative to sbcl-0.8.3:
+ * incompatible change: The --disable-debugger command line
+ option now clobbers the debugger at a more fundamental
+ level, by redefining #'INVOKE-DEBUGGER instead of by
+ rebinding *DEBUGGER-HOOK*. The main difference is that BREAK
+ is specified by ANSI to ignore *DEBUGGER-HOOK* and
+ INVOKE-DEBUGGER regardless. Under the old system, BREAK would
+ enter the debugger REPL and then suffer recursive errors
+ because *DEBUG-IO* is also messed up in --disable-debugger mode;
+ while under the new system, BREAK in --disable-debugger mode
+ terminates the system just as an unhandled error would.
* fixed compiler performance when processing loops with a step >1;
* bug fix: DOCUMENTATION now retrieves generic function
documentation. Also, DOCUMENTATION and (SETF DOCUMENTATION)
+++ /dev/null
-There are a number of hacks that I've used to make the system work
-that even I can see are ugly. Some which come to mind..
-
-It's dependent on being compiled in a rigid sequence, all in a single
-compilation pass, particularly in the cross-compilation phase.
-There's very little support for compiling modules in parallel
-or recompiling the system incrementally.
-
-The way the cross-compiler uses UNCROSS is ugly.
-
-The heavy use of %PYTHON:DEFMACRO to construct basic macros is
-arguably ugly. But it's better than what I tried before that, and the
-system is still slightly contaminated with fallout from what I tried..
-When I was first trying to bootstrap the system, I went off on a wild
-goose chase of trying to define everything (even fundamental macros
-like DEFUN and DEFMACRO) in terms of ordinary functions and Lisp
-special operators. I later realized that I could do without this, but
-a number of the changes that I made to the code while on that chase
-still live on, and the code is unnecessarily unclear because of them.
-
-The contrapuntal intertwingling of the cross-compiler and
-target Lisp build sequences is, well, baroque.
-
-Using host floating point numbers to represent target floating point
-numbers, or host characters to represent target characters, is theoretically
-shaky. (The characters are OK as long as the characters are
-in the ANSI-guaranteed character set, though.)
-
-Despite my attempts to make the compiler portable, it still makes assumptions
-about the cross-compilation host Common Lisp:
- Simple bit vectors are distinct from simple vectors (in
- DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not sure
- that things would really break if this weren't so, but I
- strongly suspect that they would.)
- SINGLE-FLOAT is distinct from DOUBLE-FLOAT.
pipelines.
.TP 3
.B --disable-debugger
-This is equivalent to --eval '(sb-ext:disable-debugger)'.
-By default, a Common Lisp system tries to ask the programmer for help
-when it gets in trouble (by printing a debug prompt on *DEBUG-IO*).
-However, this is not useful behavior for a system running with no
-programmer available, and this option tries to set up more appropriate
-behavior for that situation. This is implemented by modifying special
-variables: we set *DEBUG-IO* to send its output to *ERROR-OUTPUT*, and
-to raise an error if any input is requested from it, and we set
-*DEBUGGER-HOOK* to output a backtrace, then exit the process with a
-failure code. Because it is implemented by modifying special variables,
-its effects persist in .core files created by SB-EXT:SAVE-LISP-AND-DIE.
-(If you want to undo its effects, see the SB-EXT:ENABLE-DEBUGGER
+This is equivalent to --eval '(sb-ext:disable-debugger)'. By default,
+a Common Lisp system tries to ask the programmer for help when it gets
+in trouble (by printing a debug prompt, then listening, on
+*DEBUG-IO*). However, this is not useful behavior for a system running
+with no programmer available, and this option tries to set up more
+appropriate behavior for that situation. This is implemented by
+redefining INVOKE-DEBUGGER so that any call exits the process with a
+failure code after printing a backtrace, and by redefining *DEBUG-IO*
+to send its output to *ERROR-OUTPUT* and to raise an error if any
+input is requested from it. (Note that because it is implemented by
+modifying special variables and FDEFINITIONs, its effects persist in
+.core files created by SB-EXT:SAVE-LISP-AND-DIE. If you want to undo
+its effects, e.g. if you build a system unattended and then want to
+operate a derived system interactively, see the SB-EXT:ENABLE-DEBUGGER
command.)
.PP
;; (There used to be more cases back before sbcl-0.7.0, when
;; we did special tricks to debug the IR1 interpreter.)
))
-
-(defun print-code-locations (function)
- (let ((debug-fun (fun-debug-fun function)))
- (do-debug-fun-blocks (block debug-fun)
- (do-debug-block-locations (loc block)
- (fill-in-code-location loc)
- (format t "~S code location at ~W"
- (compiled-code-location-kind loc)
- (compiled-code-location-pc loc))
- (sb!debug::print-code-location-source-form loc 0)
- (terpri)))))
(defvar *debug-condition*)
(defvar *nested-debug-condition*)
-(defun invoke-debugger (condition)
+;;; the ordinary ANSI case of INVOKE-DEBUGGER, when not suppressed by
+;;; command-line --disable-debugger option
+(defun invoke-debugger/enabled (condition)
#!+sb-doc
"Enter the debugger."
(let ((old-hook *debugger-hook*))
(internal-debug))
(when background-p (sb!thread::release-foreground)))))))
+;;; the degenerate case of INVOKE-DEBUGGER, when ordinary ANSI behavior
+;;; has been suppressed by command-line --disable-debugger option
+(defun invoke-debugger/disabled (condition)
+ ;; There is no one there to interact with, so report the
+ ;; condition and terminate the program.
+ (flet ((failure-quit (&key recklessly-p)
+ (/show0 "in FAILURE-QUIT (in --disable-debugger debugger hook)")
+ (quit :unix-status 1 :recklessly-p recklessly-p)))
+ ;; This HANDLER-CASE is here mostly to stop output immediately
+ ;; (and fall through to QUIT) when there's an I/O error. Thus,
+ ;; when we're run under a shell script or something, we can die
+ ;; cleanly when the script dies (and our pipes are cut), instead
+ ;; of falling into ldb or something messy like that. Similarly, we
+ ;; can terminate cleanly even if BACKTRACE dies because of bugs in
+ ;; user PRINT-OBJECT methods.
+ (handler-case
+ (progn
+ (format *error-output*
+ "~&~@<unhandled condition (of type ~S): ~2I~_~A~:>~2%"
+ (type-of condition)
+ condition)
+ ;; Flush *ERROR-OUTPUT* even before the BACKTRACE, so that
+ ;; even if we hit an error within BACKTRACE (e.g. a bug in
+ ;; the debugger's own frame-walking code, or a bug in a user
+ ;; PRINT-OBJECT method) we'll at least have the CONDITION
+ ;; printed out before we die.
+ (finish-output *error-output*)
+ ;; (Where to truncate the BACKTRACE is of course arbitrary, but
+ ;; it seems as though we should at least truncate it somewhere.)
+ (sb!debug:backtrace 128 *error-output*)
+ (format
+ *error-output*
+ "~%unhandled condition in --disable-debugger mode, quitting~%")
+ (finish-output *error-output*)
+ (failure-quit))
+ (condition ()
+ ;; We IGNORE-ERRORS here because even %PRIMITIVE PRINT can
+ ;; fail when our output streams are blown away, as e.g. when
+ ;; we're running under a Unix shell script and it dies somehow
+ ;; (e.g. because of a SIGINT). In that case, we might as well
+ ;; just give it up for a bad job, and stop trying to notify
+ ;; the user of anything.
+ ;;
+ ;; Actually, the only way I've run across to exercise the
+ ;; problem is to have more than one layer of shell script.
+ ;; I have a shell script which does
+ ;; time nice -10 sh make.sh "$1" 2>&1 | tee make.tmp
+ ;; and the problem occurs when I interrupt this with Ctrl-C
+ ;; under Linux 2.2.14-5.0 and GNU bash, version 1.14.7(1).
+ ;; I haven't figured out whether it's bash, time, tee, Linux, or
+ ;; what that is responsible, but that it's possible at all
+ ;; means that we should IGNORE-ERRORS here. -- WHN 2001-04-24
+ (ignore-errors
+ (%primitive print
+ "Argh! error within --disable-debugger error handling"))
+ (failure-quit :recklessly-p t)))))
+
+;;; halt-on-failures and prompt-on-failures modes, suitable for
+;;; noninteractive and interactive use respectively
+(defun disable-debugger ()
+ (setf (fdefinition 'invoke-debugger) #'invoke-debugger/disabled
+ *debug-io* *error-output*))
+(defun enable-debugger ()
+ (setf (fdefinition 'invoke-debugger) #'invoke-debugger/enabled
+ *debug-io* *query-io*))
+;;; The enabled mode is the ANSI default.
+(enable-debugger)
+
(defun show-restarts (restarts s)
(cond ((null restarts)
(format s
;; (classic CMU CL error message: "You're certainly a clever child.":-)
(critically-unreachable "after TOPLEVEL-REPL"))))
-;;; halt-on-failures and prompt-on-failures modes, suitable for
-;;; noninteractive and interactive use respectively
-(defun disable-debugger ()
- (setf *debugger-hook* 'noprogrammer-debugger-hook-fun
- *debug-io* *error-output*))
-(defun enable-debugger ()
- (setf *debugger-hook* nil
- *debug-io* *query-io*))
-
;;; read-eval-print loop for the default system toplevel
(defun toplevel-repl (noprint)
(/show0 "entering TOPLEVEL-REPL")
(dolist (result results)
(fresh-line)
(prin1 result))))))
-
-;;; suitable value for *DEBUGGER-HOOK* for a noninteractive Unix-y program
-(defun noprogrammer-debugger-hook-fun (condition old-debugger-hook)
- (declare (ignore old-debugger-hook))
- (flet ((failure-quit (&key recklessly-p)
- (/show0 "in FAILURE-QUIT (in --disable-debugger debugger hook)")
- (quit :unix-status 1 :recklessly-p recklessly-p)))
- ;; This HANDLER-CASE is here mostly to stop output immediately
- ;; (and fall through to QUIT) when there's an I/O error. Thus,
- ;; when we're run under a shell script or something, we can die
- ;; cleanly when the script dies (and our pipes are cut), instead
- ;; of falling into ldb or something messy like that.
- (handler-case
- (progn
- (format *error-output*
- "~&~@<unhandled condition (of type ~S): ~2I~_~A~:>~2%"
- (type-of condition)
- condition)
- ;; Flush *ERROR-OUTPUT* even before the BACKTRACE, so that
- ;; even if we hit an error within BACKTRACE (e.g. a bug in
- ;; the debugger's own frame-walking code, or a bug in a user
- ;; PRINT-OBJECT method) we'll at least have the CONDITION
- ;; printed out before we die.
- (finish-output *error-output*)
- ;; (Where to truncate the BACKTRACE is of course arbitrary, but
- ;; it seems as though we should at least truncate it somewhere.)
- (sb!debug:backtrace 128 *error-output*)
- (format
- *error-output*
- "~%unhandled condition in --disable-debugger mode, quitting~%")
- (finish-output *error-output*)
- (failure-quit))
- (condition ()
- ;; We IGNORE-ERRORS here because even %PRIMITIVE PRINT can
- ;; fail when our output streams are blown away, as e.g. when
- ;; we're running under a Unix shell script and it dies somehow
- ;; (e.g. because of a SIGINT). In that case, we might as well
- ;; just give it up for a bad job, and stop trying to notify
- ;; the user of anything.
- ;;
- ;; Actually, the only way I've run across to exercise the
- ;; problem is to have more than one layer of shell script.
- ;; I have a shell script which does
- ;; time nice -10 sh make.sh "$1" 2>&1 | tee make.tmp
- ;; and the problem occurs when I interrupt this with Ctrl-C
- ;; under Linux 2.2.14-5.0 and GNU bash, version 1.14.7(1).
- ;; I haven't figured out whether it's bash, time, tee, Linux, or
- ;; what that is responsible, but that it's possible at all
- ;; means that we should IGNORE-ERRORS here. -- WHN 2001-04-24
- (ignore-errors
- (%primitive print
- "Argh! error within --disable-debugger error handling"))
- (failure-quit :recklessly-p t)))))
\f
;;; a convenient way to get into the assembly-level debugger
(defun %halt ()
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.3.56"
+"0.8.3.57"
projects / sbcl.git / commitdiff