| blob | 6bdd89a38def0ddd219757cee1b4a19be06d552b |
1 ;;;; the implementation of the programmer's interface to writing
2 ;;;; debugging tools
4 ;;;; This software is part of the SBCL system. See the README file for
5 ;;;; more information.
6 ;;;;
7 ;;;; This software is derived from the CMU CL system, which was
8 ;;;; written at Carnegie Mellon University and released into the
9 ;;;; public domain. The software is in the public domain and is
10 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
11 ;;;; files for more information.
15 ;;; FIXME: There are an awful lot of package prefixes in this code.
16 ;;; Couldn't we have SB-DI use the SB-C and SB-VM packages?
17 \f
18 ;;;; conditions
20 ;;;; The interface to building debugging tools signals conditions that
21 ;;;; prevent it from adhering to its contract. These are
22 ;;;; serious-conditions because the program using the interface must
23 ;;;; handle them before it can correctly continue execution. These
24 ;;;; debugging conditions are not errors since it is no fault of the
25 ;;;; programmers that the conditions occur. The interface does not
26 ;;;; provide for programs to detect these situations other than
27 ;;;; calling a routine that detects them and signals a condition. For
28 ;;;; example, programmers call A which may fail to return successfully
29 ;;;; due to a lack of debug information, and there is no B the they
30 ;;;; could have called to realize A would fail. It is not an error to
31 ;;;; have called A, but it is an error for the program to then ignore
32 ;;;; the signal generated by A since it cannot continue without A's
33 ;;;; correctly returning a value or performing some operation.
34 ;;;;
35 ;;;; Use DEBUG-SIGNAL to signal these conditions.
38 ()
39 #!+sb-doc
40 (:documentation
41 "All DEBUG-CONDITIONs inherit from this type. These are serious conditions
47 #!+sb-doc
48 (:documentation
49 "The system could not return values from a frame with DEBUG-FUN since
55 "~&Cannot return values from ~:[frame~;~:*~S~] since ~
56 the debug information lacks details about returning ~
57 values here."
58 fun)))))
63 #!+sb-doc
72 #!+sb-doc
81 #!+sb-doc
82 (:documentation
83 "The DEBUG-FUN has no lambda list since argument DEBUG-VARs are
104 \f
105 ;;;; errors and DEBUG-SIGNAL
107 ;;; The debug-internals code tries to signal all programmer errors as
108 ;;; subtypes of DEBUG-ERROR. There are calls to ERROR signalling
109 ;;; SIMPLE-ERRORs, but these dummy checks in the code and shouldn't
110 ;;; come up.
111 ;;;
112 ;;; While under development, this code also signals errors in code
113 ;;; branches that remain unimplemented.
116 #!+sb-doc
117 (:documentation
118 "All programmer errors from using the interface for building debugging
144 ()
157 stream
158 "~&Form was preprocessed for ~S,~% but called on ~S:~% ~S"
163 ;;; This signals debug-conditions. If they go unhandled, then signal
164 ;;; an UNHANDLED-DEBUG-CONDITION error.
165 ;;;
166 ;;; ??? Get SIGNAL in the right package!
171 \f
172 ;;;; structures
173 ;;;;
174 ;;;; Most of these structures model information stored in internal
175 ;;;; data structures created by the compiler. Whenever comments
176 ;;;; preface an object or type with "compiler", they refer to the
177 ;;;; internal compiler thing, not to the object or type with the same
178 ;;;; name in the "SB-DI" package.
180 ;;;; DEBUG-VARs
182 ;;; These exist for caching data stored in packed binary form in
183 ;;; compiler DEBUG-FUNs.
186 ;; the name of the variable
188 ;; a unique integer identification relative to other variables with the same
189 ;; symbol
191 ;; Does the variable always have a valid value?
196 "~S ~W"
200 #!+sb-doc
202 "Return the integer that makes DEBUG-VAR's name and package unique
207 (:constructor make-compiled-debug-var
209 sc-offset save-sc-offset indirect-sc-offset info))
211 ;; storage class and offset (unexported)
213 ;; storage class and offset when saved somewhere
215 ;; For indirect closures the fp of the parent frame is stored in the
216 ;; normal sc-offsets above, and this has the offset into the frame
220 ;;;; DEBUG-FUNs
222 ;;; These exist for caching data stored in packed binary form in
223 ;;; compiler DEBUG-FUNs. *COMPILED-DEBUG-FUNS* maps a SB!C::DEBUG-FUN
224 ;;; to a DEBUG-FUN. There should only be one DEBUG-FUN in existence
225 ;;; for any function; that is, all CODE-LOCATIONs and other objects
226 ;;; that reference DEBUG-FUNs point to unique objects. This is
227 ;;; due to the overhead in cached information.
231 ;; some representation of the function arguments. See
232 ;; DEBUG-FUN-LAMBDA-LIST.
233 ;; NOTE: must parse vars before parsing arg list stuff.
235 ;; cached DEBUG-VARS information (unexported).
236 ;; These are sorted by their name.
238 ;; cached debug-block information. This is NIL when we have tried to
239 ;; parse the packed binary info, but none is available.
241 ;; the actual function if available
249 (:constructor make-bogus-debug-fun
256 %name)
258 ;;;; DEBUG-BLOCKs
260 ;;; These exist for caching data stored in packed binary form in compiler
261 ;;; DEBUG-BLOCKs.
264 ;; This indicates whether the block is a special glob of code shared
265 ;; by various functions and tucked away elsewhere in a component.
266 ;; This kind of block has no start code-location. This slot is in
267 ;; all debug-blocks since it is an exported interface.
273 #!+sb-doc
279 ;; code-location information for the block
284 ;; the DEBUG-FUN containing this CODE-LOCATION
286 ;; This is initially :UNSURE. Upon first trying to access an
287 ;; :UNPARSED slot, if the data is unavailable, then this becomes T,
288 ;; and the code-location is unknown. If the data is available, this
289 ;; becomes NIL, a known location. We can't use a separate type
290 ;; code-location for this since we must return code-locations before
291 ;; we can tell whether they're known or unknown. For example, when
292 ;; parsing the stack, we don't want to unpack all the variables and
293 ;; blocks just to make frames.
295 ;; the DEBUG-BLOCK containing CODE-LOCATION. XXX Possibly toss this
296 ;; out and just find it in the blocks cache in DEBUG-FUN.
298 ;; This is the number of forms processed by the compiler or loader
299 ;; before the top level form containing this code-location.
301 ;; This is the depth-first number of the node that begins
302 ;; code-location within its top level form.
305 ;;;; frames
307 ;;; These represent call frames on the stack.
310 ;; the next frame up, or NIL when top frame
312 ;; the previous frame down, or NIL when the bottom frame. Before
313 ;; computing the next frame down, this slot holds the frame pointer
314 ;; to the control stack for the given frame. This lets us get the
315 ;; next frame down and the return-pc for that frame.
317 ;; the DEBUG-FUN for the function whose call this frame represents
319 ;; the CODE-LOCATION where the frame's DEBUG-FUN will continue
320 ;; running when program execution returns to this frame. If someone
321 ;; interrupted this frame, the result could be an unknown
322 ;; CODE-LOCATION.
324 ;; an a-list of catch-tags to code-locations
326 ;; pointer to frame on control stack (unexported)
327 pointer
328 ;; This is the frame's number for prompt printing. Top is zero.
333 (:constructor make-compiled-frame
337 ;; This indicates whether someone interrupted the frame.
338 ;; (unexported). If escaped, this is a pointer to the state that was
339 ;; saved when we were interrupted, an os_context_t, i.e. the third
340 ;; argument to an SA_SIGACTION-style signal handler.
341 escaped)
345 "~S~:[~;, interrupted~]"
348 \f
350 ;;; This maps SB!C::COMPILED-DEBUG-FUNs to
351 ;;; COMPILED-DEBUG-FUNs, so we can get at cached stuff and not
352 ;;; duplicate COMPILED-DEBUG-FUN structures.
355 ;;; Make a COMPILED-DEBUG-FUN for a SB!C::COMPILER-DEBUG-FUN and its
356 ;;; component. This maps the latter to the former in
357 ;;; *COMPILED-DEBUG-FUNS*. If there already is a COMPILED-DEBUG-FUN,
358 ;;; then this returns it from *COMPILED-DEBUG-FUNS*.
359 ;;;
360 ;;; FIXME: It seems this table can potentially grow without bounds,
361 ;;; and retains roots to functions that might otherwise be collected.
368 \f
369 ;;;; breakpoints
371 ;;; This is an internal structure that manages information about a
372 ;;; breakpoint locations. See *COMPONENT-BREAKPOINT-OFFSETS*.
376 ;; This is the component in which the breakpoint lies.
377 component
378 ;; This is the byte offset into the component.
380 ;; The original instruction replaced by the breakpoint.
382 ;; A list of user breakpoints at this location.
395 ;; This is the function invoked when execution encounters the
396 ;; breakpoint. It takes a frame, the breakpoint, and optionally a
397 ;; list of values. Values are supplied for :FUN-END breakpoints as
398 ;; values to return for the function containing the breakpoint.
399 ;; :FUN-END breakpoint hook functions also take a cookie argument.
400 ;; See the COOKIE-FUN slot.
402 ;; CODE-LOCATION or DEBUG-FUN
404 ;; :CODE-LOCATION, :FUN-START, or :FUN-END for that kind
405 ;; of breakpoint. :UNKNOWN-RETURN-PARTNER if this is the partner of
406 ;; a :code-location breakpoint at an :UNKNOWN-RETURN code-location.
409 ;; Status helps the user and the implementation.
411 ;; This is a backpointer to a breakpoint-data.
413 ;; With code-locations whose type is :UNKNOWN-RETURN, there are
414 ;; really two breakpoints: one at the multiple-value entry point,
415 ;; and one at the single-value entry point. This slot holds the
416 ;; breakpoint for the other one, or NIL if this isn't at an
417 ;; :UNKNOWN-RETURN code location.
419 ;; :FUN-END breakpoints use a breakpoint at the :FUN-START
420 ;; to establish the end breakpoint upon function entry. We do this
421 ;; by frobbing the LRA to jump to a special piece of code that
422 ;; breaks and provides the return values for the returnee. This slot
423 ;; points to the start breakpoint, so we can activate, deactivate,
424 ;; and delete it.
426 ;; This is a hook users supply to get a dynamically unique cookie
427 ;; for identifying :FUN-END breakpoint executions. That is, if
428 ;; there is one :FUN-END breakpoint, but there may be multiple
429 ;; pending calls of its function on the stack. This function takes
430 ;; the cookie, and the hook function takes the cookie too.
432 ;; This slot users can set with whatever information they find useful.
433 %info)
438 "~S~:[~;~:*~S~]"
448 (:constructor %make-compiled-debug-fun
451 ;; compiler's dumped DEBUG-FUN information (unexported)
453 ;; code object (unexported).
454 component
455 ;; the :FUN-START breakpoint (if any) used to facilitate
456 ;; function end breakpoints
458 \f
459 ;;;; CODE-LOCATIONs
464 str)))
468 (:constructor make-known-code-location
473 ;; an index into DEBUG-FUN's component slot
475 ;; a bit-vector indexed by a variable's position in
476 ;; DEBUG-FUN-DEBUG-VARS indicating whether the variable has a
477 ;; valid value at this code-location. (unexported).
479 ;; (unexported) To see SB!C::LOCATION-KIND, do
480 ;; (SB!KERNEL:TYPEXPAND 'SB!C::LOCATION-KIND).
483 \f
484 ;;;; frames
486 ;;; This is used in FIND-ESCAPED-FRAME and with the bogus components
487 ;;; and LRAs used for :FUN-END breakpoints. When a component's
488 ;;; debug-info slot is :BOGUS-LRA, then the REAL-LRA-SLOT contains the
489 ;;; real component to continue executing, as opposed to the bogus
490 ;;; component which appeared in some frame's LRA location.
492 ;; X86 stores a fixup vector at the first constant slot
496 ;;; These are magically converted by the compiler.
513 #!+stack-grows-downward-not-upward
516 #!-stack-grows-downward-not-upward
521 #!+stack-grows-downward-not-upward
541 ;;;; (OR X86 X86-64) support
552 code-header-len)))
553 ;;(format t "c-lra-fpc ~A ~A ~A~%" pc code pc-offset)
561 ;;; Check for a valid return address - it could be any valid C/Lisp
562 ;;; address.
563 ;;;
564 ;;; XXX Could be a little smarter.
569 ;; not the first page (which is unmapped)
570 ;;
571 ;; FIXME: Where is this documented? Is it really true of every CPU
572 ;; architecture? Is it even necessarily true in current SBCL?
574 ;; not a Lisp stack pointer
577 ;;; Try to find a valid previous stack. This is complex on the x86 as
578 ;;; it can jump between C and Lisp frames. To help find a valid frame
579 ;;; it searches backwards.
580 ;;;
581 ;;; XXX Should probably check whether it has reached the bottom of the
582 ;;; stack.
583 ;;;
584 ;;; XXX Should handle interrupted frames, both Lisp and C. At present
585 ;;; it manages to find a fp trail, see linux hack below.
599 \f
600 ;;; Return the top frame of the control stack as it was before calling
601 ;;; this function.
606 nil))
608 ;;; Flush all of the frames above FRAME, and renumber all the frames
609 ;;; below FRAME.
623 ;;; Return the frame immediately below FRAME on the stack; or when
624 ;;; FRAME is the bottom of the stack, return NIL.
627 ;; We have to access the old-fp and return-pc out of frame and pass
628 ;; them to COMPUTE-CALLING-FRAME.
638 debug-fun)))
642 frame ocfp-save-offset
643 #!-fp-and-pc-standard-save
645 #!+fp-and-pc-standard-save
648 frame lra-save-offset
649 #!-fp-and-pc-standard-save
651 #!+fp-and-pc-standard-save
653 frame)))
664 #!-alpha
667 #!+alpha
674 frame)))))))
675 down)))
677 ;;; Get the old FP or return PC out of FRAME. STACK-SLOT is the
678 ;;; standard save location offset on the stack. LOC is the saved
679 ;;; SC-OFFSET describing the main location.
691 (#.ocfp-save-offset
693 (#.lra-save-offset
707 (#.ocfp-save-offset
709 (#.lra-save-offset
711 value))))))
719 ;;; This returns a frame for the one existing in time immediately
720 ;;; prior to the frame referenced by current-fp. This is current-fp's
721 ;;; caller or the next frame down the control stack. If there is no
722 ;;; down frame, this returns NIL for the bottom of the stack. UP-FRAME
723 ;;; is the up link for the resulting frame object, and it is null when
724 ;;; we call this to get the top of the stack.
725 ;;;
726 ;;; The current frame contains the pointer to the temporally previous
727 ;;; frame we want, and the current frame contains the pc at which we
728 ;;; will continue executing upon returning to that previous frame.
729 ;;;
730 ;;; Note: Sometimes LRA is actually a fixnum. This happens when lisp
731 ;;; calls into C. In this case, the code object is stored on the stack
732 ;;; after the LRA, and the LRA is the word offset.
753 nil)
755 0
756 nil)))
763 (:undefined-function
766 (:foreign-function
778 escaped)
780 escaped))))))
788 ;; First check for an escaped frame.
793 ;; If it's escaped it may be a function end breakpoint trap.
796 ;; If :bogus-lra grab the real lra.
808 (:undefined-function
811 (:foreign-function
822 escaped)
824 ;; If we have an interrupt-context that's not on
825 ;; our stack at all, and we're computing the
826 ;; from from a saved FP, we're probably looking
827 ;; at an interrupted syscall.
836 #!-alpha n
840 ;;; On SB-DYNAMIC-CORE symbols which come from the runtime go through
841 ;;; an indirection table, but the debugger needs to know the actual
842 ;;; address.
844 #!+sb-dynamic-core
846 #!-sb-dynamic-core
849 ;;;; See above.
872 ;; KLUDGE: Detect undefined functions by a range-check
873 ;; against the trampoline address and the following
874 ;; function in the runtime.
887 code-header-len)))
890 ;; We were in an assembly routine. Therefore, use the
891 ;; LRA as the pc.
892 ;;
893 ;; FIXME: Should this be WARN or ERROR or what?
895 pc-offset code))
922 code-header-len)))
925 ;; We were in an assembly routine.
931 "Set PC-OFFSET to zero and continue backtrace."
932 'bug
933 :format-control
934 "~@<PC-OFFSET (~D) not in code object. Frame details:~
935 ~2I~:@_PC: #X~X~:@_CODE: ~S~:@_CODE FUN: ~S~:@_LRA: ~
936 #X~X~:@_COMPUTED RETURN: #X~X.~:>"
937 :format-arguments
940 code
946 computed-return))
947 ;; We failed to pinpoint where PC is, but set
948 ;; pc-offset to 0 to keep the backtrace from
949 ;; exploding.
955 real-lra-slot)))
958 nil))
963 "Finds the PC for the return from an assembly routine properly.
964 For some architectures (such as PPC) this will not be the $LRA
965 register."
971 code-header-len)
972 return-machine-address)))
974 ;;; Find the code object corresponding to the object represented by
975 ;;; bits and return it. We assume bogus functions correspond to the
976 ;;; undefined-function.
988 object)
992 nil))))))))
993 \f
994 ;;;; frame utilities
1008 min-name))
1010 ;;; This returns a COMPILED-DEBUG-FUN for COMPONENT and PC. We fetch the
1011 ;;; SB!C::DEBUG-INFO and run down its FUN-MAP to get a
1012 ;;; SB!C::COMPILED-DEBUG-FUN from the PC. The result only needs to
1013 ;;; reference the COMPONENT, for function constants, and the
1014 ;;; SB!C::COMPILED-DEBUG-FUN.
1042 ;; Non-escaped frame means that this frame calls something.
1043 ;; And the PC points to where something should return.
1044 ;; The return adress may be in the next
1045 ;; function, e.g. in local tail calls the
1046 ;; function will be entered just after the
1047 ;; CALL.
1048 ;; See debug.impure.lisp/:local-tail-call for a test-case
1052 component)))
1055 ;;; This returns a code-location for the COMPILED-DEBUG-FUN,
1056 ;;; DEBUG-FUN, and the pc into its code vector. If we stopped at a
1057 ;;; breakpoint, find the CODE-LOCATION for that breakpoint. Otherwise,
1058 ;;; make an :UNSURE code location, so it can be filled in when we
1059 ;;; figure out what is going on.
1062 escaped
1065 pc nil)))
1070 what)))))
1073 ;;; Return an alist mapping catch tags to CODE-LOCATIONs. These are
1074 ;;; CODE-LOCATIONs at which execution would continue with frame as the
1075 ;;; top frame if someone threw to the corresponding tag.
1082 do
1084 #!-alpha
1088 #!+alpha
1123 reversed-result)))
1125 #!-alpha
1129 #!+alpha
1135 ;;; Modify the value of the OLD-TAG catches in FRAME to NEW-TAG
1141 #!-alpha
1145 #!+alpha
1165 #!-alpha
1169 #!+alpha
1176 \f
1177 ;;;; operations on DEBUG-FUNs
1179 ;;; Execute the forms in a context with BLOCK-VAR bound to each
1180 ;;; DEBUG-BLOCK in DEBUG-FUN successively. Result is an optional
1181 ;;; form to execute for return values, and DO-DEBUG-FUN-BLOCKS
1182 ;;; returns nil if there is no result form. This signals a
1183 ;;; NO-DEBUG-BLOCKS condition when the DEBUG-FUN lacks
1184 ;;; DEBUG-BLOCK information.
1195 ;;; Execute body in a context with VAR bound to each DEBUG-VAR in
1196 ;;; DEBUG-FUN. This returns the value of executing result (defaults to
1197 ;;; nil). This may iterate over only some of DEBUG-FUN's variables or
1198 ;;; none depending on debug policy; for example, possibly the
1199 ;;; compilation only preserved argument information.
1211 ;;; Return the object of type FUNCTION associated with the DEBUG-FUN,
1212 ;;; or NIL if the function is unavailable or is non-existent as a user
1213 ;;; callable function object.
1234 cached-value)))
1236 ;;; Return the name of the function represented by DEBUG-FUN. This may
1237 ;;; be a string or a cons; do not assume it is a symbol.
1244 ;; Frames named (.EVAL. special-operator) should show the operator name
1245 ;; in backtraces, but if the debugger needs to detect that the frame is
1246 ;; interpreted for other purposes, it can specify PRETTY = NIL.
1249 pretty)
1270 ;; Return the name of the closure, if named, otherwise nil.
1276 ;; Frames named (.APPLY. something) are interpreted function applicators.
1277 ;; Show them as the name of the interpreted function being applied.
1278 #!+sb-fasteval
1281 ;; Find a variable named FUN.
1289 #!+precise-arg-count-error
1295 #!-precise-arg-count-error
1298 ;; The logic in CLEAN-FRAME-CALL is based on the frame name,
1299 ;; so if the simple-fun is named (XEP mumble) then the closure
1300 ;; needs to pretend to be named similarly.
1306 closure-name))))))))
1308 ;;; Return a DEBUG-FUN that represents debug information for FUN.
1323 ;; KLUDGE: comment from CMU CL:
1324 ;; This used to be the non-interpreted branch, but
1325 ;; William wrote it to return the debug-fun of fun's XEP
1326 ;; instead of fun's debug-fun. The above code does this
1327 ;; more correctly, but it doesn't get or eliminate all
1328 ;; appropriate cases. It mostly works, and probably
1329 ;; works for all named functions anyway.
1330 ;; -- WHN 20000120
1336 ;;; Return the kind of the function, which is one of :OPTIONAL,
1337 ;;; :EXTERNAL, :TOPLEVEL, :CLEANUP, or NIL.
1339 ;; FIXME: This "is one of" information should become part of the function
1340 ;; declamation, not just a doc string
1346 nil)))
1348 ;;; Is there any variable information for DEBUG-FUN?
1352 ;;; Return a list of DEBUG-VARs in DEBUG-FUN having the same name
1353 ;;; and package as SYMBOL. If SYMBOL is uninterned, then this returns
1354 ;;; a list of DEBUG-VARs without package names and with the same name
1355 ;;; as symbol. The result of this function is limited to the
1356 ;;; availability of variable information in DEBUG-FUN; for
1357 ;;; example, possibly DEBUG-FUN only knows about its arguments.
1369 vars)))
1371 ;;; Return a list of DEBUG-VARs in DEBUG-FUN whose names contain
1372 ;;; NAME-PREFIX-STRING as an initial substring. The result of this
1373 ;;; function is limited to the availability of variable information in
1374 ;;; debug-fun; for example, possibly debug-fun only knows
1375 ;;; about its arguments.
1386 ;; Find names from pos to variable's len that contain prefix.
1395 prefix-len)
1396 prefix-len)
1400 res))))
1402 ;;; This returns a position in VARIABLES for one containing NAME as an
1403 ;;; initial substring. END is the length of VARIABLES if supplied.
1417 ;;; Return a list representing the lambda-list for DEBUG-FUN. The
1418 ;;; list has the following structure:
1419 ;;; (required-var1 required-var2
1420 ;;; ...
1421 ;;; (:optional var3 suppliedp-var4)
1422 ;;; (:optional var5)
1423 ;;; ...
1424 ;;; (:rest var6) (:rest var7)
1425 ;;; ...
1426 ;;; (:keyword keyword-symbol var8 suppliedp-var9)
1427 ;;; (:keyword keyword-symbol var10)
1428 ;;; ...
1429 ;;; )
1430 ;;; Each VARi is a DEBUG-VAR; however it may be the symbol :DELETED if
1431 ;;; it is unreferenced in DEBUG-FUN. This signals a
1432 ;;; LAMBDA-LIST-UNAVAILABLE condition when there is no argument list
1433 ;;; information.
1439 ;;; Note: If this has to compute the lambda list, it caches it in DEBUG-FUN.
1447 args
1452 nil)
1455 ;; If the packed information is there (whether empty or not) as
1456 ;; opposed to being nil, then returned our cached value (nil).
1457 nil)
1459 ;; Our cached value is nil, and the packed lambda-list information
1460 ;; is nil, so we don't have anything available.
1464 ;;; COMPILED-DEBUG-FUN-LAMBDA-LIST calls this when a
1465 ;;; COMPILED-DEBUG-FUN has no lambda list information cached. It
1466 ;;; returns the lambda list as the first value and whether there was
1467 ;;; any argument information as the second value. Therefore,
1468 ;;; (VALUES NIL T) means there were no arguments, but (VALUES NIL NIL)
1469 ;;; means there was no argument information.
1478 t))
1482 t)))))
1497 tag-and-info)
1498 result))
1501 :deleted
1511 ;; The next two args are the &MORE arg context and
1512 ;; count.
1515 ;; SUPPLIED-P var immediately following keyword or
1516 ;; optional. Stick the extra var in the result element
1517 ;; representing the keyword or optional, which is the
1518 ;; previous one.
1521 ;; The keyword of a keyword parameter. Store it so the next
1522 ;; element can be used to form a (:keyword KEYWORD VALUE)
1523 ;; entry.
1526 ;; The previous element was the keyword of a keyword
1527 ;; parameter and is stored in KEYWORD. The current element
1528 ;; is the index of the value (or a deleted
1529 ;; marker). Construct and push the complete entry.
1532 ;; We saw an optional marker, so the following non-symbols
1533 ;; are indexes (or deleted markers) indicating optional
1534 ;; variables.
1537 ;; Deleted required, optional or keyword argument.
1540 ;; Required arg at beginning of args array.
1546 ;;; This is used in COMPILED-DEBUG-FUN-LAMBDA-LIST.
1557 \f
1558 ;;;; unpacking variable and basic block data
1564 ;;; PARSE-DEBUG-BLOCKS and PARSE-DEBUG-VARS
1565 ;;; use this to unpack binary encoded information. It returns the
1566 ;;; values returned by the last form in body.
1567 ;;;
1568 ;;; This binds buffer-var to *parsing-buffer*, makes sure it starts at
1569 ;;; element zero, and makes sure if we unwind, we nil out any set
1570 ;;; elements for GC purposes.
1571 ;;;
1572 ;;; This also binds other-var to *other-parsing-buffer* when it is
1573 ;;; supplied, making sure it starts at element zero and that we nil
1574 ;;; out any elements if we unwind.
1575 ;;;
1576 ;;; This defines the local macro RESULT that takes a buffer, copies
1577 ;;; its elements to a resulting simple-vector, nil's out elements, and
1578 ;;; restarts the buffer at element zero. RESULT returns the
1579 ;;; simple-vector.
1602 ;;; The argument is a debug internals structure. This returns the
1603 ;;; DEBUG-BLOCKs for DEBUG-FUN, regardless of whether we have unpacked
1604 ;;; them yet. It signals a NO-DEBUG-BLOCKS condition if it can't
1605 ;;; return the blocks.
1620 ;;; Return a SIMPLE-VECTOR of DEBUG-BLOCKs or NIL. NIL indicates there
1621 ;;; was no basic block information.
1629 ;;; This does some of the work of PARSE-DEBUG-BLOCKS.
1633 debug-fun))
1635 ;; KLUDGE: 8 is a hard-wired constant in the compiler for the
1636 ;; element size of the packed binary representation of the
1637 ;; blocks data.
1660 live-set-len blocks i))
1663 pc debug-fun block tlf-offset
1664 form-number live-set kind
1665 step-info)
1666 locations-buffer)
1675 ;;; The argument is a debug internals structure. This returns NIL if
1676 ;;; there is no variable information. It returns an empty
1677 ;;; simple-vector if there were no locals in the function. Otherwise
1678 ;;; it returns a SIMPLE-VECTOR of DEBUG-VARs.
1687 vars)))
1689 ;;; VARS is the parsed variables for a minimal debug function. We need
1690 ;;; to assign names of the form ARG-NNN. We must pad with leading
1691 ;;; zeros, since the arguments must be in alphabetical order.
1700 ;; The cross-compiler won't dump literal package
1701 ;; references because the target package objects
1702 ;; aren't created until partway through
1703 ;; cold-init. In lieu of adding smarts to the
1704 ;; build framework to handle this, we use an
1705 ;; explicit load-time-value form.
1708 ;;; Parse the packed representation of DEBUG-VARs from
1709 ;;; DEBUG-FUN's SB!C::COMPILED-DEBUG-FUN, returning a vector
1710 ;;; of DEBUG-VARs, or NIL if there was no information to parse.
1713 debug-fun))
1724 result))
1733 flags))
1749 id
1750 live
1751 sc-offset
1752 save-sc-offset
1753 indirect-sc-offset
1756 buffer)))))))
1757 \f
1758 ;;;; CODE-LOCATIONs
1760 ;;; If we're sure of whether code-location is known, return T or NIL.
1761 ;;; If we're :UNSURE, then try to fill in the code-location's slots.
1762 ;;; This determines whether there is any debug-block information, and
1763 ;;; if code-location is known.
1764 ;;;
1765 ;;; ??? IF this conses closures every time it's called, then break off the
1766 ;;; :UNSURE part to get the HANDLER-CASE into another function.
1771 (:unsure
1776 ;;; Return the DEBUG-BLOCK containing code-location if it is available.
1777 ;;; Some debug policies inhibit debug-block information, and if none
1778 ;;; is available, then this signals a NO-DEBUG-BLOCKS condition.
1785 ;; (There used to be more cases back before sbcl-0.7.0, when
1786 ;; we did special tricks to debug the IR1 interpreter.)
1787 )
1788 block)))
1790 ;;; Store and return BASIC-CODE-LOCATION's debug-block. We determines
1791 ;;; the correct one using the code-location's pc. We use
1792 ;;; DEBUG-FUN-DEBUG-BLOCKS to return the cached block information
1793 ;;; or signal a NO-DEBUG-BLOCKS condition. The blocks are sorted by
1794 ;;; their first code-location's pc, in ascending order. Therefore, as
1795 ;;; soon as we find a block that starts with a pc greater than
1796 ;;; basic-code-location's pc, we know the previous block contains the
1797 ;;; pc. If we get to the last block, then the code-location is either
1798 ;;; in the second to last block or the last block, and we have to be
1799 ;;; careful in determining this since the last block could be code at
1800 ;;; the end of the function. We have to check for the last block being
1801 ;;; code first in order to see how to compare the code-location's pc.
1805 basic-code-location))
1821 debug-fun)))
1823 last))
1824 ((< pc
1838 ;;; Return the CODE-LOCATION's DEBUG-SOURCE.
1846 ;;; Returns the number of top level forms before the one containing
1847 ;;; CODE-LOCATION as seen by the compiler in some compilation unit. (A
1848 ;;; compilation unit is not necessarily a single file, see the section
1849 ;;; on debug-sources.)
1858 ;; This check should be unnecessary. We're missing
1859 ;; debug info the compiler should have dumped.
1862 ;; (There used to be more cases back before sbcl-0.7.0,,
1863 ;; when we did special tricks to debug the IR1
1864 ;; interpreter.)
1865 ))
1868 ;;; Return the number of the form corresponding to CODE-LOCATION. The
1869 ;;; form number is derived by a walking the subforms of a top level
1870 ;;; form in depth-first order.
1879 ;; This check should be unnecessary. We're missing
1880 ;; debug info the compiler should have dumped.
1883 ;; (There used to be more cases back before sbcl-0.7.0,,
1884 ;; when we did special tricks to debug the IR1
1885 ;; interpreter.)
1886 ))
1889 ;;; Return the kind of CODE-LOCATION, one of:
1890 ;;; :INTERPRETED, :UNKNOWN-RETURN, :KNOWN-RETURN, :INTERNAL-ERROR,
1891 ;;; :NON-LOCAL-EXIT, :BLOCK-START, :CALL-SITE, :SINGLE-VALUE-RETURN,
1892 ;;; :NON-LOCAL-ENTRY
1901 ;; This check should be unnecessary. We're missing
1902 ;; debug info the compiler should have dumped.
1906 ;; (There used to be more cases back before sbcl-0.7.0,,
1907 ;; when we did special tricks to debug the IR1
1908 ;; interpreter.)
1909 ))
1911 ;;; This returns CODE-LOCATION's live-set if it is available. If
1912 ;;; there is no debug-block information, this returns NIL.
1915 nil
1919 ;; This check should be unnecessary. We're missing
1920 ;; debug info the compiler should have dumped.
1921 ;;
1922 ;; FIXME: This error and comment happen over and over again.
1923 ;; Make them a shared function.
1928 ;;; true if OBJ1 and OBJ2 are the same place in the code
1937 ;; (There used to be more cases back before sbcl-0.7.0,,
1938 ;; when we did special tricks to debug the IR1
1939 ;; interpreter.)
1940 ))
1941 ;; (There used to be more cases back before sbcl-0.7.0,,
1942 ;; when we did special tricks to debug IR1-interpreted code.)
1943 ))
1948 ;;; Fill in CODE-LOCATION's :UNPARSED slots, returning T or NIL
1949 ;;; depending on whether the code-location was known in its
1950 ;;; DEBUG-FUN's debug-block information. This may signal a
1951 ;;; NO-DEBUG-BLOCKS condition due to DEBUG-FUN-DEBUG-BLOCKS, and
1952 ;;; it assumes the %UNKNOWN-P slot is already set or going to be set.
1977 \f
1978 ;;;; operations on DEBUG-BLOCKs
1980 ;;; Execute FORMS in a context with CODE-VAR bound to each
1981 ;;; CODE-LOCATION in DEBUG-BLOCK, and return the value of RESULT.
1992 ;;; Return the name of the function represented by DEBUG-FUN.
1993 ;;; This may be a string or a cons; do not assume it is a symbol.
2000 "??? Can't get name of debug-block's function."
2003 ;; (There used to be more cases back before sbcl-0.7.0, when we
2004 ;; did special tricks to debug the IR1 interpreter.)
2005 ))
2011 ;; (There used to be more cases back before sbcl-0.7.0, when we
2012 ;; did special tricks to debug the IR1 interpreter.)
2013 ))
2014 \f
2015 ;;;; operations on debug variables
2020 ;;; FIXME: Make sure that this isn't called anywhere that it wouldn't
2021 ;;; be acceptable to have NIL returned, or that it's only called on
2022 ;;; DEBUG-VARs whose symbols have non-NIL packages.
2026 ;;; Return the value stored for DEBUG-VAR in frame, or if the value is
2027 ;;; not :VALID, then signal an INVALID-VALUE error.
2034 ;;; Returns the value stored for DEBUG-VAR in frame. The value may be
2035 ;;; invalid. This is SETFable.
2041 res)))
2043 ;;; This returns what is stored for the variable represented by
2044 ;;; DEBUG-VAR relative to the FRAME. This may be an indirect value
2045 ;;; cell if the variable is both closed over and set.
2050 ;; Indirect are accessed through a frame pointer of the parent.
2059 escaped))
2061 escaped))
2066 escaped))
2073 ;;; a helper function for working with possibly-invalid values:
2074 ;;; Do (%MAKE-LISP-OBJ VAL) only if the value looks valid.
2075 ;;;
2076 ;;; (Such values can arise in registers on machines with conservative
2077 ;;; GC, and might also arise in debug variable locations when
2078 ;;; those variables are invalid.)
2079 ;;;
2080 ;;; NOTE: this function is not GC-safe in the slightest when creating
2081 ;;; a pointer to an object in dynamic space. If a GC occurs between
2082 ;;; the start of the call to VALID-LISP-POINTER-P and the end of
2083 ;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
2084 ;;; is constructed. This can happen on CHENEYGC if an asynchronous
2085 ;;; interrupt occurs within the window. This can happen on GENCGC
2086 ;;; under the same circumstances, but is more likely due to all GENCGC
2087 ;;; platforms supporting threaded operation. This is somewhat
2088 ;;; mitigated on x86oids due to the conservative stack and interrupt
2089 ;;; context "scavenging" on such platforms, but there still may be a
2090 ;;; vulnerable window.
2098 x))
2100 ;; fixnum
2102 ;; immediate single float, 64-bit only
2105 ;; character
2108 ;; unbound marker
2110 ;; undefined_tramp doesn't validate properly as a pointer, and
2111 ;; the actual value can vary by backend (x86oids need not apply)
2116 ;; pointer
2123 nil)))))
2126 ;; NOTE: The long-float support in here is obviously decayed. When
2127 ;; the x86oid and non-x86oid versions of this function were unified,
2128 ;; the behavior of long-floats was preserved, which only served to
2129 ;; highlight its brokenness.
2133 escaped
2140 escaped
2144 ;; x86oids have no separate number stack, so dummy it
2145 ;; up for them.
2146 #!+c-stack-is-control-stack
2149 #!-c-stack-is-control-stack
2154 #!-alpha
2157 #!+alpha
2185 val)))
2188 val))
2199 #!+long-float
2206 #!+long-float
2215 #!+long-float
2229 #!+long-float
2251 (#.constant-sc-number
2260 ;;; This stores value as the value of DEBUG-VAR in FRAME. In the
2261 ;;; COMPILED-DEBUG-VAR case, access the current value to determine if
2262 ;;; it is an indirect value cell. This occurs when the variable is
2263 ;;; both closed over and set.
2270 new-value)
2272 ;;; This stores VALUE for the variable represented by debug-var
2273 ;;; relative to the frame. This assumes the location directly contains
2274 ;;; the variable's value; that is, there is no indirect value cell
2275 ;;; currently there in case the variable is both closed over and set.
2281 value escaped)
2286 value))))
2289 ;; Like sub-access-debug-var-slot, this is the unification of two
2290 ;; divergent copy-pasted functions. The astute reviewer will notice
2291 ;; that long-floats are messed up here as well, that x86oids
2292 ;; apparently don't support accessing float values that are in
2293 ;; registers, and that non-x86oids store the real part of a float
2294 ;; for both the real and imaginary parts of a complex on the stack
2295 ;; (but not in registers, oddly enough). Some research has
2296 ;; indicated that the different forms of THE used for validating the
2297 ;; type of complex float components between x86oid and non-x86oid
2298 ;; systems are only significant in the case of using a non-complex
2299 ;; number as input (as the non-x86oid case effectively converts
2300 ;; non-complex numbers to complex ones and the x86oid case will
2301 ;; error out). That said, the error message from entering a value
2302 ;; of the wrong type will be slightly easier to understand on x86oid
2303 ;; systems.
2307 escaped
2310 value))
2314 escaped
2318 value))
2320 ;; x86oids have no separate number stack, so dummy it
2321 ;; up for them.
2330 #!-alpha
2332 (* nfp-save-offset
2334 #!+alpha
2337 (* nfp-save-offset
2372 #!+long-float
2379 #!+long-float
2390 #!+long-float
2419 #!+long-float
2453 ;;; The method for setting and accessing COMPILED-DEBUG-VAR values use
2454 ;;; this to determine if the value stored is the actual value or an
2455 ;;; indirection cell.
2460 ;;; Return three values reflecting the validity of DEBUG-VAR's value
2461 ;;; at BASIC-CODE-LOCATION:
2462 ;;; :VALID The value is known to be available.
2463 ;;; :INVALID The value is known to be unavailable.
2464 ;;; :UNKNOWN The value's availability is unknown.
2465 ;;;
2466 ;;; If the variable is always alive, then it is valid. If the
2467 ;;; code-location is unknown, then the variable's validity is
2468 ;;; :unknown. Once we've called CODE-LOCATION-UNKNOWN-P, we know the
2469 ;;; live-set information has been cached in the code-location.
2476 ;;; This is the method for DEBUG-VAR-VALIDITY for COMPILED-DEBUG-VARs.
2477 ;;; For safety, make sure basic-code-location is what we think.
2485 :valid
2492 basic-code-location)))))
2495 :debug-var debug-var
2496 :debug-fun
2498 ;; There must be live-set info since basic-code-location is known.
2500 basic-code-location)
2501 pos))
2502 :invalid
2504 \f
2505 ;;;; sources
2507 ;;; This code produces and uses what we call source-paths. A
2508 ;;; source-path is a list whose first element is a form number as
2509 ;;; returned by CODE-LOCATION-FORM-NUMBER and whose last element is a
2510 ;;; top level form number as returned by
2511 ;;; CODE-LOCATION-TOPLEVEL-FORM-NUMBER. The elements from the last to
2512 ;;; the first, exclusively, are the numbered subforms into which to
2513 ;;; descend. For example:
2514 ;;; (defun foo (x)
2515 ;;; (let ((a (aref x 3)))
2516 ;;; (cons a 3)))
2517 ;;; The call to AREF in this example is form number 5. Assuming this
2518 ;;; DEFUN is the 11'th top level form, the source-path for the AREF
2519 ;;; call is as follows:
2520 ;;; (5 1 0 1 3 11)
2521 ;;; Given the DEFUN, 3 gets you the LET, 1 gets you the bindings, 0
2522 ;;; gets the first binding, and 1 gets the AREF form.
2524 ;;; This returns a table mapping form numbers to source-paths. A
2525 ;;; source-path indicates a descent into the TOPLEVEL-FORM form,
2526 ;;; going directly to the subform corressponding to the form number.
2527 ;;;
2528 ;;; The vector elements are in the same format as the compiler's
2529 ;;; NODE-SOURCE-PATH; that is, the first element is the form number and
2530 ;;; the last is the TOPLEVEL-FORM number.
2531 ;;;
2532 ;;; This should be synchronized with SB-C::SUB-FIND-SOURCE-PATHS
2540 translations)
2554 ;; Don't look into quoted constants.
2566 ;;; FORM is a top level form, and path is a source-path into it. This
2567 ;;; returns the form indicated by the source-path. Context is the
2568 ;;; number of enclosing forms to return instead of directly returning
2569 ;;; the source-path form. When context is non-zero, the form returned
2570 ;;; contains a marker, #:****HERE****, immediately before the form
2571 ;;; indicated by path.
2574 ;; Get to the form indicated by path or the enclosing form indicated
2575 ;; by context and path.
2583 ;; Recursively rebuild the source form resulting from the above
2584 ;; descent, copying the beginning of each subform up to the next
2585 ;; subform we descend into according to path. At the bottom of the
2586 ;; recursion, we return the form indicated by path preceded by our
2587 ;; marker, and this gets spliced into the resulting list structure
2588 ;; on the way back up.
2592 form
2602 ;;; Given a code location, return the associated form-number
2603 ;;; translations and the actual top level form.
2616 ;;; To suppress the read-time evaluation #. macro during source read,
2617 ;;; *READTABLE* is modified.
2618 ;;;
2619 ;;; FIXME: This breaks #+#.(cl:if ...) Maybe we need a SAFE-READ-EVAL, which
2620 ;;; this code can use for side- effect free #. calls?
2621 ;;;
2622 ;;; FIXME: This also knows nothing of custom readtables. The assumption
2623 ;;; is that the current readtable is a decent approximation for what
2624 ;;; we want, but that's lossy.
2632 rt)
2633 rt))
2635 ;;; Locate the source file (if it still exists) and grab the top level
2636 ;;; form. If the file is modified, we use the top level form offset
2637 ;;; instead of the recorded character offset.
2644 tlf-offset))
2646 ;; FIXME: External format?
2654 "~%; File has been modified since compilation:~%; ~A~@
2655 ; Using form offset instead of character position.~%"
2656 namestring)
2661 \f
2662 ;;;; PREPROCESS-FOR-EVAL
2664 ;;; Return a function of one argument that evaluates form in the
2665 ;;; lexical context of the BASIC-CODE-LOCATION LOC, or signal a
2666 ;;; NO-DEBUG-VARS condition when the LOC's DEBUG-FUN has no
2667 ;;; DEBUG-VAR information available.
2668 ;;;
2669 ;;; The returned function takes the frame to get values from as its
2670 ;;; argument, and it returns the values of FORM. The returned function
2671 ;;; can signal the following conditions: INVALID-VALUE,
2672 ;;; AMBIGUOUS-VAR-NAME, and FRAME-FUN-MISMATCH.
2687 (:more-context
2689 (:more-count
2706 (:valid
2708 (:more
2712 0
2714 (:unknown
2718 (:ambiguous
2727 ;; This prevents these functions from being used in any
2728 ;; location other than a function return location, so maybe
2729 ;; this should only check whether FRAME's DEBUG-FUN is the
2730 ;; same as LOC's.
2736 ;;; EVAL-IN-FRAME
2740 #!+sb-doc
2741 "Evaluate FORM in the lexical context of FRAME's current code location,
2742 returning the results of the evaluation."
2744 \f
2745 ;;;; breakpoints
2747 ;;;; user-visible interface
2749 ;;; Create and return a breakpoint. When program execution encounters
2750 ;;; the breakpoint, the system calls HOOK-FUN. HOOK-FUN takes the
2751 ;;; current frame for the function in which the program is running and
2752 ;;; the breakpoint object.
2753 ;;;
2754 ;;; WHAT and KIND determine where in a function the system invokes
2755 ;;; HOOK-FUN. WHAT is either a code-location or a DEBUG-FUN. KIND is
2756 ;;; one of :CODE-LOCATION, :FUN-START, or :FUN-END. Since the starts
2757 ;;; and ends of functions may not have code-locations representing
2758 ;;; them, designate these places by supplying WHAT as a DEBUG-FUN and
2759 ;;; KIND indicating the :FUN-START or :FUN-END. When WHAT is a
2760 ;;; DEBUG-FUN and kind is :FUN-END, then HOOK-FUN must take two
2761 ;;; additional arguments, a list of values returned by the function
2762 ;;; and a FUN-END-COOKIE.
2763 ;;;
2764 ;;; INFO is information supplied by and used by the user.
2765 ;;;
2766 ;;; FUN-END-COOKIE is a function. To implement :FUN-END
2767 ;;; breakpoints, the system uses starter breakpoints to establish the
2768 ;;; :FUN-END breakpoint for each invocation of the function. Upon
2769 ;;; each entry, the system creates a unique cookie to identify the
2770 ;;; invocation, and when the user supplies a function for this
2771 ;;; argument, the system invokes it on the frame and the cookie. The
2772 ;;; system later invokes the :FUN-END breakpoint hook on the same
2773 ;;; cookie. The user may save the cookie for comparison in the hook
2774 ;;; function.
2775 ;;;
2776 ;;; Signal an error if WHAT is an unknown code-location.
2783 what))
2788 ;; This slot is filled in due to calling CODE-LOCATION-UNKNOWN-P.
2791 :unknown-return-partner
2792 info)))
2795 ;; (There used to be more cases back before sbcl-0.7.0,,
2796 ;; when we did special tricks to debug the IR1
2797 ;; interpreter.)
2798 )
2799 bpt))
2802 (:fun-start
2804 (:fun-end
2821 bpt))))))
2823 ;;; These are unique objects created upon entry into a function by a
2824 ;;; :FUN-END breakpoint's starter hook. These are only created
2825 ;;; when users supply :FUN-END-COOKIE to MAKE-BREAKPOINT. Also,
2826 ;;; the :FUN-END breakpoint's hook is called on the same cookie
2827 ;;; when it is created.
2833 ;; a pointer to the bogus-lra created for :FUN-END breakpoints
2834 bogus-lra
2835 ;; the DEBUG-FUN associated with this cookie
2836 debug-fun)
2838 ;;; This maps bogus-lra-components to cookies, so that
2839 ;;; HANDLE-FUN-END-BREAKPOINT can find the appropriate cookie for the
2840 ;;; breakpoint hook.
2843 ;;; This returns a hook function for the start helper breakpoint
2844 ;;; associated with a :FUN-END breakpoint. The returned function
2845 ;;; makes a fake LRA that all returns go through, and this piece of
2846 ;;; fake code actually breaks. Upon return from the break, the code
2847 ;;; provides the returnee with any values. Since the returned function
2848 ;;; effectively activates FUN-END-BPT on each entry to DEBUG-FUN's
2849 ;;; function, we must establish breakpoint-data about FUN-END-BPT.
2857 #!-fp-and-pc-standard-save
2860 #!+fp-and-pc-standard-save
2865 lra-save-offset
2866 lra-sc-offset))
2868 lra-save-offset
2869 lra-sc-offset)
2870 lra)
2882 ;;; This takes a FUN-END-COOKIE and a frame, and it returns
2883 ;;; whether the cookie is still valid. A cookie becomes invalid when
2884 ;;; the frame that established the cookie has exited. Sometimes cookie
2885 ;;; holders are unaware of cookie invalidation because their
2886 ;;; :FUN-END breakpoint hooks didn't run due to THROW'ing.
2887 ;;;
2888 ;;; This takes a frame as an efficiency hack since the user probably
2889 ;;; has a frame object in hand when using this routine, and it saves
2890 ;;; repeated parsing of the stack and consing when asking whether a
2891 ;;; series of cookies is valid.
2895 #!-fp-and-pc-standard-save
2899 #!+fp-and-pc-standard-save
2905 lra
2908 \f
2909 ;;;; ACTIVATE-BREAKPOINT
2911 ;;; Cause the system to invoke the breakpoint's hook function until
2912 ;;; the next call to DEACTIVATE-BREAKPOINT or DELETE-BREAKPOINT. The
2913 ;;; system invokes breakpoint hook functions in the opposite order
2914 ;;; that you activate them.
2920 (:code-location
2928 ;; (There used to be more cases back before sbcl-0.7.0, when
2929 ;; we did special tricks to debug the IR1 interpreter.)
2930 )))
2931 (:fun-start
2935 ;; (There used to be more cases back before sbcl-0.7.0, when
2936 ;; we did special tricks to debug the IR1 interpreter.)
2937 ))
2938 (:fun-end
2943 ;; may already be active by some other :FUN-END breakpoint
2946 ;; (There used to be more cases back before sbcl-0.7.0, when
2947 ;; we did special tricks to debug the IR1 interpreter.)
2948 ))))
2949 breakpoint)
2956 breakpoint
2971 breakpoint
2975 debug-fun))))))
2991 \f
2992 ;;;; DEACTIVATE-BREAKPOINT
2994 ;;; Stop the system from invoking the breakpoint's hook function.
3005 ;; (There used to be more cases back before sbcl-0.7.0, when
3006 ;; we did special tricks to debug the IR1 interpreter.)
3007 ))))
3008 breakpoint)
3030 breakpoint)
3031 \f
3032 ;;;; BREAKPOINT-INFO
3034 ;;; Return the user-maintained info associated with breakpoint. This
3035 ;;; is SETF'able.
3043 \f
3044 ;;;; BREAKPOINT-ACTIVE-P and DELETE-BREAKPOINT
3051 ;;; Free system storage and remove computational overhead associated
3052 ;;; with breakpoint. After calling this, breakpoint is completely
3053 ;;; impotent and can never become active again.
3072 nil))))))
3073 breakpoint)
3074 \f
3075 ;;;; C call out stubs
3077 ;;; This actually installs the break instruction in the component. It
3078 ;;; returns the overwritten bits. You must call this in a context in
3079 ;;; which GC is disabled, so that Lisp doesn't move objects around
3080 ;;; that C is pointing to.
3085 ;;; This removes the break instruction and replaces the original
3086 ;;; instruction. You must call this in a context in which GC is disabled
3087 ;;; so Lisp doesn't move objects around that C is pointing to.
3097 ;;;; breakpoint handlers (layer between C and exported interface)
3099 ;;; This maps components to a mapping of offsets to BREAKPOINT-DATAs.
3102 ;;; This returns the BREAKPOINT-DATA object associated with component cross
3103 ;;; offset. If none exists, this makes one, installs it, and returns it.
3110 data))))
3119 ;;; We use this when there are no longer any active breakpoints
3120 ;;; corresponding to DATA.
3122 ;; Again, this looks brittle. Is there no danger of being interrupted
3123 ;; here?
3133 ;;; The C handler for interrupts calls this when it has a
3134 ;;; debugging-tool break instruction. This does *not* handle all
3135 ;;; breaks; for example, it does not handle breaks for internal
3136 ;;; errors.
3142 offset))
3148 offset component signal-context)))))
3150 ;;; This holds breakpoint-datas while invoking the breakpoint hooks
3151 ;;; associated with that particular component and location. While they
3152 ;;; are executing, if we hit the location again, we ignore the
3153 ;;; breakpoint to avoid infinite recursion. fun-end breakpoints
3154 ;;; must work differently since the breakpoint-data is unique for each
3155 ;;; invocation.
3158 ;;; This handles code-location and DEBUG-FUN :FUN-START
3159 ;;; breakpoints.
3167 ;; At this point breakpoints may not hold the same list as
3168 ;; BREAKPOINT-DATA-BREAKPOINTS since invoking hooks may have allowed
3169 ;; a breakpoint deactivation. In fact, if all breakpoints were
3170 ;; deactivated then data is invalid since it was deleted and so the
3171 ;; correct one must be looked up if it is to be used. If there are
3172 ;; no more breakpoints active at this location, then the normal
3173 ;; instruction has been put back, and we do not need to
3174 ;; DO-DISPLACED-INST.
3177 ;; The breakpoint is still active, so we need to execute the
3178 ;; displaced instruction and leave the breakpoint instruction
3179 ;; behind. The best way to do this is different on each machine,
3180 ;; so we just leave it up to the C code.
3183 ;; Some platforms have no usable sigreturn() call. If your
3184 ;; implementation of arch_do_displaced_inst() _does_ sigreturn(),
3185 ;; it's polite to warn here
3193 frame
3194 ;; If this is an :UNKNOWN-RETURN-PARTNER, then pass the
3195 ;; hook function the original breakpoint, so that users
3196 ;; aren't forced to confront the fact that some
3197 ;; breakpoints really are two.
3200 bpt)))))
3209 ;; KLUDGE: This argument is ignored on
3210 ;; x86oids in this scenario, but is
3211 ;; declared to be a SAP.
3214 nil)))
3221 offset))
3227 ;;; Either HANDLE-BREAKPOINT calls this for :FUN-END breakpoints
3228 ;;; [old C code] or HANDLE-FUN-END-BREAKPOINT calls this directly
3229 ;;; [new C code].
3231 ;; FIXME: This looks brittle: what if we are interrupted somewhere
3232 ;; here? ...or do we have interrupts disabled here?
3244 frame bpt
3246 cookie))))
3250 scp
3264 results)))
3266 \f
3267 ;;;; MAKE-BOGUS-LRA (used for :FUN-END breakpoints)
3272 ;; One more for a fixup vector
3275 ;;; Make a bogus LRA object that signals a breakpoint trap when
3276 ;;; returned to. If the breakpoint trap handler returns, REAL-LRA is
3277 ;;; returned to. Three values are returned: the bogus LRA object, the
3278 ;;; code component it is part of, and the PC offset for the trap
3279 ;;; instruction.
3282 ;; These are really code labels, not variables: but this way we get
3283 ;; their addresses.
3292 src-start src-end dst-start trap-loc)
3297 ;; Set up the widetag and header of LRA
3298 ;; The header contains the same thing as the code object header,
3299 ;; the number of boxed words, which include slots and
3300 ;; constants and it has to be double word aligned.
3301 ;;
3302 ;; It used to be a part of the fun_end_breakpoint_guts
3303 ;; but its position and value depend on the offsets
3304 ;; and alignment of code object slots.
3308 bogus-lra-constants
3323 ;; We used to set the header value of the LRA here to the
3324 ;; offset from the enclosing component to the LRA header, but
3325 ;; MAKE-LISP-OBJ actually checks the value before we get a
3326 ;; chance to set it, so it's now done in arch-assem.S.
3328 \f
3329 ;;;; miscellaneous
3331 ;;; This appears here because it cannot go with the DEBUG-FUN
3332 ;;; interface since DO-DEBUG-BLOCK-LOCATIONS isn't defined until after
3333 ;;; the DEBUG-FUN routines.
3335 ;;; Return a code-location before the body of a function and after all
3336 ;;; the arguments are in place; or if that location can't be
3337 ;;; determined due to a lack of debug information, return NIL.
3344 debug-fun))
3345 nil))
3346 ;; (There used to be more cases back before sbcl-0.7.0, when
3347 ;; we did special tricks to debug the IR1 interpreter.)
3348 ))
3350 \f
3351 ;;;; Single-stepping
3353 ;;; The single-stepper works by inserting conditional trap instructions
3354 ;;; into the generated code (see src/compiler/*/call.lisp), currently:
3355 ;;;
3356 ;;; 1) Before the code generated for a function call that was
3357 ;;; translated to a VOP
3358 ;;; 2) Just before the call instruction for a full call
3359 ;;;
3360 ;;; In both cases, the trap will only be executed if stepping has been
3361 ;;; enabled, in which case it'll ultimately be handled by
3362 ;;; HANDLE-SINGLE-STEP-TRAP, which will either signal a stepping condition,
3363 ;;; or replace the function that's about to be called with a wrapper
3364 ;;; which will signal the condition.
3368 ;; The following calls must get tail-call eliminated for
3369 ;; *STEP-FRAME* to get set correctly on non-x86.
3378 ;; If there was not enough debug information available, there's no
3379 ;; sense in signaling the condition.
3385 ;; KLUDGE: Use the first non-foreign frame as the
3386 ;; *STACK-TOP-HINT*. Getting the frame from the signal
3387 ;; context as on x86 would be cleaner, but
3388 ;; SIGNAL-CONTEXT-FRAME doesn't seem seem to work at all
3389 ;; on non-x86.
3391 while frame
3397 ;; We could theoretically store information in
3398 ;; the debug-info about to determine the
3399 ;; arguments here, but for now let's just pass
3400 ;; on it.
3403 ;;; This function will replace the fdefn / function that was in the
3404 ;;; register at CALLEE-REGISTER-OFFSET with a wrapper function. To
3405 ;;; ensure that the full call will use the wrapper instead of the
3406 ;;; original, conditional trap must be emitted before the fdefn /
3407 ;;; function is converted into a raw address.
3409 ;; Fetch the function / fdefn we're about to call from the
3410 ;; appropriate register.
3414 ;; If there was not enough debug information available, there's no
3415 ;; sense in signaling the condition.
3423 args)))
3424 ;; Signal a step condition
3428 ;; And proceed based on its return value.
3430 ;; STEP-INTO was selected. Use *STEP-OUT* to
3431 ;; let the stepper know that selecting the
3432 ;; STEP-OUT restart is valid inside this
3434 ;; Pass the return values of the call to
3435 ;; STEP-VALUES, which will signal a
3436 ;; condition with them in the VALUES slot.
3439 step-info
3441 ;; If the user selected the STEP-OUT
3442 ;; restart during the call, resume
3443 ;; stepping
3446 ;; STEP-NEXT / CONTINUE / OUT selected:
3447 ;; Disable the stepper for the duration of
3448 ;; the call.
3455 fdefn))
3457 ;; And then store the wrapper in the same place.
3459 ;; %SET-CONTEXT-REGISTER is a function, so the address of
3460 ;; NEW-CALLEE gets converted to a fixnum before passing, which
3461 ;; won't keep NEW-CALLEE pinned down. Once it's inside
3462 ;; CONTEXT, which is registered in thread->interrupt_contexts,
3463 ;; it will properly point to NEW-CALLEE.
3467 ;;; Given a signal context, fetch the step-info that's been stored in
3468 ;;; the debug info at the trap point.
3474 pc-offset
3475 nil)))
3482 nil)))))
3484 ;;; Return the frame that triggered a single-step condition. Used to
3485 ;;; provide a *STACK-TOP-HINT*.
3490 ;;;; fetching errorful function name
3492 ;;; This flag is used to prevent infinite recursive lossage when
3493 ;;; we can't find the caller for some reason.
3502 frame)