| blob | 9aca1622530d48281adebd19a73eecf9d9d17e15 |
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.
835 #!-alpha n
839 ;;; On SB-DYNAMIC-CORE symbols which come from the runtime go through
840 ;;; an indirection table, but the debugger needs to know the actual
841 ;;; address.
843 #!+sb-dynamic-core
845 #!-sb-dynamic-core
848 ;;;; See above.
871 ;; KLUDGE: Detect undefined functions by a range-check
872 ;; against the trampoline address and the following
873 ;; function in the runtime.
886 code-header-len)))
889 ;; We were in an assembly routine. Therefore, use the
890 ;; LRA as the pc.
891 ;;
892 ;; FIXME: Should this be WARN or ERROR or what?
894 pc-offset code))
921 code-header-len)))
924 ;; We were in an assembly routine.
930 "Set PC-OFFSET to zero and continue backtrace."
931 'bug
932 :format-control
933 "~@<PC-OFFSET (~D) not in code object. Frame details:~
934 ~2I~:@_PC: #X~X~:@_CODE: ~S~:@_CODE FUN: ~S~:@_LRA: ~
935 #X~X~:@_COMPUTED RETURN: #X~X.~:>"
936 :format-arguments
939 code
945 computed-return))
946 ;; We failed to pinpoint where PC is, but set
947 ;; pc-offset to 0 to keep the backtrace from
948 ;; exploding.
954 real-lra-slot)))
957 nil))
962 "Finds the PC for the return from an assembly routine properly.
963 For some architectures (such as PPC) this will not be the $LRA
964 register."
970 code-header-len)
971 return-machine-address)))
973 ;;; Find the code object corresponding to the object represented by
974 ;;; bits and return it. We assume bogus functions correspond to the
975 ;;; undefined-function.
987 object)
991 nil))))))))
992 \f
993 ;;;; frame utilities
1007 min-name))
1009 ;;; This returns a COMPILED-DEBUG-FUN for COMPONENT and PC. We fetch the
1010 ;;; SB!C::DEBUG-INFO and run down its FUN-MAP to get a
1011 ;;; SB!C::COMPILED-DEBUG-FUN from the PC. The result only needs to
1012 ;;; reference the COMPONENT, for function constants, and the
1013 ;;; SB!C::COMPILED-DEBUG-FUN.
1041 ;; Non-escaped frame means that this frame calls something.
1042 ;; And the PC points to where something should return.
1043 ;; The return adress may be in the next
1044 ;; function, e.g. in local tail calls the
1045 ;; function will be entered just after the
1046 ;; CALL.
1047 ;; See debug.impure.lisp/:local-tail-call for a test-case
1051 component)))
1054 ;;; This returns a code-location for the COMPILED-DEBUG-FUN,
1055 ;;; DEBUG-FUN, and the pc into its code vector. If we stopped at a
1056 ;;; breakpoint, find the CODE-LOCATION for that breakpoint. Otherwise,
1057 ;;; make an :UNSURE code location, so it can be filled in when we
1058 ;;; figure out what is going on.
1061 escaped
1064 pc nil)))
1069 what)))))
1072 ;;; Return an alist mapping catch tags to CODE-LOCATIONs. These are
1073 ;;; CODE-LOCATIONs at which execution would continue with frame as the
1074 ;;; top frame if someone threw to the corresponding tag.
1081 do
1083 #!-alpha
1087 #!+alpha
1122 reversed-result)))
1124 #!-alpha
1128 #!+alpha
1134 ;;; Modify the value of the OLD-TAG catches in FRAME to NEW-TAG
1140 #!-alpha
1144 #!+alpha
1164 #!-alpha
1168 #!+alpha
1175 \f
1176 ;;;; operations on DEBUG-FUNs
1178 ;;; Execute the forms in a context with BLOCK-VAR bound to each
1179 ;;; DEBUG-BLOCK in DEBUG-FUN successively. Result is an optional
1180 ;;; form to execute for return values, and DO-DEBUG-FUN-BLOCKS
1181 ;;; returns nil if there is no result form. This signals a
1182 ;;; NO-DEBUG-BLOCKS condition when the DEBUG-FUN lacks
1183 ;;; DEBUG-BLOCK information.
1194 ;;; Execute body in a context with VAR bound to each DEBUG-VAR in
1195 ;;; DEBUG-FUN. This returns the value of executing result (defaults to
1196 ;;; nil). This may iterate over only some of DEBUG-FUN's variables or
1197 ;;; none depending on debug policy; for example, possibly the
1198 ;;; compilation only preserved argument information.
1210 ;;; Return the object of type FUNCTION associated with the DEBUG-FUN,
1211 ;;; or NIL if the function is unavailable or is non-existent as a user
1212 ;;; callable function object.
1233 cached-value)))
1235 ;;; Return the name of the function represented by DEBUG-FUN. This may
1236 ;;; be a string or a cons; do not assume it is a symbol.
1243 ;; Frames named (.EVAL. special-operator) should show the operator name
1244 ;; in backtraces, but if the debugger needs to detect that the frame is
1245 ;; interpreted for other purposes, it can specify PRETTY = NIL.
1248 pretty)
1269 ;; Return the name of the closure, if named, otherwise nil.
1275 ;; Frames named (.APPLY. something) are interpreted function applicators.
1276 ;; Show them as the name of the interpreted function being applied.
1277 #!+sb-fasteval
1280 ;; Find a variable named FUN.
1288 #!+precise-arg-count-error
1294 #!-precise-arg-count-error
1297 ;; The logic in CLEAN-FRAME-CALL is based on the frame name,
1298 ;; so if the simple-fun is named (XEP mumble) then the closure
1299 ;; needs to pretend to be named similarly.
1305 closure-name))))))))
1307 ;;; Return a DEBUG-FUN that represents debug information for FUN.
1322 ;; KLUDGE: comment from CMU CL:
1323 ;; This used to be the non-interpreted branch, but
1324 ;; William wrote it to return the debug-fun of fun's XEP
1325 ;; instead of fun's debug-fun. The above code does this
1326 ;; more correctly, but it doesn't get or eliminate all
1327 ;; appropriate cases. It mostly works, and probably
1328 ;; works for all named functions anyway.
1329 ;; -- WHN 20000120
1335 ;;; Return the kind of the function, which is one of :OPTIONAL,
1336 ;;; :EXTERNAL, :TOPLEVEL, :CLEANUP, or NIL.
1338 ;; FIXME: This "is one of" information should become part of the function
1339 ;; declamation, not just a doc string
1345 nil)))
1347 ;;; Is there any variable information for DEBUG-FUN?
1351 ;;; Return a list of DEBUG-VARs in DEBUG-FUN having the same name
1352 ;;; and package as SYMBOL. If SYMBOL is uninterned, then this returns
1353 ;;; a list of DEBUG-VARs without package names and with the same name
1354 ;;; as symbol. The result of this function is limited to the
1355 ;;; availability of variable information in DEBUG-FUN; for
1356 ;;; example, possibly DEBUG-FUN only knows about its arguments.
1368 vars)))
1370 ;;; Return a list of DEBUG-VARs in DEBUG-FUN whose names contain
1371 ;;; NAME-PREFIX-STRING as an initial substring. The result of this
1372 ;;; function is limited to the availability of variable information in
1373 ;;; debug-fun; for example, possibly debug-fun only knows
1374 ;;; about its arguments.
1385 ;; Find names from pos to variable's len that contain prefix.
1394 prefix-len)
1395 prefix-len)
1399 res))))
1401 ;;; This returns a position in VARIABLES for one containing NAME as an
1402 ;;; initial substring. END is the length of VARIABLES if supplied.
1416 ;;; Return a list representing the lambda-list for DEBUG-FUN. The
1417 ;;; list has the following structure:
1418 ;;; (required-var1 required-var2
1419 ;;; ...
1420 ;;; (:optional var3 suppliedp-var4)
1421 ;;; (:optional var5)
1422 ;;; ...
1423 ;;; (:rest var6) (:rest var7)
1424 ;;; ...
1425 ;;; (:keyword keyword-symbol var8 suppliedp-var9)
1426 ;;; (:keyword keyword-symbol var10)
1427 ;;; ...
1428 ;;; )
1429 ;;; Each VARi is a DEBUG-VAR; however it may be the symbol :DELETED if
1430 ;;; it is unreferenced in DEBUG-FUN. This signals a
1431 ;;; LAMBDA-LIST-UNAVAILABLE condition when there is no argument list
1432 ;;; information.
1438 ;;; Note: If this has to compute the lambda list, it caches it in DEBUG-FUN.
1446 args
1451 nil)
1454 ;; If the packed information is there (whether empty or not) as
1455 ;; opposed to being nil, then returned our cached value (nil).
1456 nil)
1458 ;; Our cached value is nil, and the packed lambda-list information
1459 ;; is nil, so we don't have anything available.
1463 ;;; COMPILED-DEBUG-FUN-LAMBDA-LIST calls this when a
1464 ;;; COMPILED-DEBUG-FUN has no lambda list information cached. It
1465 ;;; returns the lambda list as the first value and whether there was
1466 ;;; any argument information as the second value. Therefore,
1467 ;;; (VALUES NIL T) means there were no arguments, but (VALUES NIL NIL)
1468 ;;; means there was no argument information.
1477 t))
1481 t)))))
1496 tag-and-info)
1497 result))
1500 :deleted
1510 ;; The next two args are the &MORE arg context and
1511 ;; count.
1514 ;; SUPPLIED-P var immediately following keyword or
1515 ;; optional. Stick the extra var in the result element
1516 ;; representing the keyword or optional, which is the
1517 ;; previous one.
1520 ;; The keyword of a keyword parameter. Store it so the next
1521 ;; element can be used to form a (:keyword KEYWORD VALUE)
1522 ;; entry.
1525 ;; The previous element was the keyword of a keyword
1526 ;; parameter and is stored in KEYWORD. The current element
1527 ;; is the index of the value (or a deleted
1528 ;; marker). Construct and push the complete entry.
1531 ;; We saw an optional marker, so the following non-symbols
1532 ;; are indexes (or deleted markers) indicating optional
1533 ;; variables.
1536 ;; Deleted required, optional or keyword argument.
1539 ;; Required arg at beginning of args array.
1545 ;;; This is used in COMPILED-DEBUG-FUN-LAMBDA-LIST.
1556 \f
1557 ;;;; unpacking variable and basic block data
1563 ;;; PARSE-DEBUG-BLOCKS and PARSE-DEBUG-VARS
1564 ;;; use this to unpack binary encoded information. It returns the
1565 ;;; values returned by the last form in body.
1566 ;;;
1567 ;;; This binds buffer-var to *parsing-buffer*, makes sure it starts at
1568 ;;; element zero, and makes sure if we unwind, we nil out any set
1569 ;;; elements for GC purposes.
1570 ;;;
1571 ;;; This also binds other-var to *other-parsing-buffer* when it is
1572 ;;; supplied, making sure it starts at element zero and that we nil
1573 ;;; out any elements if we unwind.
1574 ;;;
1575 ;;; This defines the local macro RESULT that takes a buffer, copies
1576 ;;; its elements to a resulting simple-vector, nil's out elements, and
1577 ;;; restarts the buffer at element zero. RESULT returns the
1578 ;;; simple-vector.
1601 ;;; The argument is a debug internals structure. This returns the
1602 ;;; DEBUG-BLOCKs for DEBUG-FUN, regardless of whether we have unpacked
1603 ;;; them yet. It signals a NO-DEBUG-BLOCKS condition if it can't
1604 ;;; return the blocks.
1619 ;;; Return a SIMPLE-VECTOR of DEBUG-BLOCKs or NIL. NIL indicates there
1620 ;;; was no basic block information.
1628 ;;; This does some of the work of PARSE-DEBUG-BLOCKS.
1632 debug-fun))
1634 ;; KLUDGE: 8 is a hard-wired constant in the compiler for the
1635 ;; element size of the packed binary representation of the
1636 ;; blocks data.
1659 live-set-len blocks i))
1662 pc debug-fun block tlf-offset
1663 form-number live-set kind
1664 step-info)
1665 locations-buffer)
1674 ;;; The argument is a debug internals structure. This returns NIL if
1675 ;;; there is no variable information. It returns an empty
1676 ;;; simple-vector if there were no locals in the function. Otherwise
1677 ;;; it returns a SIMPLE-VECTOR of DEBUG-VARs.
1686 vars)))
1688 ;;; VARS is the parsed variables for a minimal debug function. We need
1689 ;;; to assign names of the form ARG-NNN. We must pad with leading
1690 ;;; zeros, since the arguments must be in alphabetical order.
1699 ;; The cross-compiler won't dump literal package
1700 ;; references because the target package objects
1701 ;; aren't created until partway through
1702 ;; cold-init. In lieu of adding smarts to the
1703 ;; build framework to handle this, we use an
1704 ;; explicit load-time-value form.
1707 ;;; Parse the packed representation of DEBUG-VARs from
1708 ;;; DEBUG-FUN's SB!C::COMPILED-DEBUG-FUN, returning a vector
1709 ;;; of DEBUG-VARs, or NIL if there was no information to parse.
1712 debug-fun))
1723 result))
1732 flags))
1748 id
1749 live
1750 sc-offset
1751 save-sc-offset
1752 indirect-sc-offset
1755 buffer)))))))
1756 \f
1757 ;;;; CODE-LOCATIONs
1759 ;;; If we're sure of whether code-location is known, return T or NIL.
1760 ;;; If we're :UNSURE, then try to fill in the code-location's slots.
1761 ;;; This determines whether there is any debug-block information, and
1762 ;;; if code-location is known.
1763 ;;;
1764 ;;; ??? IF this conses closures every time it's called, then break off the
1765 ;;; :UNSURE part to get the HANDLER-CASE into another function.
1770 (:unsure
1775 ;;; Return the DEBUG-BLOCK containing code-location if it is available.
1776 ;;; Some debug policies inhibit debug-block information, and if none
1777 ;;; is available, then this signals a NO-DEBUG-BLOCKS condition.
1784 ;; (There used to be more cases back before sbcl-0.7.0, when
1785 ;; we did special tricks to debug the IR1 interpreter.)
1786 )
1787 block)))
1789 ;;; Store and return BASIC-CODE-LOCATION's debug-block. We determines
1790 ;;; the correct one using the code-location's pc. We use
1791 ;;; DEBUG-FUN-DEBUG-BLOCKS to return the cached block information
1792 ;;; or signal a NO-DEBUG-BLOCKS condition. The blocks are sorted by
1793 ;;; their first code-location's pc, in ascending order. Therefore, as
1794 ;;; soon as we find a block that starts with a pc greater than
1795 ;;; basic-code-location's pc, we know the previous block contains the
1796 ;;; pc. If we get to the last block, then the code-location is either
1797 ;;; in the second to last block or the last block, and we have to be
1798 ;;; careful in determining this since the last block could be code at
1799 ;;; the end of the function. We have to check for the last block being
1800 ;;; code first in order to see how to compare the code-location's pc.
1804 basic-code-location))
1820 debug-fun)))
1822 last))
1823 ((< pc
1837 ;;; Return the CODE-LOCATION's DEBUG-SOURCE.
1845 ;;; Returns the number of top level forms before the one containing
1846 ;;; CODE-LOCATION as seen by the compiler in some compilation unit. (A
1847 ;;; compilation unit is not necessarily a single file, see the section
1848 ;;; on debug-sources.)
1857 ;; This check should be unnecessary. We're missing
1858 ;; debug info the compiler should have dumped.
1861 ;; (There used to be more cases back before sbcl-0.7.0,,
1862 ;; when we did special tricks to debug the IR1
1863 ;; interpreter.)
1864 ))
1867 ;;; Return the number of the form corresponding to CODE-LOCATION. The
1868 ;;; form number is derived by a walking the subforms of a top level
1869 ;;; form in depth-first order.
1878 ;; This check should be unnecessary. We're missing
1879 ;; debug info the compiler should have dumped.
1882 ;; (There used to be more cases back before sbcl-0.7.0,,
1883 ;; when we did special tricks to debug the IR1
1884 ;; interpreter.)
1885 ))
1888 ;;; Return the kind of CODE-LOCATION, one of:
1889 ;;; :INTERPRETED, :UNKNOWN-RETURN, :KNOWN-RETURN, :INTERNAL-ERROR,
1890 ;;; :NON-LOCAL-EXIT, :BLOCK-START, :CALL-SITE, :SINGLE-VALUE-RETURN,
1891 ;;; :NON-LOCAL-ENTRY
1900 ;; This check should be unnecessary. We're missing
1901 ;; debug info the compiler should have dumped.
1905 ;; (There used to be more cases back before sbcl-0.7.0,,
1906 ;; when we did special tricks to debug the IR1
1907 ;; interpreter.)
1908 ))
1910 ;;; This returns CODE-LOCATION's live-set if it is available. If
1911 ;;; there is no debug-block information, this returns NIL.
1914 nil
1918 ;; This check should be unnecessary. We're missing
1919 ;; debug info the compiler should have dumped.
1920 ;;
1921 ;; FIXME: This error and comment happen over and over again.
1922 ;; Make them a shared function.
1927 ;;; true if OBJ1 and OBJ2 are the same place in the code
1936 ;; (There used to be more cases back before sbcl-0.7.0,,
1937 ;; when we did special tricks to debug the IR1
1938 ;; interpreter.)
1939 ))
1940 ;; (There used to be more cases back before sbcl-0.7.0,,
1941 ;; when we did special tricks to debug IR1-interpreted code.)
1942 ))
1947 ;;; Fill in CODE-LOCATION's :UNPARSED slots, returning T or NIL
1948 ;;; depending on whether the code-location was known in its
1949 ;;; DEBUG-FUN's debug-block information. This may signal a
1950 ;;; NO-DEBUG-BLOCKS condition due to DEBUG-FUN-DEBUG-BLOCKS, and
1951 ;;; it assumes the %UNKNOWN-P slot is already set or going to be set.
1976 \f
1977 ;;;; operations on DEBUG-BLOCKs
1979 ;;; Execute FORMS in a context with CODE-VAR bound to each
1980 ;;; CODE-LOCATION in DEBUG-BLOCK, and return the value of RESULT.
1991 ;;; Return the name of the function represented by DEBUG-FUN.
1992 ;;; This may be a string or a cons; do not assume it is a symbol.
1999 "??? Can't get name of debug-block's function."
2002 ;; (There used to be more cases back before sbcl-0.7.0, when we
2003 ;; did special tricks to debug the IR1 interpreter.)
2004 ))
2010 ;; (There used to be more cases back before sbcl-0.7.0, when we
2011 ;; did special tricks to debug the IR1 interpreter.)
2012 ))
2013 \f
2014 ;;;; operations on debug variables
2019 ;;; FIXME: Make sure that this isn't called anywhere that it wouldn't
2020 ;;; be acceptable to have NIL returned, or that it's only called on
2021 ;;; DEBUG-VARs whose symbols have non-NIL packages.
2025 ;;; Return the value stored for DEBUG-VAR in frame, or if the value is
2026 ;;; not :VALID, then signal an INVALID-VALUE error.
2033 ;;; Returns the value stored for DEBUG-VAR in frame. The value may be
2034 ;;; invalid. This is SETFable.
2040 res)))
2042 ;;; This returns what is stored for the variable represented by
2043 ;;; DEBUG-VAR relative to the FRAME. This may be an indirect value
2044 ;;; cell if the variable is both closed over and set.
2049 ;; Indirect are accessed through a frame pointer of the parent.
2058 escaped))
2060 escaped))
2065 escaped))
2072 ;;; a helper function for working with possibly-invalid values:
2073 ;;; Do (%MAKE-LISP-OBJ VAL) only if the value looks valid.
2074 ;;;
2075 ;;; (Such values can arise in registers on machines with conservative
2076 ;;; GC, and might also arise in debug variable locations when
2077 ;;; those variables are invalid.)
2078 ;;;
2079 ;;; NOTE: this function is not GC-safe in the slightest when creating
2080 ;;; a pointer to an object in dynamic space. If a GC occurs between
2081 ;;; the start of the call to VALID-LISP-POINTER-P and the end of
2082 ;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
2083 ;;; is constructed. This can happen on CHENEYGC if an asynchronous
2084 ;;; interrupt occurs within the window. This can happen on GENCGC
2085 ;;; under the same circumstances, but is more likely due to all GENCGC
2086 ;;; platforms supporting threaded operation. This is somewhat
2087 ;;; mitigated on x86oids due to the conservative stack and interrupt
2088 ;;; context "scavenging" on such platforms, but there still may be a
2089 ;;; vulnerable window.
2097 x))
2099 ;; fixnum
2101 ;; immediate single float, 64-bit only
2104 ;; character
2107 ;; unbound marker
2109 ;; undefined_tramp doesn't validate properly as a pointer, and
2110 ;; the actual value can vary by backend (x86oids need not apply)
2115 ;; pointer
2122 nil)))))
2125 ;; NOTE: The long-float support in here is obviously decayed. When
2126 ;; the x86oid and non-x86oid versions of this function were unified,
2127 ;; the behavior of long-floats was preserved, which only served to
2128 ;; highlight its brokenness.
2132 escaped
2139 escaped
2143 ;; x86oids have no separate number stack, so dummy it
2144 ;; up for them.
2145 #!+c-stack-is-control-stack
2148 #!-c-stack-is-control-stack
2153 #!-alpha
2156 #!+alpha
2184 val)))
2187 val))
2198 #!+long-float
2205 #!+long-float
2214 #!+long-float
2228 #!+long-float
2250 (#.constant-sc-number
2259 ;;; This stores value as the value of DEBUG-VAR in FRAME. In the
2260 ;;; COMPILED-DEBUG-VAR case, access the current value to determine if
2261 ;;; it is an indirect value cell. This occurs when the variable is
2262 ;;; both closed over and set.
2269 new-value)
2271 ;;; This stores VALUE for the variable represented by debug-var
2272 ;;; relative to the frame. This assumes the location directly contains
2273 ;;; the variable's value; that is, there is no indirect value cell
2274 ;;; currently there in case the variable is both closed over and set.
2280 value escaped)
2285 value))))
2288 ;; Like sub-access-debug-var-slot, this is the unification of two
2289 ;; divergent copy-pasted functions. The astute reviewer will notice
2290 ;; that long-floats are messed up here as well, that x86oids
2291 ;; apparently don't support accessing float values that are in
2292 ;; registers, and that non-x86oids store the real part of a float
2293 ;; for both the real and imaginary parts of a complex on the stack
2294 ;; (but not in registers, oddly enough). Some research has
2295 ;; indicated that the different forms of THE used for validating the
2296 ;; type of complex float components between x86oid and non-x86oid
2297 ;; systems are only significant in the case of using a non-complex
2298 ;; number as input (as the non-x86oid case effectively converts
2299 ;; non-complex numbers to complex ones and the x86oid case will
2300 ;; error out). That said, the error message from entering a value
2301 ;; of the wrong type will be slightly easier to understand on x86oid
2302 ;; systems.
2306 escaped
2309 value))
2313 escaped
2317 value))
2319 ;; x86oids have no separate number stack, so dummy it
2320 ;; up for them.
2329 #!-alpha
2331 (* nfp-save-offset
2333 #!+alpha
2336 (* nfp-save-offset
2371 #!+long-float
2378 #!+long-float
2389 #!+long-float
2418 #!+long-float
2452 ;;; The method for setting and accessing COMPILED-DEBUG-VAR values use
2453 ;;; this to determine if the value stored is the actual value or an
2454 ;;; indirection cell.
2459 ;;; Return three values reflecting the validity of DEBUG-VAR's value
2460 ;;; at BASIC-CODE-LOCATION:
2461 ;;; :VALID The value is known to be available.
2462 ;;; :INVALID The value is known to be unavailable.
2463 ;;; :UNKNOWN The value's availability is unknown.
2464 ;;;
2465 ;;; If the variable is always alive, then it is valid. If the
2466 ;;; code-location is unknown, then the variable's validity is
2467 ;;; :unknown. Once we've called CODE-LOCATION-UNKNOWN-P, we know the
2468 ;;; live-set information has been cached in the code-location.
2475 ;;; This is the method for DEBUG-VAR-VALIDITY for COMPILED-DEBUG-VARs.
2476 ;;; For safety, make sure basic-code-location is what we think.
2484 :valid
2491 basic-code-location)))))
2494 :debug-var debug-var
2495 :debug-fun
2497 ;; There must be live-set info since basic-code-location is known.
2499 basic-code-location)
2500 pos))
2501 :invalid
2503 \f
2504 ;;;; sources
2506 ;;; This code produces and uses what we call source-paths. A
2507 ;;; source-path is a list whose first element is a form number as
2508 ;;; returned by CODE-LOCATION-FORM-NUMBER and whose last element is a
2509 ;;; top level form number as returned by
2510 ;;; CODE-LOCATION-TOPLEVEL-FORM-NUMBER. The elements from the last to
2511 ;;; the first, exclusively, are the numbered subforms into which to
2512 ;;; descend. For example:
2513 ;;; (defun foo (x)
2514 ;;; (let ((a (aref x 3)))
2515 ;;; (cons a 3)))
2516 ;;; The call to AREF in this example is form number 5. Assuming this
2517 ;;; DEFUN is the 11'th top level form, the source-path for the AREF
2518 ;;; call is as follows:
2519 ;;; (5 1 0 1 3 11)
2520 ;;; Given the DEFUN, 3 gets you the LET, 1 gets you the bindings, 0
2521 ;;; gets the first binding, and 1 gets the AREF form.
2523 ;;; This returns a table mapping form numbers to source-paths. A
2524 ;;; source-path indicates a descent into the TOPLEVEL-FORM form,
2525 ;;; going directly to the subform corressponding to the form number.
2526 ;;;
2527 ;;; The vector elements are in the same format as the compiler's
2528 ;;; NODE-SOURCE-PATH; that is, the first element is the form number and
2529 ;;; the last is the TOPLEVEL-FORM number.
2530 ;;;
2531 ;;; This should be synchronized with SB-C::SUB-FIND-SOURCE-PATHS
2539 translations)
2553 ;; Don't look into quoted constants.
2565 ;;; FORM is a top level form, and path is a source-path into it. This
2566 ;;; returns the form indicated by the source-path. Context is the
2567 ;;; number of enclosing forms to return instead of directly returning
2568 ;;; the source-path form. When context is non-zero, the form returned
2569 ;;; contains a marker, #:****HERE****, immediately before the form
2570 ;;; indicated by path.
2573 ;; Get to the form indicated by path or the enclosing form indicated
2574 ;; by context and path.
2582 ;; Recursively rebuild the source form resulting from the above
2583 ;; descent, copying the beginning of each subform up to the next
2584 ;; subform we descend into according to path. At the bottom of the
2585 ;; recursion, we return the form indicated by path preceded by our
2586 ;; marker, and this gets spliced into the resulting list structure
2587 ;; on the way back up.
2591 form
2601 ;;; Given a code location, return the associated form-number
2602 ;;; translations and the actual top level form.
2615 ;;; To suppress the read-time evaluation #. macro during source read,
2616 ;;; *READTABLE* is modified.
2617 ;;;
2618 ;;; FIXME: This breaks #+#.(cl:if ...) Maybe we need a SAFE-READ-EVAL, which
2619 ;;; this code can use for side- effect free #. calls?
2620 ;;;
2621 ;;; FIXME: This also knows nothing of custom readtables. The assumption
2622 ;;; is that the current readtable is a decent approximation for what
2623 ;;; we want, but that's lossy.
2631 rt)
2632 rt))
2634 ;;; Locate the source file (if it still exists) and grab the top level
2635 ;;; form. If the file is modified, we use the top level form offset
2636 ;;; instead of the recorded character offset.
2643 tlf-offset))
2645 ;; FIXME: External format?
2653 "~%; File has been modified since compilation:~%; ~A~@
2654 ; Using form offset instead of character position.~%"
2655 namestring)
2660 \f
2661 ;;;; PREPROCESS-FOR-EVAL
2663 ;;; Return a function of one argument that evaluates form in the
2664 ;;; lexical context of the BASIC-CODE-LOCATION LOC, or signal a
2665 ;;; NO-DEBUG-VARS condition when the LOC's DEBUG-FUN has no
2666 ;;; DEBUG-VAR information available.
2667 ;;;
2668 ;;; The returned function takes the frame to get values from as its
2669 ;;; argument, and it returns the values of FORM. The returned function
2670 ;;; can signal the following conditions: INVALID-VALUE,
2671 ;;; AMBIGUOUS-VAR-NAME, and FRAME-FUN-MISMATCH.
2686 (:more-context
2688 (:more-count
2705 (:valid
2707 (:more
2711 0
2713 (:unknown
2717 (:ambiguous
2726 ;; This prevents these functions from being used in any
2727 ;; location other than a function return location, so maybe
2728 ;; this should only check whether FRAME's DEBUG-FUN is the
2729 ;; same as LOC's.
2735 ;;; EVAL-IN-FRAME
2739 #!+sb-doc
2740 "Evaluate FORM in the lexical context of FRAME's current code location,
2741 returning the results of the evaluation."
2743 \f
2744 ;;;; breakpoints
2746 ;;;; user-visible interface
2748 ;;; Create and return a breakpoint. When program execution encounters
2749 ;;; the breakpoint, the system calls HOOK-FUN. HOOK-FUN takes the
2750 ;;; current frame for the function in which the program is running and
2751 ;;; the breakpoint object.
2752 ;;;
2753 ;;; WHAT and KIND determine where in a function the system invokes
2754 ;;; HOOK-FUN. WHAT is either a code-location or a DEBUG-FUN. KIND is
2755 ;;; one of :CODE-LOCATION, :FUN-START, or :FUN-END. Since the starts
2756 ;;; and ends of functions may not have code-locations representing
2757 ;;; them, designate these places by supplying WHAT as a DEBUG-FUN and
2758 ;;; KIND indicating the :FUN-START or :FUN-END. When WHAT is a
2759 ;;; DEBUG-FUN and kind is :FUN-END, then HOOK-FUN must take two
2760 ;;; additional arguments, a list of values returned by the function
2761 ;;; and a FUN-END-COOKIE.
2762 ;;;
2763 ;;; INFO is information supplied by and used by the user.
2764 ;;;
2765 ;;; FUN-END-COOKIE is a function. To implement :FUN-END
2766 ;;; breakpoints, the system uses starter breakpoints to establish the
2767 ;;; :FUN-END breakpoint for each invocation of the function. Upon
2768 ;;; each entry, the system creates a unique cookie to identify the
2769 ;;; invocation, and when the user supplies a function for this
2770 ;;; argument, the system invokes it on the frame and the cookie. The
2771 ;;; system later invokes the :FUN-END breakpoint hook on the same
2772 ;;; cookie. The user may save the cookie for comparison in the hook
2773 ;;; function.
2774 ;;;
2775 ;;; Signal an error if WHAT is an unknown code-location.
2782 what))
2787 ;; This slot is filled in due to calling CODE-LOCATION-UNKNOWN-P.
2790 :unknown-return-partner
2791 info)))
2794 ;; (There used to be more cases back before sbcl-0.7.0,,
2795 ;; when we did special tricks to debug the IR1
2796 ;; interpreter.)
2797 )
2798 bpt))
2801 (:fun-start
2803 (:fun-end
2820 bpt))))))
2822 ;;; These are unique objects created upon entry into a function by a
2823 ;;; :FUN-END breakpoint's starter hook. These are only created
2824 ;;; when users supply :FUN-END-COOKIE to MAKE-BREAKPOINT. Also,
2825 ;;; the :FUN-END breakpoint's hook is called on the same cookie
2826 ;;; when it is created.
2832 ;; a pointer to the bogus-lra created for :FUN-END breakpoints
2833 bogus-lra
2834 ;; the DEBUG-FUN associated with this cookie
2835 debug-fun)
2837 ;;; This maps bogus-lra-components to cookies, so that
2838 ;;; HANDLE-FUN-END-BREAKPOINT can find the appropriate cookie for the
2839 ;;; breakpoint hook.
2842 ;;; This returns a hook function for the start helper breakpoint
2843 ;;; associated with a :FUN-END breakpoint. The returned function
2844 ;;; makes a fake LRA that all returns go through, and this piece of
2845 ;;; fake code actually breaks. Upon return from the break, the code
2846 ;;; provides the returnee with any values. Since the returned function
2847 ;;; effectively activates FUN-END-BPT on each entry to DEBUG-FUN's
2848 ;;; function, we must establish breakpoint-data about FUN-END-BPT.
2856 #!-fp-and-pc-standard-save
2859 #!+fp-and-pc-standard-save
2864 lra-save-offset
2865 lra-sc-offset))
2867 lra-save-offset
2868 lra-sc-offset)
2869 lra)
2881 ;;; This takes a FUN-END-COOKIE and a frame, and it returns
2882 ;;; whether the cookie is still valid. A cookie becomes invalid when
2883 ;;; the frame that established the cookie has exited. Sometimes cookie
2884 ;;; holders are unaware of cookie invalidation because their
2885 ;;; :FUN-END breakpoint hooks didn't run due to THROW'ing.
2886 ;;;
2887 ;;; This takes a frame as an efficiency hack since the user probably
2888 ;;; has a frame object in hand when using this routine, and it saves
2889 ;;; repeated parsing of the stack and consing when asking whether a
2890 ;;; series of cookies is valid.
2894 #!-fp-and-pc-standard-save
2898 #!+fp-and-pc-standard-save
2904 lra
2907 \f
2908 ;;;; ACTIVATE-BREAKPOINT
2910 ;;; Cause the system to invoke the breakpoint's hook function until
2911 ;;; the next call to DEACTIVATE-BREAKPOINT or DELETE-BREAKPOINT. The
2912 ;;; system invokes breakpoint hook functions in the opposite order
2913 ;;; that you activate them.
2919 (:code-location
2927 ;; (There used to be more cases back before sbcl-0.7.0, when
2928 ;; we did special tricks to debug the IR1 interpreter.)
2929 )))
2930 (:fun-start
2934 ;; (There used to be more cases back before sbcl-0.7.0, when
2935 ;; we did special tricks to debug the IR1 interpreter.)
2936 ))
2937 (:fun-end
2942 ;; may already be active by some other :FUN-END breakpoint
2945 ;; (There used to be more cases back before sbcl-0.7.0, when
2946 ;; we did special tricks to debug the IR1 interpreter.)
2947 ))))
2948 breakpoint)
2955 breakpoint
2970 breakpoint
2974 debug-fun))))))
2990 \f
2991 ;;;; DEACTIVATE-BREAKPOINT
2993 ;;; Stop the system from invoking the breakpoint's hook function.
3004 ;; (There used to be more cases back before sbcl-0.7.0, when
3005 ;; we did special tricks to debug the IR1 interpreter.)
3006 ))))
3007 breakpoint)
3029 breakpoint)
3030 \f
3031 ;;;; BREAKPOINT-INFO
3033 ;;; Return the user-maintained info associated with breakpoint. This
3034 ;;; is SETF'able.
3042 \f
3043 ;;;; BREAKPOINT-ACTIVE-P and DELETE-BREAKPOINT
3050 ;;; Free system storage and remove computational overhead associated
3051 ;;; with breakpoint. After calling this, breakpoint is completely
3052 ;;; impotent and can never become active again.
3071 nil))))))
3072 breakpoint)
3073 \f
3074 ;;;; C call out stubs
3076 ;;; This actually installs the break instruction in the component. It
3077 ;;; returns the overwritten bits. You must call this in a context in
3078 ;;; which GC is disabled, so that Lisp doesn't move objects around
3079 ;;; that C is pointing to.
3084 ;;; This removes the break instruction and replaces the original
3085 ;;; instruction. You must call this in a context in which GC is disabled
3086 ;;; so Lisp doesn't move objects around that C is pointing to.
3096 ;;;; breakpoint handlers (layer between C and exported interface)
3098 ;;; This maps components to a mapping of offsets to BREAKPOINT-DATAs.
3101 ;;; This returns the BREAKPOINT-DATA object associated with component cross
3102 ;;; offset. If none exists, this makes one, installs it, and returns it.
3109 data))))
3118 ;;; We use this when there are no longer any active breakpoints
3119 ;;; corresponding to DATA.
3121 ;; Again, this looks brittle. Is there no danger of being interrupted
3122 ;; here?
3132 ;;; The C handler for interrupts calls this when it has a
3133 ;;; debugging-tool break instruction. This does *not* handle all
3134 ;;; breaks; for example, it does not handle breaks for internal
3135 ;;; errors.
3141 offset))
3147 offset component signal-context)))))
3149 ;;; This holds breakpoint-datas while invoking the breakpoint hooks
3150 ;;; associated with that particular component and location. While they
3151 ;;; are executing, if we hit the location again, we ignore the
3152 ;;; breakpoint to avoid infinite recursion. fun-end breakpoints
3153 ;;; must work differently since the breakpoint-data is unique for each
3154 ;;; invocation.
3157 ;;; This handles code-location and DEBUG-FUN :FUN-START
3158 ;;; breakpoints.
3166 ;; At this point breakpoints may not hold the same list as
3167 ;; BREAKPOINT-DATA-BREAKPOINTS since invoking hooks may have allowed
3168 ;; a breakpoint deactivation. In fact, if all breakpoints were
3169 ;; deactivated then data is invalid since it was deleted and so the
3170 ;; correct one must be looked up if it is to be used. If there are
3171 ;; no more breakpoints active at this location, then the normal
3172 ;; instruction has been put back, and we do not need to
3173 ;; DO-DISPLACED-INST.
3176 ;; The breakpoint is still active, so we need to execute the
3177 ;; displaced instruction and leave the breakpoint instruction
3178 ;; behind. The best way to do this is different on each machine,
3179 ;; so we just leave it up to the C code.
3182 ;; Some platforms have no usable sigreturn() call. If your
3183 ;; implementation of arch_do_displaced_inst() _does_ sigreturn(),
3184 ;; it's polite to warn here
3192 frame
3193 ;; If this is an :UNKNOWN-RETURN-PARTNER, then pass the
3194 ;; hook function the original breakpoint, so that users
3195 ;; aren't forced to confront the fact that some
3196 ;; breakpoints really are two.
3199 bpt)))))
3208 ;; KLUDGE: This argument is ignored on
3209 ;; x86oids in this scenario, but is
3210 ;; declared to be a SAP.
3213 nil)))
3220 offset))
3226 ;;; Either HANDLE-BREAKPOINT calls this for :FUN-END breakpoints
3227 ;;; [old C code] or HANDLE-FUN-END-BREAKPOINT calls this directly
3228 ;;; [new C code].
3230 ;; FIXME: This looks brittle: what if we are interrupted somewhere
3231 ;; here? ...or do we have interrupts disabled here?
3243 frame bpt
3245 cookie))))
3249 scp
3263 results)))
3265 \f
3266 ;;;; MAKE-BOGUS-LRA (used for :FUN-END breakpoints)
3271 ;; One more for a fixup vector
3274 ;;; Make a bogus LRA object that signals a breakpoint trap when
3275 ;;; returned to. If the breakpoint trap handler returns, REAL-LRA is
3276 ;;; returned to. Three values are returned: the bogus LRA object, the
3277 ;;; code component it is part of, and the PC offset for the trap
3278 ;;; instruction.
3281 ;; These are really code labels, not variables: but this way we get
3282 ;; their addresses.
3291 src-start src-end dst-start trap-loc)
3296 ;; Set up the widetag and header of LRA
3297 ;; The header contains the same thing as the code object header,
3298 ;; the number of boxed words, which include slots and
3299 ;; constants and it has to be double word aligned.
3300 ;;
3301 ;; It used to be a part of the fun_end_breakpoint_guts
3302 ;; but its position and value depend on the offsets
3303 ;; and alignment of code object slots.
3307 bogus-lra-constants
3322 ;; We used to set the header value of the LRA here to the
3323 ;; offset from the enclosing component to the LRA header, but
3324 ;; MAKE-LISP-OBJ actually checks the value before we get a
3325 ;; chance to set it, so it's now done in arch-assem.S.
3327 \f
3328 ;;;; miscellaneous
3330 ;;; This appears here because it cannot go with the DEBUG-FUN
3331 ;;; interface since DO-DEBUG-BLOCK-LOCATIONS isn't defined until after
3332 ;;; the DEBUG-FUN routines.
3334 ;;; Return a code-location before the body of a function and after all
3335 ;;; the arguments are in place; or if that location can't be
3336 ;;; determined due to a lack of debug information, return NIL.
3343 debug-fun))
3344 nil))
3345 ;; (There used to be more cases back before sbcl-0.7.0, when
3346 ;; we did special tricks to debug the IR1 interpreter.)
3347 ))
3349 \f
3350 ;;;; Single-stepping
3352 ;;; The single-stepper works by inserting conditional trap instructions
3353 ;;; into the generated code (see src/compiler/*/call.lisp), currently:
3354 ;;;
3355 ;;; 1) Before the code generated for a function call that was
3356 ;;; translated to a VOP
3357 ;;; 2) Just before the call instruction for a full call
3358 ;;;
3359 ;;; In both cases, the trap will only be executed if stepping has been
3360 ;;; enabled, in which case it'll ultimately be handled by
3361 ;;; HANDLE-SINGLE-STEP-TRAP, which will either signal a stepping condition,
3362 ;;; or replace the function that's about to be called with a wrapper
3363 ;;; which will signal the condition.
3367 ;; The following calls must get tail-call eliminated for
3368 ;; *STEP-FRAME* to get set correctly on non-x86.
3377 ;; If there was not enough debug information available, there's no
3378 ;; sense in signaling the condition.
3384 ;; KLUDGE: Use the first non-foreign frame as the
3385 ;; *STACK-TOP-HINT*. Getting the frame from the signal
3386 ;; context as on x86 would be cleaner, but
3387 ;; SIGNAL-CONTEXT-FRAME doesn't seem seem to work at all
3388 ;; on non-x86.
3390 while frame
3396 ;; We could theoretically store information in
3397 ;; the debug-info about to determine the
3398 ;; arguments here, but for now let's just pass
3399 ;; on it.
3402 ;;; This function will replace the fdefn / function that was in the
3403 ;;; register at CALLEE-REGISTER-OFFSET with a wrapper function. To
3404 ;;; ensure that the full call will use the wrapper instead of the
3405 ;;; original, conditional trap must be emitted before the fdefn /
3406 ;;; function is converted into a raw address.
3408 ;; Fetch the function / fdefn we're about to call from the
3409 ;; appropriate register.
3413 ;; If there was not enough debug information available, there's no
3414 ;; sense in signaling the condition.
3422 args)))
3423 ;; Signal a step condition
3427 ;; And proceed based on its return value.
3429 ;; STEP-INTO was selected. Use *STEP-OUT* to
3430 ;; let the stepper know that selecting the
3431 ;; STEP-OUT restart is valid inside this
3433 ;; Pass the return values of the call to
3434 ;; STEP-VALUES, which will signal a
3435 ;; condition with them in the VALUES slot.
3438 step-info
3440 ;; If the user selected the STEP-OUT
3441 ;; restart during the call, resume
3442 ;; stepping
3445 ;; STEP-NEXT / CONTINUE / OUT selected:
3446 ;; Disable the stepper for the duration of
3447 ;; the call.
3454 fdefn))
3456 ;; And then store the wrapper in the same place.
3458 ;; %SET-CONTEXT-REGISTER is a function, so the address of
3459 ;; NEW-CALLEE gets converted to a fixnum before passing, which
3460 ;; won't keep NEW-CALLEE pinned down. Once it's inside
3461 ;; CONTEXT, which is registered in thread->interrupt_contexts,
3462 ;; it will properly point to NEW-CALLEE.
3466 ;;; Given a signal context, fetch the step-info that's been stored in
3467 ;;; the debug info at the trap point.
3473 pc-offset
3474 nil)))
3481 nil)))))
3483 ;;; Return the frame that triggered a single-step condition. Used to
3484 ;;; provide a *STACK-TOP-HINT*.
3489 ;;;; fetching errorful function name
3491 ;;; This flag is used to prevent infinite recursive lossage when
3492 ;;; we can't find the caller for some reason.
3501 frame)