fix rounding of floats big enough to be bignums
[sbcl.git] / src / code / debug-info.lisp
1 ;;;; structures used for recording debugger information
2
3 ;;;; This software is part of the SBCL system. See the README file for
4 ;;;; more information.
5 ;;;;
6 ;;;; This software is derived from the CMU CL system, which was
7 ;;;; written at Carnegie Mellon University and released into the
8 ;;;; public domain. The software is in the public domain and is
9 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
10 ;;;; files for more information.
11
12 (in-package "SB!C")
13 \f
14 ;;;; flags for compiled debug variables
15
16 ;;; FIXME: old CMU CL representation follows:
17 ;;;    Compiled debug variables are in a packed binary representation in the
18 ;;; DEBUG-FUN-VARS:
19 ;;;    single byte of boolean flags:
20 ;;;     uninterned name
21 ;;;        packaged name
22 ;;;     environment-live
23 ;;;     has distinct save location
24 ;;;     has ID (name not unique in this fun)
25 ;;;     minimal debug-info argument (name generated as ARG-0, ...)
26 ;;;     deleted: placeholder for unused minimal argument
27 ;;;    [name length in bytes (as var-length integer), if not minimal]
28 ;;;    [...name bytes..., if not minimal]
29 ;;;    [if packaged, var-length integer that is package name length]
30 ;;;     ...package name bytes...]
31 ;;;    [If has ID, ID as var-length integer]
32 ;;;    SC-Offset of primary location (as var-length integer)
33 ;;;    [If has save SC, SC-OFFSET of save location (as var-length integer)]
34
35 (def!constant compiled-debug-var-more-context-p         #b00000001)
36 (def!constant compiled-debug-var-more-count-p           #b00000010)
37 (def!constant compiled-debug-var-environment-live       #b00000100)
38 (def!constant compiled-debug-var-save-loc-p             #b00001000)
39 (def!constant compiled-debug-var-id-p                   #b00010000)
40 (def!constant compiled-debug-var-minimal-p              #b00100000)
41 (def!constant compiled-debug-var-deleted-p              #b01000000)
42 \f
43 ;;;; compiled debug blocks
44 ;;;;
45 ;;;;    Compiled debug blocks are in a packed binary representation in the
46 ;;;; DEBUG-FUN-BLOCKS:
47 ;;;;    number of successors + bit flags (single byte)
48 ;;;;    elsewhere-p
49 ;;;;    ...ordinal number of each successor in the function's blocks vector...
50 ;;;;    number of locations in this block
51 ;;;;    kind of first location (single byte)
52 ;;;;    delta from previous PC (or from 0 if first location in function.)
53 ;;;;    [offset of first top level form, if no function TLF-NUMBER]
54 ;;;;    form number of first source form
55 ;;;;    first live mask (length in bytes determined by number of VARIABLES)
56 ;;;;    ...more <kind, delta, top level form offset, form-number, live-set>
57 ;;;;       tuples...
58
59 (defconstant-eqx compiled-debug-block-nsucc-byte (byte 2 0) #'equalp)
60 (def!constant compiled-debug-block-elsewhere-p #b00000100)
61
62 (defconstant-eqx compiled-code-location-kind-byte (byte 4 0) #'equalp)
63 (defparameter *compiled-code-location-kinds*
64   #(:unknown-return :known-return :internal-error :non-local-exit
65     :block-start :call-site :single-value-return :non-local-entry
66     :step-before-vop))
67 \f
68 ;;;; DEBUG-FUN objects
69
70 (def!struct (debug-fun (:constructor nil)))
71
72 (def!struct (compiled-debug-fun (:include debug-fun)
73                                 #-sb-xc-host (:pure t))
74   ;; KLUDGE: Courtesy of more than a decade of, ah, organic growth in
75   ;; CMU CL, there are two distinct -- but coupled -- mechanisms to
76   ;; finding the name of a function. The slot here is one mechanism
77   ;; (used in CMU CL to look up names in the debugger, e.g. in
78   ;; BACKTRACE). The other mechanism is the NAME slot in function
79   ;; primitive objects (used in CMU CL to look up names elsewhere,
80   ;; e.g. in CL:FUNCTION-LAMBDA-EXPRESSION and in CL:DESCRIBE).
81   ;;
82   ;; They're coupled by the way that DEBUG-FUN objects are looked up.
83   ;; A list of DEBUG-FUN objects is maintained for each COMPONENT. To
84   ;; figure out which DEBUG-FUN object corresponds to your FUNCTION
85   ;; object, you compare the name values of each. -- WHN 2001-12-20
86   (name (missing-arg) :type (or simple-string cons symbol))
87   ;; The kind of function (same as FUNCTIONAL-KIND):
88   (kind nil :type (member nil :optional :external :toplevel :cleanup))
89   ;; a description of variable locations for this function, in alphabetical
90   ;; order by name; or NIL if no information is available
91   ;;
92   ;; The variable entries are alphabetically ordered. This ordering is
93   ;; used in lifetime info to refer to variables: the first entry is
94   ;; 0, the second entry is 1, etc. Variable numbers are *not* the
95   ;; byte index at which the representation of the location starts.
96   ;;
97   ;; Each entry is:
98   ;;   * a FLAGS value, which is a FIXNUM with various
99   ;;     COMPILED-DEBUG-FUN-FOO bits set
100   ;;   * the symbol which names this variable, unless debug info
101   ;;     is minimal
102   ;;   * the variable ID, when it has one
103   ;;   * SC-offset of primary location, if it has one
104   ;;   * SC-offset of save location, if it has one
105   (vars nil :type (or simple-vector null))
106   ;; a vector of the packed binary representation of the
107   ;; COMPILED-DEBUG-BLOCKs in this function, in the order that the
108   ;; blocks were emitted. The first block is the start of the
109   ;; function. This slot may be NIL to save space.
110   ;;
111   ;; FIXME: The "packed binary representation" description in the
112   ;; comment above is the same as the description of the old
113   ;; representation of VARIABLES which doesn't work properly in SBCL
114   ;; (because it doesn't transform correctly under package renaming).
115   ;; Check whether this slot's data might have the same problem that
116   ;; that slot's data did.
117   (blocks nil :type (or (simple-array (unsigned-byte 8) (*)) null))
118   ;; If all code locations in this function are in the same top level
119   ;; form, then this is the number of that form, otherwise NIL. If
120   ;; NIL, then each code location represented in the BLOCKS specifies
121   ;; the TLF number.
122   (tlf-number nil :type (or index null))
123   ;; a vector describing the variables that the argument values are
124   ;; stored in within this function. The locations are represented by
125   ;; the ordinal number of the entry in the VARIABLES slot value. The
126   ;; locations are in the order that the arguments are actually passed
127   ;; in, but special marker symbols can be interspersed to indicate
128   ;; the original call syntax:
129   ;;
130   ;; DELETED
131   ;;    There was an argument to the function in this position, but it was
132   ;;    deleted due to lack of references. The value cannot be recovered.
133   ;;
134   ;; SUPPLIED-P
135   ;;    The following location is the supplied-p value for the preceding
136   ;;    keyword or optional.
137   ;;
138   ;; OPTIONAL-ARGS
139   ;;    Indicates that following unqualified args are optionals, not required.
140   ;;
141   ;; REST-ARG
142   ;;    The following location holds the list of rest args.
143   ;;
144   ;; MORE-ARG
145   ;;    The following two locations are the more arg context and count.
146   ;;
147   ;; <any other symbol>
148   ;;    The following location is the value of the &KEY argument with the
149   ;;    specified name.
150   ;;
151   ;; This may be NIL to save space. If no symbols are present, then
152   ;; this will be represented with an I-vector with sufficiently large
153   ;; element type. If this is :MINIMAL, then this means that the
154   ;; VARIABLES are all required arguments, and are in the order they
155   ;; appear in the VARIABLES vector. In other words, :MINIMAL stands
156   ;; in for a vector where every element holds its index.
157   (arguments nil :type (or (simple-array * (*)) (member :minimal nil)))
158   ;; There are three alternatives for this slot:
159   ;;
160   ;; a VECTOR
161   ;;    A vector of SC-OFFSETS describing the return locations. The
162   ;;    vector element type is chosen to hold the largest element.
163   ;;
164   ;; :STANDARD
165   ;;    The function returns using the standard unknown-values convention.
166   ;;
167   ;; :FIXED
168   ;;    The function returns using the fixed-values convention, but
169   ;;    in order to save space, we elected not to store a vector.
170   (returns :fixed :type (or (simple-array * (*)) (member :standard :fixed)))
171   ;; SC-OFFSETs describing where the return PC and return FP are kept.
172   (return-pc (missing-arg) :type sc-offset)
173   (old-fp (missing-arg) :type sc-offset)
174   ;; SC-OFFSET for the number stack FP in this function, or NIL if no
175   ;; NFP allocated.
176   (nfp nil :type (or sc-offset null))
177   ;; The earliest PC in this function at which the environment is properly
178   ;; initialized (arguments moved from passing locations, etc.)
179   (start-pc (missing-arg) :type index)
180   ;; The start of elsewhere code for this function (if any.)
181   (elsewhere-pc (missing-arg) :type index))
182 \f
183 ;;;; minimal debug function
184
185 ;;; The minimal debug info format compactly represents debug-info for some
186 ;;; cases where the other debug info (variables, blocks) is small enough so
187 ;;; that the per-function overhead becomes relatively large. The minimal
188 ;;; debug-info format can represent any function at level 0, and any fixed-arg
189 ;;; function at level 1.
190 ;;;
191 ;;; In the minimal format, the debug functions and function map are
192 ;;; packed into a single byte-vector which is placed in the
193 ;;; COMPILED-DEBUG-INFO-FUN-MAP. Because of this, all functions in a
194 ;;; component must be representable in minimal format for any function
195 ;;; to actually be dumped in minimal format. The vector is a sequence
196 ;;; of records in this format:
197 ;;;    name representation + kind + return convention (single byte)
198 ;;;    bit flags (single byte)
199 ;;;     setf, nfp, variables
200 ;;;    [package name length (as var-length int), if name is packaged]
201 ;;;    [...package name bytes, if name is packaged]
202 ;;;    [name length (as var-length int), if there is a name]
203 ;;;    [...name bytes, if there is a name]
204 ;;;    [variables length (as var-length int), if variables flag]
205 ;;;    [...bytes holding variable descriptions]
206 ;;;     If variables are dumped (level 1), then the variables are all
207 ;;;     arguments (in order) with the minimal-arg bit set.
208 ;;;    [If returns is specified, then the number of return values]
209 ;;;    [...sequence of var-length ints holding sc-offsets of the return
210 ;;;     value locations, if fixed return values are specified.]
211 ;;;    return-pc location sc-offset (as var-length int)
212 ;;;    old-fp location sc-offset (as var-length int)
213 ;;;    [nfp location sc-offset (as var-length int), if nfp flag]
214 ;;;    code-start-pc (as a var-length int)
215 ;;;     This field implicitly encodes start of this function's code in the
216 ;;;     function map, as a delta from the previous function's code start.
217 ;;;     If the first function in the component, then this is the delta from
218 ;;;     0 (i.e. the absolute offset.)
219 ;;;    start-pc (as a var-length int)
220 ;;;     This encodes the environment start PC as an offset from the
221 ;;;     code-start PC.
222 ;;;    elsewhere-pc
223 ;;;     This encodes the elsewhere code start for this function, as a delta
224 ;;;     from the previous function's elsewhere code start. (i.e. the
225 ;;;     encoding is the same as for code-start-pc.)
226
227 ;;; ### For functions with XEPs, name could be represented more simply
228 ;;; and compactly as some sort of info about with how to find the
229 ;;; function entry that this is a function for. Actually, you really
230 ;;; hardly need any info. You can just chain through the functions in
231 ;;; the component until you find the right one. Well, I guess you need
232 ;;; to at least know which function is an XEP for the real function
233 ;;; (which would be useful info anyway).
234 \f
235 ;;;; DEBUG SOURCE
236
237 ;;; There is one per compiled file and one per function compiled at
238 ;;; toplevel or loaded from source.
239 (def!struct (debug-source #-sb-xc-host (:pure t))
240   ;; (This is one of those structures where IWBNI we had multiple
241   ;; inheritance.  The first four slots describe compilation of a
242   ;; file, the fifth and sixth compilation of a form processed by
243   ;; EVAL, and the seventh and eigth all compilation units; and these
244   ;; are orthogonal concerns that can combine independently.)
245
246   ;; When the DEBUG-SOURCE describes a file, the file's namestring.
247   ;; Otherwise, NIL.
248   (namestring nil :type (or null string))
249   ;; the universal time that the source was written, or NIL if
250   ;; unavailable
251   (created nil :type (or unsigned-byte null))
252   ;; the source path root number of the first form read from this
253   ;; source (i.e. the total number of forms converted previously in
254   ;; this compilation).  (Note: this will always be 0 so long as the
255   ;; SOURCE-INFO structure has exactly one FILE-INFO.)
256   (source-root 0 :type index)
257   ;; The FILE-POSITIONs of the truly top level forms read from this
258   ;; file (if applicable). The vector element type will be chosen to
259   ;; hold the largest element.
260   (start-positions nil :type (or (simple-array * (*)) null))
261
262   ;; For functions processed by EVAL (including EVAL-WHEN and LOAD on
263   ;; a source file), the source form.
264   (form nil :type list)
265   ;; This is the function whose source is the form.
266   (function nil)
267
268   ;; the universal time that the source was compiled
269   (compiled (missing-arg) :type unsigned-byte)
270   ;; Additional information from (WITH-COMPILATION-UNIT (:SOURCE-PLIST ...))
271   (plist *source-plist*))
272 \f
273 ;;;; DEBUG-INFO structures
274
275 (def!struct debug-info
276   ;; Some string describing something about the code in this component.
277   (name (missing-arg) :type t)
278   ;; A list of DEBUG-SOURCE structures describing where the code for this
279   ;; component came from, in the order that they were read.
280   (source nil))
281
282 (defconstant +debug-info-source-index+
283   (let* ((dd (find-defstruct-description 'debug-info))
284          (slots (dd-slots dd))
285          (source (locally (declare (notinline find)) ; bug 117 bogowarning
286                    (find 'source slots :key #'dsd-name))))
287     (dsd-index source)))
288
289 (def!struct (compiled-debug-info
290              (:include debug-info)
291              #-sb-xc-host (:pure t))
292   ;; a SIMPLE-VECTOR of alternating DEBUG-FUN objects and fixnum
293   ;; PCs, used to map PCs to functions, so that we can figure out what
294   ;; function we were running in. Each function is valid between the
295   ;; PC before it (inclusive) and the PC after it (exclusive). The PCs
296   ;; are in sorted order, to allow binary search. We omit the first
297   ;; and last PC, since their values are 0 and the length of the code
298   ;; vector.
299   ;;
300   ;; KLUDGE: PC's can't always be represented by FIXNUMs, unless we're
301   ;; always careful to put our code in low memory. Is that how it
302   ;; works? Would this break if we used a more general memory map? --
303   ;; WHN 20000120
304   (fun-map (missing-arg) :type simple-vector :read-only t))
305
306 (defvar *!initial-debug-sources*)
307
308 (defun !debug-info-cold-init ()
309   (let ((now (get-universal-time)))
310     (dolist (debug-source *!initial-debug-sources*)
311       (let* ((namestring (debug-source-namestring debug-source))
312              (timestamp (file-write-date namestring)))
313         (setf (debug-source-created debug-source) timestamp
314               (debug-source-compiled debug-source) now)))))