0.pre7.129:
[sbcl.git] / src / code / debug-info.lisp
index 4c0b7be..760e594 100644 (file)
 ;;;;    number of locations in this block
 ;;;;    kind of first location (single byte)
 ;;;;    delta from previous PC (or from 0 if first location in function.)
-;;;;    [offset of first top-level form, if no function TLF-NUMBER]
+;;;;    [offset of first top level form, if no function TLF-NUMBER]
 ;;;;    form number of first source form
 ;;;;    first live mask (length in bytes determined by number of VARIABLES)
-;;;;    ...more <kind, delta, top-level form offset, form-number, live-set>
+;;;;    ...more <kind, delta, top level form offset, form-number, live-set>
 ;;;;       tuples...
 
 (defconstant-eqx compiled-debug-block-nsucc-byte (byte 2 0) #'equalp)
 
 (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))
+  ;; KLUDGE: Courtesy of more than a decade of, ah, organic growth in
+  ;; CMU CL, there are two distinct -- but coupled -- mechanisms to
+  ;; finding the name of a function. The slot here is one mechanism
+  ;; (used in CMU CL to look up names in the debugger, e.g. in
+  ;; BACKTRACE). The other mechanism is the the NAME slot in function
+  ;; primitive objects (used in CMU CL to look up names elsewhere,
+  ;; e.g. in CL:FUNCTION-LAMBDA-EXPRESSION and in CL:DESCRIBE).
+  ;;
+  ;; They're coupled by the way that DEBUG-FUN objects are looked up.
+  ;; A list of DEBUG-FUN objects is maintained for each COMPONENT. To
+  ;; figure out which DEBUG-FUN object corresponds to your FUNCTION
+  ;; object, you compare the name values of each. -- WHN 2001-12-20
+  (name (missing-arg) :type (or simple-string cons symbol))
   ;; The kind of function (same as FUNCTIONAL-KIND):
-  (kind nil :type (member nil :optional :external :top-level :cleanup))
+  (kind nil :type (member nil :optional :external :toplevel :cleanup))
   ;; a description of variable locations for this function, in alphabetical
   ;; order by name; or NIL if no information is available
   ;;
-  ;; The variable entries are alphabetically ordered. This ordering is used in
-  ;; lifetime info to refer to variables: the first entry is 0, the second
-  ;; entry is 1, etc. Variable numbers are *not* the byte index at which the
-  ;; representation of the location starts.
+  ;; The variable entries are alphabetically ordered. This ordering is
+  ;; used in lifetime info to refer to variables: the first entry is
+  ;; 0, the second entry is 1, etc. Variable numbers are *not* the
+  ;; byte index at which the representation of the location starts.
   ;;
   ;; Each entry is:
   ;;   * a FLAGS value, which is a FIXNUM with various
   ;;     COMPILED-DEBUG-FUN-FOO bits set
-  ;;   * the symbol which names this variable, unless debug info is minimal
+  ;;   * 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
   ;; 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
