;;; FIXME: old CMU CL representation follows:
;;; Compiled debug variables are in a packed binary representation in the
-;;; DEBUG-FUNCTION-VARIABLES:
+;;; DEBUG-FUN-VARIABLES:
;;; single byte of boolean flags:
;;; uninterned name
;;; packaged name
;;;; compiled debug blocks
;;;;
;;;; Compiled debug blocks are in a packed binary representation in the
-;;;; DEBUG-FUNCTION-BLOCKS:
+;;;; DEBUG-FUN-BLOCKS:
;;;; number of successors + bit flags (single byte)
;;;; elsewhere-p
;;;; ...ordinal number of each successor in the function's blocks vector...
#(:unknown-return :known-return :internal-error :non-local-exit
:block-start :call-site :single-value-return :non-local-entry))
\f
-;;;; DEBUG-FUNCTION objects
+;;;; DEBUG-FUN objects
-(def!struct (debug-function (:constructor nil)))
+(def!struct (debug-fun (:constructor nil)))
-(def!struct (compiled-debug-function (:include debug-function)
- #-sb-xc-host (:pure t))
+(def!struct (compiled-debug-fun (:include debug-fun)
+ #-sb-xc-host (:pure t))
;; The name of this function. If from a DEFUN, etc., then this is the
;; function name, otherwise it is a descriptive string.
(name (required-argument) :type (or simple-string cons symbol))
;;
;; Each entry is:
;; * a FLAGS value, which is a FIXNUM with various
- ;; COMPILED-DEBUG-FUNCTION-FOO bits set
+ ;; COMPILED-DEBUG-FUN-FOO bits set
;; * the symbol which names this variable, unless debug info is minimal
;; * the variable ID, when it has one
;; * SC-offset of primary location, if it has one
;; * SC-offset of save location, if it has one
(variables nil :type (or simple-vector null))
- ;; A vector of the packed binary representation of the COMPILED-DEBUG-BLOCKs
- ;; in this function, in the order that the blocks were emitted. The first
- ;; block is the start of the function. This slot may be NIL to save space.
+ ;; a vector of the packed binary representation of the
+ ;; COMPILED-DEBUG-BLOCKs in this function, in the order that the
+ ;; blocks were emitted. The first block is the start of the
+ ;; function. This slot may be NIL to save space.
;;
;; FIXME: The "packed binary representation" description in the comment
;; above is the same as the description of the old representation of
;; The following two locations are the more arg context and count.
;;
;; <any other symbol>
- ;; The following location is the value of the keyword argument with the
+ ;; The following location is the value of the &KEY argument with the
;; specified name.
;;
;; This may be NIL to save space. If no symbols are present, then this will
;;; debug-info format can represent any function at level 0, and any fixed-arg
;;; function at level 1.
;;;
-;;; In the minimal format, the debug functions and function map are packed into
-;;; a single byte-vector which is placed in the
-;;; COMPILED-DEBUG-INFO-FUNCTION-MAP. Because of this, all functions in a
-;;; component must be representable in minimal format for any function to
-;;; actually be dumped in minimal format. The vector is a sequence of records
-;;; in this format:
+;;; In the minimal format, the debug functions and function map are
+;;; packed into a single byte-vector which is placed in the
+;;; COMPILED-DEBUG-INFO-FUN-MAP. Because of this, all functions in a
+;;; component must be representable in minimal format for any function
+;;; to actually be dumped in minimal format. The vector is a sequence
+;;; of records in this format:
;;; name representation + kind + return convention (single byte)
;;; bit flags (single byte)
;;; setf, nfp, variables
;;; from the previous function's elsewhere code start. (i.e. the
;;; encoding is the same as for code-start-pc.)
-#|
-### For functions with XEPs, name could be represented more simply and
-compactly as some sort of info about with how to find the function-entry that
-this is a function for. Actually, you really hardly need any info. You can
-just chain through the functions in the component until you find the right one.
-Well, I guess you need to at least know which function is an XEP for the real
-function (which would be useful info anyway).
-|#
-
-;;; The following are definitions of bit-fields in the first byte of
-;;; the minimal debug function:
-(defconstant minimal-debug-function-name-symbol 0)
-(defconstant minimal-debug-function-name-packaged 1)
-(defconstant minimal-debug-function-name-uninterned 2)
-(defconstant minimal-debug-function-name-component 3)
-(defconstant-eqx minimal-debug-function-name-style-byte (byte 2 0) #'equalp)
-(defconstant-eqx minimal-debug-function-kind-byte (byte 3 2) #'equalp)
-(defparameter *minimal-debug-function-kinds*
- #(nil :optional :external :top-level :cleanup))
-(defconstant minimal-debug-function-returns-standard 0)
-(defconstant minimal-debug-function-returns-specified 1)
-(defconstant minimal-debug-function-returns-fixed 2)
-(defconstant-eqx minimal-debug-function-returns-byte (byte 2 5) #'equalp)
-
-;;; The following are bit-flags in the second byte of the minimal debug
-;;; function:
-;;; * If true, wrap (SETF ...) around the name.
-(defconstant minimal-debug-function-setf-bit (ash 1 0))
-;;; * If true, there is a NFP.
-(defconstant minimal-debug-function-nfp-bit (ash 1 1))
-;;; * If true, variables (hence arguments) have been dumped.
-(defconstant minimal-debug-function-variables-bit (ash 1 2))
+;;; ### For functions with XEPs, name could be represented more simply
+;;; and compactly as some sort of info about with how to find the
+;;; FUNCTION-ENTRY that this is a function for. Actually, you really
+;;; hardly need any info. You can just chain through the functions in
+;;; the component until you find the right one. Well, I guess you need
+;;; to at least know which function is an XEP for the real function
+;;; (which would be useful info anyway).
\f
;;;; debug source
(def!struct (debug-source #-sb-xc-host (:pure t))
;; This slot indicates where the definition came from:
- ;; :File - from a file (Compile-File)
- ;; :Lisp - from Lisp (Compile)
+ ;; :FILE - from a file (i.e. COMPILE-FILE)
+ ;; :LISP - from Lisp (i.e. COMPILE)
(from (required-argument) :type (member :file :lisp))
- ;; If :File, the file name, if :Lisp or :Stream, then a vector of the
- ;; top-level forms. When from COMPILE, form 0 is #'(LAMBDA ...).
+ ;; If :FILE, the file name, if :LISP or :STREAM, then a vector of
+ ;; the top-level forms. When from COMPILE, form 0 is #'(LAMBDA ...).
(name nil)
- ;; File comment for this file, if any.
- (comment nil :type (or simple-string null))
- ;; The universal time that the source was written, or NIL if unavailable.
+ ;; the universal time that the source was written, or NIL if
+ ;; unavailable
(created nil :type (or unsigned-byte null))
- ;; The universal time that the source was compiled.
+ ;; the universal time that the source was compiled
(compiled (required-argument) :type unsigned-byte)
- ;; The source path root number of the first form read from this source (i.e.
- ;; the total number of forms converted previously in this compilation.)
+ ;; the source path root number of the first form read from this
+ ;; source (i.e. the total number of forms converted previously in
+ ;; this compilation)
(source-root 0 :type index)
- ;; The file-positions of each truly top-level form read from this file (if
- ;; applicable). The vector element type will be chosen to hold the largest
- ;; element. May be null to save space.
+ ;; The FILE-POSITIONs of the truly top-level forms read from this
+ ;; file (if applicable). The vector element type will be chosen to
+ ;; hold the largest element. May be null to save space, or if
+ ;; :DEBUG-SOURCE-FORM is :LISP.
(start-positions nil :type (or (simple-array * (*)) null))
;; If from :LISP, this is the function whose source is form 0.
(info nil))
;; A list of DEBUG-SOURCE structures describing where the code for this
;; component came from, in the order that they were read.
;;
- ;; *** NOTE: the offset of this slot is wired into the fasl dumper so that it
- ;; *** can backpatch the source info when compilation is complete.
+ ;; KLUDGE: comment from CMU CL:
+ ;; *** NOTE: the offset of this slot is wired into the fasl dumper
+ ;; *** so that it can backpatch the source info when compilation
+ ;; *** is complete.
(source nil :type list))
(def!struct (compiled-debug-info
(:include debug-info)
#-sb-xc-host (:pure t))
- ;; a simple-vector of alternating DEBUG-FUNCTION objects and fixnum PCs,
- ;; used to map PCs to functions, so that we can figure out what function we
- ;; were running in. Each function is valid between the PC before it
- ;; (inclusive) and the PC after it (exclusive). The PCs are in sorted order,
- ;; to allow binary search. We omit the first and last PC, since their values
- ;; are 0 and the length of the code vector.
+ ;; a simple-vector of alternating DEBUG-FUN objects and fixnum
+ ;; PCs, used to map PCs to functions, so that we can figure out what
+ ;; function we were running in. Each function is valid between the
+ ;; PC before it (inclusive) and the PC after it (exclusive). The PCs
+ ;; are in sorted order, to allow binary search. We omit the first
+ ;; and last PC, since their values are 0 and the length of the code
+ ;; vector.
;;
- ;; KLUDGE: PC's can't always be represented by FIXNUMs, unless we're always
- ;; careful to put our code in low memory. Is that how it works? Would this
- ;; break if we used a more general memory map? -- WHN 20000120
- (function-map (required-argument) :type simple-vector :read-only t))
+ ;; KLUDGE: PC's can't always be represented by FIXNUMs, unless we're
+ ;; always careful to put our code in low memory. Is that how it
+ ;; works? Would this break if we used a more general memory map? --
+ ;; WHN 20000120
+ (fun-map (required-argument) :type simple-vector :read-only t))
projects / sbcl.git / blobdiff