-  ;; VARIABLES which doesn't work properly in SBCL (because it doesn't
-  ;; transform correctly under package renaming). Check whether this slot's
-  ;; data might have the same problem that that slot's data did.
+  ;; FIXME: The "packed binary representation" description in the
+  ;; comment above is the same as the description of the old
+  ;; representation of VARIABLES which doesn't work properly in SBCL
+  ;; (because it doesn't transform correctly under package renaming).
+  ;; Check whether this slot's data might have the same problem that
+  ;; that slot's data did.
   (blocks nil :type (or (simple-array (unsigned-byte 8) (*)) null))
-  ;; If all code locations in this function are in the same top-level form,
-  ;; then this is the number of that form, otherwise NIL. If NIL, then each
-  ;; code location represented in the BLOCKS specifies the TLF number.
+  ;; If all code locations in this function are in the same top level
+  ;; form, then this is the number of that form, otherwise NIL. If
+  ;; NIL, then each code location represented in the BLOCKS specifies
+  ;; the TLF number.
   (tlf-number nil :type (or index null))
-  ;; A vector describing the variables that the argument values are stored in
-  ;; within this function. The locations are represented by the ordinal number
-  ;; of the entry in the VARIABLES slot value. The locations are in the order
-  ;; that the arguments are actually passed in, but special marker symbols can
-  ;; be interspersed to indicate the original call syntax:
+  ;; a vector describing the variables that the argument values are
+  ;; stored in within this function. The locations are represented by
+  ;; the ordinal number of the entry in the VARIABLES slot value. The
+  ;; locations are in the order that the arguments are actually passed
+  ;; in, but special marker symbols can be interspersed to indicate
+  ;; the original call syntax:
   ;;
   ;; DELETED
   ;;    There was an argument to the function in this position, but it was
   ;;    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
-  ;; be represented with an I-vector with sufficiently large element type. If
-  ;; this is :MINIMAL, then this means that the VARIABLES are all required
-  ;; arguments, and are in the order they appear in the VARIABLES vector. In
-  ;; other words, :MINIMAL stands in for a vector where every element holds its
-  ;; index.
+  ;; This may be NIL to save space. If no symbols are present, then
+  ;; this will be represented with an I-vector with sufficiently large
+  ;; element type. If this is :MINIMAL, then this means that the
+  ;; VARIABLES are all required arguments, and are in the order they
+  ;; appear in the VARIABLES vector. In other words, :MINIMAL stands
+  ;; in for a vector where every element holds its index.
   (arguments nil :type (or (simple-array * (*)) (member :minimal nil)))
   ;; There are three alternatives for this slot:
   ;;
-  ;; A vector
+  ;; a VECTOR
   ;;    A vector of SC-OFFSETS describing the return locations. The
   ;;    vector element type is chosen to hold the largest element.
   ;;
-  ;; :Standard
+  ;; :STANDARD
   ;;    The function returns using the standard unknown-values convention.
   ;;
-  ;; :Fixed
+  ;; :FIXED
   ;;    The function returns using the fixed-values convention, but
   ;;    in order to save space, we elected not to store a vector.
   (returns :fixed :type (or (simple-array * (*)) (member :standard :fixed)))
   ;; SC-Offsets describing where the return PC and return FP are kept.
-  (return-pc (required-argument) :type sc-offset)
-  (old-fp (required-argument) :type sc-offset)
-  ;; SC-Offset for the number stack FP in this function, or NIL if no NFP
-  ;; allocated.
+  (return-pc (missing-arg) :type sc-offset)
+  (old-fp (missing-arg) :type sc-offset)
+  ;; SC-Offset for the number stack FP in this function, or NIL if no
+  ;; NFP allocated.
   (nfp nil :type (or sc-offset null))
   ;; The earliest PC in this function at which the environment is properly
   ;; initialized (arguments moved from passing locations, etc.)
-  (start-pc (required-argument) :type index)
+  (start-pc (missing-arg) :type index)
   ;; The start of elsewhere code for this function (if any.)
-  (elsewhere-pc (required-argument) :type index))
+  (elsewhere-pc (missing-arg) :type index))
 \f
 ;;;; minimal debug function
 
 
 ;;; ### 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
+;;; 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
   ;; This slot indicates where the definition came from:
   ;;    :FILE - from a file (i.e. COMPILE-FILE)
   ;;    :LISP - from Lisp (i.e. COMPILE)
-  (from (required-argument) :type (member :file :lisp))
+  (from (missing-arg) :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 ...).
+  ;; the top level forms. When from COMPILE, form 0 is #'(LAMBDA ...).
   (name nil)
   ;; 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
-  (compiled (required-argument) :type unsigned-byte)
+  (compiled (missing-arg) :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)
   (source-root 0 :type index)
-  ;; The FILE-POSITIONs of the truly top-level forms read from this
+  ;; 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.
 
 (def!struct debug-info
   ;; Some string describing something about the code in this component.
-  (name (required-argument) :type simple-string)
+  (name (missing-arg) :type simple-string)
   ;; A list of DEBUG-SOURCE structures describing where the code for this
   ;; component came from, in the order that they were read.
   ;;
 (def!struct (compiled-debug-info
             (:include debug-info)
             #-sb-xc-host (:pure t))
-  ;; a simple-vector of alternating DEBUG-FUN objects and fixnum
+  ;; 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
   ;; 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))
+  (fun-map (missing-arg) :type simple-vector :read-only t))