| blob | f8a1099ed70ecfb61e53655cb5cc0e1d710647b6 |
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 ;;;; frames
222 ;;; These represent call frames on the stack.
225 ;; the next frame up, or NIL when top frame
227 ;; the previous frame down, or NIL when the bottom frame. Before
228 ;; computing the next frame down, this slot holds the frame pointer
229 ;; to the control stack for the given frame. This lets us get the
230 ;; next frame down and the return-pc for that frame.
232 ;; the DEBUG-FUN for the function whose call this frame represents
234 ;; the CODE-LOCATION where the frame's DEBUG-FUN will continue
235 ;; running when program execution returns to this frame. If someone
236 ;; interrupted this frame, the result could be an unknown
237 ;; CODE-LOCATION.
239 ;; an a-list of catch-tags to code-locations
241 ;; pointer to frame on control stack (unexported)
242 pointer
243 ;; This is the frame's number for prompt printing. Top is zero.
248 (:constructor make-compiled-frame
252 ;; This indicates whether someone interrupted the frame.
253 ;; (unexported). If escaped, this is a pointer to the state that was
254 ;; saved when we were interrupted, an os_context_t, i.e. the third
255 ;; argument to an SA_SIGACTION-style signal handler.
256 escaped)
260 "~S~:[~;, interrupted~]"
263 \f
264 ;;;; DEBUG-FUNs
266 ;;; These exist for caching data stored in packed binary form in
267 ;;; compiler DEBUG-FUNs. *COMPILED-DEBUG-FUNS* maps a SB!C::DEBUG-FUN
268 ;;; to a DEBUG-FUN. There should only be one DEBUG-FUN in existence
269 ;;; for any function; that is, all CODE-LOCATIONs and other objects
270 ;;; that reference DEBUG-FUNs point to unique objects. This is
271 ;;; due to the overhead in cached information.
274 ;; some representation of the function arguments. See
275 ;; DEBUG-FUN-LAMBDA-LIST.
276 ;; NOTE: must parse vars before parsing arg list stuff.
278 ;; cached DEBUG-VARS information (unexported).
279 ;; These are sorted by their name.
281 ;; cached debug-block information. This is NIL when we have tried to
282 ;; parse the packed binary info, but none is available.
284 ;; the actual function if available
292 (:constructor %make-compiled-debug-fun
295 ;; compiler's dumped DEBUG-FUN information (unexported)
297 ;; code object (unexported).
298 component
299 ;; the :FUN-START breakpoint (if any) used to facilitate
300 ;; function end breakpoints
303 ;;; This maps SB!C::COMPILED-DEBUG-FUNs to
304 ;;; COMPILED-DEBUG-FUNs, so we can get at cached stuff and not
305 ;;; duplicate COMPILED-DEBUG-FUN structures.
308 ;;; Make a COMPILED-DEBUG-FUN for a SB!C::COMPILER-DEBUG-FUN and its
309 ;;; component. This maps the latter to the former in
310 ;;; *COMPILED-DEBUG-FUNS*. If there already is a COMPILED-DEBUG-FUN,
311 ;;; then this returns it from *COMPILED-DEBUG-FUNS*.
312 ;;;
313 ;;; FIXME: It seems this table can potentially grow without bounds,
314 ;;; and retains roots to functions that might otherwise be collected.
324 (:constructor make-bogus-debug-fun
331 %name)
332 \f
333 ;;;; DEBUG-BLOCKs
335 ;;; These exist for caching data stored in packed binary form in compiler
336 ;;; DEBUG-BLOCKs.
339 ;; This indicates whether the block is a special glob of code shared
340 ;; by various functions and tucked away elsewhere in a component.
341 ;; This kind of block has no start code-location. This slot is in
342 ;; all debug-blocks since it is an exported interface.
348 #!+sb-doc
354 ;; code-location information for the block
356 \f
357 ;;;; breakpoints
359 ;;; This is an internal structure that manages information about a
360 ;;; breakpoint locations. See *COMPONENT-BREAKPOINT-OFFSETS*.
364 ;; This is the component in which the breakpoint lies.
365 component
366 ;; This is the byte offset into the component.
368 ;; The original instruction replaced by the breakpoint.
370 ;; A list of user breakpoints at this location.
383 ;; This is the function invoked when execution encounters the
384 ;; breakpoint. It takes a frame, the breakpoint, and optionally a
385 ;; list of values. Values are supplied for :FUN-END breakpoints as
386 ;; values to return for the function containing the breakpoint.
387 ;; :FUN-END breakpoint hook functions also take a cookie argument.
388 ;; See the COOKIE-FUN slot.
390 ;; CODE-LOCATION or DEBUG-FUN
392 ;; :CODE-LOCATION, :FUN-START, or :FUN-END for that kind
393 ;; of breakpoint. :UNKNOWN-RETURN-PARTNER if this is the partner of
394 ;; a :code-location breakpoint at an :UNKNOWN-RETURN code-location.
397 ;; Status helps the user and the implementation.
399 ;; This is a backpointer to a breakpoint-data.
401 ;; With code-locations whose type is :UNKNOWN-RETURN, there are
402 ;; really two breakpoints: one at the multiple-value entry point,
403 ;; and one at the single-value entry point. This slot holds the
404 ;; breakpoint for the other one, or NIL if this isn't at an
405 ;; :UNKNOWN-RETURN code location.
407 ;; :FUN-END breakpoints use a breakpoint at the :FUN-START
408 ;; to establish the end breakpoint upon function entry. We do this
409 ;; by frobbing the LRA to jump to a special piece of code that
410 ;; breaks and provides the return values for the returnee. This slot
411 ;; points to the start breakpoint, so we can activate, deactivate,
412 ;; and delete it.
414 ;; This is a hook users supply to get a dynamically unique cookie
415 ;; for identifying :FUN-END breakpoint executions. That is, if
416 ;; there is one :FUN-END breakpoint, but there may be multiple
417 ;; pending calls of its function on the stack. This function takes
418 ;; the cookie, and the hook function takes the cookie too.
420 ;; This slot users can set with whatever information they find useful.
421 %info)
426 "~S~:[~;~:*~S~]"
433 \f
434 ;;;; CODE-LOCATIONs
438 ;; the DEBUG-FUN containing this CODE-LOCATION
440 ;; This is initially :UNSURE. Upon first trying to access an
441 ;; :UNPARSED slot, if the data is unavailable, then this becomes T,
442 ;; and the code-location is unknown. If the data is available, this
443 ;; becomes NIL, a known location. We can't use a separate type
444 ;; code-location for this since we must return code-locations before
445 ;; we can tell whether they're known or unknown. For example, when
446 ;; parsing the stack, we don't want to unpack all the variables and
447 ;; blocks just to make frames.
449 ;; the DEBUG-BLOCK containing CODE-LOCATION. XXX Possibly toss this
450 ;; out and just find it in the blocks cache in DEBUG-FUN.
452 ;; This is the number of forms processed by the compiler or loader
453 ;; before the top level form containing this code-location.
455 ;; This is the depth-first number of the node that begins
456 ;; code-location within its top level form.
461 str)))
465 (:constructor make-known-code-location
470 ;; an index into DEBUG-FUN's component slot
472 ;; a bit-vector indexed by a variable's position in
473 ;; DEBUG-FUN-DEBUG-VARS indicating whether the variable has a
474 ;; valid value at this code-location. (unexported).
476 ;; (unexported) To see SB!C::LOCATION-KIND, do
477 ;; (SB!KERNEL:TYPEXPAND 'SB!C::LOCATION-KIND).
480 \f
481 ;;;; DEBUG-SOURCEs
483 ;;; Return the number of top level forms processed by the compiler
484 ;;; before compiling this source. If this source is uncompiled, this
485 ;;; is zero. This may be zero even if the source is compiled since the
486 ;;; first form in the first file compiled in one compilation, for
487 ;;; example, must have a root number of zero -- the compiler saw no
488 ;;; other top level forms before it.
491 \f
492 ;;;; frames
494 ;;; This is used in FIND-ESCAPED-FRAME and with the bogus components
495 ;;; and LRAs used for :FUN-END breakpoints. When a component's
496 ;;; debug-info slot is :BOGUS-LRA, then the REAL-LRA-SLOT contains the
497 ;;; real component to continue executing, as opposed to the bogus
498 ;;; component which appeared in some frame's LRA location.
500 ;; X86 stores a fixup vector at the first constant slot
504 ;;; These are magically converted by the compiler.
521 #!+stack-grows-downward-not-upward
524 #!-stack-grows-downward-not-upward
529 #!+stack-grows-downward-not-upward
549 ;;;; (OR X86 X86-64) support
560 code-header-len)))
561 ;;(format t "c-lra-fpc ~A ~A ~A~%" pc code pc-offset)
569 ;;; Check for a valid return address - it could be any valid C/Lisp
570 ;;; address.
571 ;;;
572 ;;; XXX Could be a little smarter.
577 ;; not the first page (which is unmapped)
578 ;;
579 ;; FIXME: Where is this documented? Is it really true of every CPU
580 ;; architecture? Is it even necessarily true in current SBCL?
582 ;; not a Lisp stack pointer
585 ;;; Try to find a valid previous stack. This is complex on the x86 as
586 ;;; it can jump between C and Lisp frames. To help find a valid frame
587 ;;; it searches backwards.
588 ;;;
589 ;;; XXX Should probably check whether it has reached the bottom of the
590 ;;; stack.
591 ;;;
592 ;;; XXX Should handle interrupted frames, both Lisp and C. At present
593 ;;; it manages to find a fp trail, see linux hack below.
607 \f
608 ;;; Convert the descriptor into a SAP. The bits all stay the same, we just
609 ;;; change our notion of what we think they are.
614 ;;; Return the top frame of the control stack as it was before calling
615 ;;; this function.
620 nil))
622 ;;; Flush all of the frames above FRAME, and renumber all the frames
623 ;;; below FRAME.
637 ;;; Return the frame immediately below FRAME on the stack; or when
638 ;;; FRAME is the bottom of the stack, return NIL.
641 ;; We have to access the old-fp and return-pc out of frame and pass
642 ;; them to COMPUTE-CALLING-FRAME.
652 debug-fun)))
656 frame ocfp-save-offset
657 #!-fp-and-pc-standard-save
659 #!+fp-and-pc-standard-save
662 frame lra-save-offset
663 #!-fp-and-pc-standard-save
665 #!+fp-and-pc-standard-save
667 frame)))
678 #!-alpha
681 #!+alpha
688 frame)))))))
689 down)))
691 ;;; Get the old FP or return PC out of FRAME. STACK-SLOT is the
692 ;;; standard save location offset on the stack. LOC is the saved
693 ;;; SC-OFFSET describing the main location.
705 (#.ocfp-save-offset
707 (#.lra-save-offset
721 (#.ocfp-save-offset
723 (#.lra-save-offset
725 value))))))
733 ;;; This returns a frame for the one existing in time immediately
734 ;;; prior to the frame referenced by current-fp. This is current-fp's
735 ;;; caller or the next frame down the control stack. If there is no
736 ;;; down frame, this returns NIL for the bottom of the stack. UP-FRAME
737 ;;; is the up link for the resulting frame object, and it is null when
738 ;;; we call this to get the top of the stack.
739 ;;;
740 ;;; The current frame contains the pointer to the temporally previous
741 ;;; frame we want, and the current frame contains the pc at which we
742 ;;; will continue executing upon returning to that previous frame.
743 ;;;
744 ;;; Note: Sometimes LRA is actually a fixnum. This happens when lisp
745 ;;; calls into C. In this case, the code object is stored on the stack
746 ;;; after the LRA, and the LRA is the word offset.
766 nil)
768 0
769 nil)))
776 (:undefined-function
779 (:foreign-function
791 escaped)
793 escaped))))))
801 ;; First check for an escaped frame.
806 ;; If it's escaped it may be a function end breakpoint trap.
809 ;; If :bogus-lra grab the real lra.
821 (:undefined-function
824 (:foreign-function
835 escaped)
837 ;; If we have an interrupt-context that's not on
838 ;; our stack at all, and we're computing the
839 ;; from from a saved FP, we're probably looking
840 ;; at an interrupted syscall.
848 #!-alpha n
852 ;;; On SB-DYNAMIC-CORE symbols which come from the runtime go through
853 ;;; an indirection table, but the debugger needs to know the actual
854 ;;; address.
856 #!+sb-dynamic-core
858 #!-sb-dynamic-core
861 ;;;; See above.
884 ;; KLUDGE: Detect undefined functions by a range-check
885 ;; against the trampoline address and the following
886 ;; function in the runtime.
899 code-header-len)))
902 ;; We were in an assembly routine. Therefore, use the
903 ;; LRA as the pc.
904 ;;
905 ;; FIXME: Should this be WARN or ERROR or what?
907 pc-offset code))
934 code-header-len)))
937 ;; We were in an assembly routine.
943 "Set PC-OFFSET to zero and continue backtrace."
944 'bug
945 :format-control
946 "~@<PC-OFFSET (~D) not in code object. Frame details:~
947 ~2I~:@_PC: #X~X~:@_CODE: ~S~:@_CODE FUN: ~S~:@_LRA: ~
948 #X~X~:@_COMPUTED RETURN: #X~X.~:>"
949 :format-arguments
952 code
954 #!-arm
956 #!+arm
958 computed-return))
959 ;; We failed to pinpoint where PC is, but set
960 ;; pc-offset to 0 to keep the backtrace from
961 ;; exploding.
967 real-lra-slot)))
970 nil))
975 "Finds the PC for the return from an assembly routine properly.
976 For some architectures (such as PPC) this will not be the $LRA
977 register."
983 code-header-len)
984 return-machine-address)))
986 ;;; Find the code object corresponding to the object represented by
987 ;;; bits and return it. We assume bogus functions correspond to the
988 ;;; undefined-function.
1000 object)
1004 nil))))))))
1005 \f
1006 ;;;; frame utilities
1020 min-name))
1022 ;;; This returns a COMPILED-DEBUG-FUN for COMPONENT and PC. We fetch the
1023 ;;; SB!C::DEBUG-INFO and run down its FUN-MAP to get a
1024 ;;; SB!C::COMPILED-DEBUG-FUN from the PC. The result only needs to
1025 ;;; reference the COMPONENT, for function constants, and the
1026 ;;; SB!C::COMPILED-DEBUG-FUN.
1054 ;; Non-escaped frame means that this frame calls something.
1055 ;; And the PC points to where something should return.
1056 ;; The return adress may be in the next
1057 ;; function, e.g. in local tail calls the
1058 ;; function will be entered just after the
1059 ;; CALL.
1060 ;; See debug.impure.lisp/:local-tail-call for a test-case
1064 component)))
1067 ;;; This returns a code-location for the COMPILED-DEBUG-FUN,
1068 ;;; DEBUG-FUN, and the pc into its code vector. If we stopped at a
1069 ;;; breakpoint, find the CODE-LOCATION for that breakpoint. Otherwise,
1070 ;;; make an :UNSURE code location, so it can be filled in when we
1071 ;;; figure out what is going on.
1074 escaped
1077 pc nil)))
1082 what)))))
1085 ;;; Return an alist mapping catch tags to CODE-LOCATIONs. These are
1086 ;;; CODE-LOCATIONs at which execution would continue with frame as the
1087 ;;; top frame if someone threw to the corresponding tag.
1094 do
1096 #!-alpha
1100 #!+alpha
1135 reversed-result)))
1137 #!-alpha
1141 #!+alpha
1147 ;;; Modify the value of the OLD-TAG catches in FRAME to NEW-TAG
1153 #!-alpha
1157 #!+alpha
1177 #!-alpha
1181 #!+alpha
1188 \f
1189 ;;;; operations on DEBUG-FUNs
1191 ;;; Execute the forms in a context with BLOCK-VAR bound to each
1192 ;;; DEBUG-BLOCK in DEBUG-FUN successively. Result is an optional
1193 ;;; form to execute for return values, and DO-DEBUG-FUN-BLOCKS
1194 ;;; returns nil if there is no result form. This signals a
1195 ;;; NO-DEBUG-BLOCKS condition when the DEBUG-FUN lacks
1196 ;;; DEBUG-BLOCK information.
1207 ;;; Execute body in a context with VAR bound to each DEBUG-VAR in
1208 ;;; DEBUG-FUN. This returns the value of executing result (defaults to
1209 ;;; nil). This may iterate over only some of DEBUG-FUN's variables or
1210 ;;; none depending on debug policy; for example, possibly the
1211 ;;; compilation only preserved argument information.
1223 ;;; Return the object of type FUNCTION associated with the DEBUG-FUN,
1224 ;;; or NIL if the function is unavailable or is non-existent as a user
1225 ;;; callable function object.
1246 cached-value)))
1248 ;;; Return the name of the function represented by DEBUG-FUN. This may
1249 ;;; be a string or a cons; do not assume it is a symbol.
1273 ;; Return the name of the closure, if named, otherwise nil.
1283 #!+precise-arg-count-error
1289 closure-save))
1290 #!-precise-arg-count-error
1292 closure-save))))
1294 ;; The logic in CLEAN-FRAME-CALL is based on the frame name,
1295 ;; so if the simple-fun is named (XEP mumble) then the closure
1296 ;; needs to pretend to be named similarly.
1302 closure-name))))))))
1304 ;;; Return a DEBUG-FUN that represents debug information for FUN.
1319 ;; KLUDGE: comment from CMU CL:
1320 ;; This used to be the non-interpreted branch, but
1321 ;; William wrote it to return the debug-fun of fun's XEP
1322 ;; instead of fun's debug-fun. The above code does this
1323 ;; more correctly, but it doesn't get or eliminate all
1324 ;; appropriate cases. It mostly works, and probably
1325 ;; works for all named functions anyway.
1326 ;; -- WHN 20000120
1332 ;;; Return the kind of the function, which is one of :OPTIONAL,
1333 ;;; :EXTERNAL, :TOPLEVEL, :CLEANUP, or NIL.
1335 ;; FIXME: This "is one of" information should become part of the function
1336 ;; declamation, not just a doc string
1342 nil)))
1344 ;;; Is there any variable information for DEBUG-FUN?
1348 ;;; Return a list of DEBUG-VARs in DEBUG-FUN having the same name
1349 ;;; and package as SYMBOL. If SYMBOL is uninterned, then this returns
1350 ;;; a list of DEBUG-VARs without package names and with the same name
1351 ;;; as symbol. The result of this function is limited to the
1352 ;;; availability of variable information in DEBUG-FUN; for
1353 ;;; example, possibly DEBUG-FUN only knows about its arguments.
1365 vars)))
1367 ;;; Return a list of DEBUG-VARs in DEBUG-FUN whose names contain
1368 ;;; NAME-PREFIX-STRING as an initial substring. The result of this
1369 ;;; function is limited to the availability of variable information in
1370 ;;; debug-fun; for example, possibly debug-fun only knows
1371 ;;; about its arguments.
1382 ;; Find names from pos to variable's len that contain prefix.
1391 prefix-len)
1392 prefix-len)
1396 res))))
1398 ;;; This returns a position in VARIABLES for one containing NAME as an
1399 ;;; initial substring. END is the length of VARIABLES if supplied.
1413 ;;; Return a list representing the lambda-list for DEBUG-FUN. The
1414 ;;; list has the following structure:
1415 ;;; (required-var1 required-var2
1416 ;;; ...
1417 ;;; (:optional var3 suppliedp-var4)
1418 ;;; (:optional var5)
1419 ;;; ...
1420 ;;; (:rest var6) (:rest var7)
1421 ;;; ...
1422 ;;; (:keyword keyword-symbol var8 suppliedp-var9)
1423 ;;; (:keyword keyword-symbol var10)
1424 ;;; ...
1425 ;;; )
1426 ;;; Each VARi is a DEBUG-VAR; however it may be the symbol :DELETED if
1427 ;;; it is unreferenced in DEBUG-FUN. This signals a
1428 ;;; LAMBDA-LIST-UNAVAILABLE condition when there is no argument list
1429 ;;; information.
1435 ;;; Note: If this has to compute the lambda list, it caches it in DEBUG-FUN.
1443 args
1448 nil)
1451 ;; If the packed information is there (whether empty or not) as
1452 ;; opposed to being nil, then returned our cached value (nil).
1453 nil)
1455 ;; Our cached value is nil, and the packed lambda-list information
1456 ;; is nil, so we don't have anything available.
1460 ;;; COMPILED-DEBUG-FUN-LAMBDA-LIST calls this when a
1461 ;;; COMPILED-DEBUG-FUN has no lambda list information cached. It
1462 ;;; returns the lambda list as the first value and whether there was
1463 ;;; any argument information as the second value. Therefore,
1464 ;;; (VALUES NIL T) means there were no arguments, but (VALUES NIL NIL)
1465 ;;; means there was no argument information.
1474 t))
1489 ;; Deleted required arg at beginning of args array.
1494 ;; SUPPLIED-P var immediately following keyword or
1495 ;; optional. Stick the extra var in the result
1496 ;; element representing the keyword or optional,
1497 ;; which is the previous one.
1498 ;;
1499 ;; FIXME: NCONC used for side-effect: the effect is defined,
1500 ;; but this is bad style no matter what.
1508 res))
1510 ;; The next two args are the &MORE arg context and count.
1516 res))
1518 ;; &KEY arg
1520 ele
1523 res))))
1525 ;; We saw an optional marker, so the following
1526 ;; non-symbols are indexes indicating optional
1527 ;; variables.
1530 ;; Required arg at beginning of args array.
1535 ;;; This is used in COMPILED-DEBUG-FUN-LAMBDA-LIST.
1546 \f
1547 ;;;; unpacking variable and basic block data
1553 ;;; PARSE-DEBUG-BLOCKS and PARSE-DEBUG-VARS
1554 ;;; use this to unpack binary encoded information. It returns the
1555 ;;; values returned by the last form in body.
1556 ;;;
1557 ;;; This binds buffer-var to *parsing-buffer*, makes sure it starts at
1558 ;;; element zero, and makes sure if we unwind, we nil out any set
1559 ;;; elements for GC purposes.
1560 ;;;
1561 ;;; This also binds other-var to *other-parsing-buffer* when it is
1562 ;;; supplied, making sure it starts at element zero and that we nil
1563 ;;; out any elements if we unwind.
1564 ;;;
1565 ;;; This defines the local macro RESULT that takes a buffer, copies
1566 ;;; its elements to a resulting simple-vector, nil's out elements, and
1567 ;;; restarts the buffer at element zero. RESULT returns the
1568 ;;; simple-vector.
1591 ;;; The argument is a debug internals structure. This returns the
1592 ;;; DEBUG-BLOCKs for DEBUG-FUN, regardless of whether we have unpacked
1593 ;;; them yet. It signals a NO-DEBUG-BLOCKS condition if it can't
1594 ;;; return the blocks.
1609 ;;; Return a SIMPLE-VECTOR of DEBUG-BLOCKs or NIL. NIL indicates there
1610 ;;; was no basic block information.
1618 ;;; This does some of the work of PARSE-DEBUG-BLOCKS.
1622 debug-fun))
1624 ;; KLUDGE: 8 is a hard-wired constant in the compiler for the
1625 ;; element size of the packed binary representation of the
1626 ;; blocks data.
1649 live-set-len blocks i))
1652 pc debug-fun block tlf-offset
1653 form-number live-set kind
1654 step-info)
1655 locations-buffer)
1664 ;;; The argument is a debug internals structure. This returns NIL if
1665 ;;; there is no variable information. It returns an empty
1666 ;;; simple-vector if there were no locals in the function. Otherwise
1667 ;;; it returns a SIMPLE-VECTOR of DEBUG-VARs.
1676 vars)))
1678 ;;; VARS is the parsed variables for a minimal debug function. We need
1679 ;;; to assign names of the form ARG-NNN. We must pad with leading
1680 ;;; zeros, since the arguments must be in alphabetical order.
1689 ;; The cross-compiler won't dump literal package
1690 ;; references because the target package objects
1691 ;; aren't created until partway through
1692 ;; cold-init. In lieu of adding smarts to the
1693 ;; build framework to handle this, we use an
1694 ;; explicit load-time-value form.
1697 ;;; Parse the packed representation of DEBUG-VARs from
1698 ;;; DEBUG-FUN's SB!C::COMPILED-DEBUG-FUN, returning a vector
1699 ;;; of DEBUG-VARs, or NIL if there was no information to parse.
1702 debug-fun))
1713 result))
1722 flags))
1734 id
1735 live
1736 sc-offset
1737 save-sc-offset
1738 indirect-sc-offset
1741 buffer)))))))
1742 \f
1743 ;;;; CODE-LOCATIONs
1745 ;;; If we're sure of whether code-location is known, return T or NIL.
1746 ;;; If we're :UNSURE, then try to fill in the code-location's slots.
1747 ;;; This determines whether there is any debug-block information, and
1748 ;;; if code-location is known.
1749 ;;;
1750 ;;; ??? IF this conses closures every time it's called, then break off the
1751 ;;; :UNSURE part to get the HANDLER-CASE into another function.
1756 (:unsure
1761 ;;; Return the DEBUG-BLOCK containing code-location if it is available.
1762 ;;; Some debug policies inhibit debug-block information, and if none
1763 ;;; is available, then this signals a NO-DEBUG-BLOCKS condition.
1770 ;; (There used to be more cases back before sbcl-0.7.0, when
1771 ;; we did special tricks to debug the IR1 interpreter.)
1772 )
1773 block)))
1775 ;;; Store and return BASIC-CODE-LOCATION's debug-block. We determines
1776 ;;; the correct one using the code-location's pc. We use
1777 ;;; DEBUG-FUN-DEBUG-BLOCKS to return the cached block information
1778 ;;; or signal a NO-DEBUG-BLOCKS condition. The blocks are sorted by
1779 ;;; their first code-location's pc, in ascending order. Therefore, as
1780 ;;; soon as we find a block that starts with a pc greater than
1781 ;;; basic-code-location's pc, we know the previous block contains the
1782 ;;; pc. If we get to the last block, then the code-location is either
1783 ;;; in the second to last block or the last block, and we have to be
1784 ;;; careful in determining this since the last block could be code at
1785 ;;; the end of the function. We have to check for the last block being
1786 ;;; code first in order to see how to compare the code-location's pc.
1790 basic-code-location))
1806 debug-fun)))
1808 last))
1809 ((< pc
1823 ;;; Return the CODE-LOCATION's DEBUG-SOURCE.
1831 ;;; Returns the number of top level forms before the one containing
1832 ;;; CODE-LOCATION as seen by the compiler in some compilation unit. (A
1833 ;;; compilation unit is not necessarily a single file, see the section
1834 ;;; on debug-sources.)
1843 ;; This check should be unnecessary. We're missing
1844 ;; debug info the compiler should have dumped.
1847 ;; (There used to be more cases back before sbcl-0.7.0,,
1848 ;; when we did special tricks to debug the IR1
1849 ;; interpreter.)
1850 ))
1853 ;;; Return the number of the form corresponding to CODE-LOCATION. The
1854 ;;; form number is derived by a walking the subforms of a top level
1855 ;;; form in depth-first order.
1864 ;; This check should be unnecessary. We're missing
1865 ;; debug info the compiler should have dumped.
1868 ;; (There used to be more cases back before sbcl-0.7.0,,
1869 ;; when we did special tricks to debug the IR1
1870 ;; interpreter.)
1871 ))
1874 ;;; Return the kind of CODE-LOCATION, one of:
1875 ;;; :INTERPRETED, :UNKNOWN-RETURN, :KNOWN-RETURN, :INTERNAL-ERROR,
1876 ;;; :NON-LOCAL-EXIT, :BLOCK-START, :CALL-SITE, :SINGLE-VALUE-RETURN,
1877 ;;; :NON-LOCAL-ENTRY
1886 ;; This check should be unnecessary. We're missing
1887 ;; debug info the compiler should have dumped.
1891 ;; (There used to be more cases back before sbcl-0.7.0,,
1892 ;; when we did special tricks to debug the IR1
1893 ;; interpreter.)
1894 ))
1896 ;;; This returns CODE-LOCATION's live-set if it is available. If
1897 ;;; there is no debug-block information, this returns NIL.
1900 nil
1904 ;; This check should be unnecessary. We're missing
1905 ;; debug info the compiler should have dumped.
1906 ;;
1907 ;; FIXME: This error and comment happen over and over again.
1908 ;; Make them a shared function.
1913 ;;; true if OBJ1 and OBJ2 are the same place in the code
1922 ;; (There used to be more cases back before sbcl-0.7.0,,
1923 ;; when we did special tricks to debug the IR1
1924 ;; interpreter.)
1925 ))
1926 ;; (There used to be more cases back before sbcl-0.7.0,,
1927 ;; when we did special tricks to debug IR1-interpreted code.)
1928 ))
1933 ;;; Fill in CODE-LOCATION's :UNPARSED slots, returning T or NIL
1934 ;;; depending on whether the code-location was known in its
1935 ;;; DEBUG-FUN's debug-block information. This may signal a
1936 ;;; NO-DEBUG-BLOCKS condition due to DEBUG-FUN-DEBUG-BLOCKS, and
1937 ;;; it assumes the %UNKNOWN-P slot is already set or going to be set.
1962 \f
1963 ;;;; operations on DEBUG-BLOCKs
1965 ;;; Execute FORMS in a context with CODE-VAR bound to each
1966 ;;; CODE-LOCATION in DEBUG-BLOCK, and return the value of RESULT.
1977 ;;; Return the name of the function represented by DEBUG-FUN.
1978 ;;; This may be a string or a cons; do not assume it is a symbol.
1985 "??? Can't get name of debug-block's function."
1988 ;; (There used to be more cases back before sbcl-0.7.0, when we
1989 ;; did special tricks to debug the IR1 interpreter.)
1990 ))
1996 ;; (There used to be more cases back before sbcl-0.7.0, when we
1997 ;; did special tricks to debug the IR1 interpreter.)
1998 ))
1999 \f
2000 ;;;; operations on debug variables
2005 ;;; FIXME: Make sure that this isn't called anywhere that it wouldn't
2006 ;;; be acceptable to have NIL returned, or that it's only called on
2007 ;;; DEBUG-VARs whose symbols have non-NIL packages.
2011 ;;; Return the value stored for DEBUG-VAR in frame, or if the value is
2012 ;;; not :VALID, then signal an INVALID-VALUE error.
2019 ;;; Returns the value stored for DEBUG-VAR in frame. The value may be
2020 ;;; invalid. This is SETFable.
2026 res)))
2028 ;;; This returns what is stored for the variable represented by
2029 ;;; DEBUG-VAR relative to the FRAME. This may be an indirect value
2030 ;;; cell if the variable is both closed over and set.
2035 ;; Indirect are accessed through a frame pointer of the parent.
2044 escaped))
2046 escaped))
2051 escaped))
2058 ;;; a helper function for working with possibly-invalid values:
2059 ;;; Do (%MAKE-LISP-OBJ VAL) only if the value looks valid.
2060 ;;;
2061 ;;; (Such values can arise in registers on machines with conservative
2062 ;;; GC, and might also arise in debug variable locations when
2063 ;;; those variables are invalid.)
2064 ;;;
2065 ;;; NOTE: this function is not GC-safe in the slightest when creating
2066 ;;; a pointer to an object in dynamic space. If a GC occurs between
2067 ;;; the start of the call to VALID-LISP-POINTER-P and the end of
2068 ;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
2069 ;;; is constructed. This can happen on CHENEYGC if an asynchronous
2070 ;;; interrupt occurs within the window. This can happen on GENCGC
2071 ;;; under the same circumstances, but is more likely due to all GENCGC
2072 ;;; platforms supporting threaded operation. This is somewhat
2073 ;;; mitigated on x86oids due to the conservative stack and interrupt
2074 ;;; context "scavenging" on such platforms, but there still may be a
2075 ;;; vulnerable window.
2078 ;; fixnum
2080 ;; immediate single float, 64-bit only
2083 ;; character
2086 ;; unbound marker
2088 ;; undefined_tramp doesn't validate properly as a pointer, and
2089 ;; the actual value can vary by backend (x86oids need not
2090 ;; apply)
2097 ;; pointer
2104 nil))))
2107 ;; NOTE: The long-float support in here is obviously decayed. When
2108 ;; the x86oid and non-x86oid versions of this function were unified,
2109 ;; the behavior of long-floats was preserved, which only served to
2110 ;; highlight its brokenness.
2114 escaped
2121 escaped
2134 ;; x86oids have no separate number stack, so dummy it
2135 ;; up for them.
2144 #!-alpha
2147 #!+alpha
2179 val)))
2182 val))
2193 #!+long-float
2200 #!+long-float
2211 #!+long-float
2225 #!+long-float
2248 (#.constant-sc-number
2257 ;;; This stores value as the value of DEBUG-VAR in FRAME. In the
2258 ;;; COMPILED-DEBUG-VAR case, access the current value to determine if
2259 ;;; it is an indirect value cell. This occurs when the variable is
2260 ;;; both closed over and set.
2267 new-value)
2269 ;;; This stores VALUE for the variable represented by debug-var
2270 ;;; relative to the frame. This assumes the location directly contains
2271 ;;; the variable's value; that is, there is no indirect value cell
2272 ;;; currently there in case the variable is both closed over and set.
2278 value escaped)
2283 value))))
2286 ;; Like sub-access-debug-var-slot, this is the unification of two
2287 ;; divergent copy-pasted functions. The astute reviewer will notice
2288 ;; that long-floats are messed up here as well, that x86oids
2289 ;; apparently don't support accessing float values that are in
2290 ;; registers, and that non-x86oids store the real part of a float
2291 ;; for both the real and imaginary parts of a complex on the stack
2292 ;; (but not in registers, oddly enough). Some research has
2293 ;; indicated that the different forms of THE used for validating the
2294 ;; type of complex float components between x86oid and non-x86oid
2295 ;; systems are only significant in the case of using a non-complex
2296 ;; number as input (as the non-x86oid case effectively converts
2297 ;; non-complex numbers to complex ones and the x86oid case will
2298 ;; error out). That said, the error message from entering a value
2299 ;; of the wrong type will be slightly easier to understand on x86oid
2300 ;; systems.
2304 escaped
2307 value))
2311 escaped
2315 value))
2328 ;; x86oids have no separate number stack, so dummy it
2329 ;; up for them.
2338 #!-alpha
2340 (* nfp-save-offset
2342 #!+alpha
2345 (* nfp-save-offset
2385 #!+long-float
2406 #!+long-float
2439 #!+long-float
2475 ;;; The method for setting and accessing COMPILED-DEBUG-VAR values use
2476 ;;; this to determine if the value stored is the actual value or an
2477 ;;; indirection cell.
2482 ;;; Return three values reflecting the validity of DEBUG-VAR's value
2483 ;;; at BASIC-CODE-LOCATION:
2484 ;;; :VALID The value is known to be available.
2485 ;;; :INVALID The value is known to be unavailable.
2486 ;;; :UNKNOWN The value's availability is unknown.
2487 ;;;
2488 ;;; If the variable is always alive, then it is valid. If the
2489 ;;; code-location is unknown, then the variable's validity is
2490 ;;; :unknown. Once we've called CODE-LOCATION-UNKNOWN-P, we know the
2491 ;;; live-set information has been cached in the code-location.
2498 ;;; This is the method for DEBUG-VAR-VALIDITY for COMPILED-DEBUG-VARs.
2499 ;;; For safety, make sure basic-code-location is what we think.
2507 :valid
2514 basic-code-location)))))
2517 :debug-var debug-var
2518 :debug-fun
2520 ;; There must be live-set info since basic-code-location is known.
2522 basic-code-location)
2523 pos))
2524 :invalid
2526 \f
2527 ;;;; sources
2529 ;;; This code produces and uses what we call source-paths. A
2530 ;;; source-path is a list whose first element is a form number as
2531 ;;; returned by CODE-LOCATION-FORM-NUMBER and whose last element is a
2532 ;;; top level form number as returned by
2533 ;;; CODE-LOCATION-TOPLEVEL-FORM-NUMBER. The elements from the last to
2534 ;;; the first, exclusively, are the numbered subforms into which to
2535 ;;; descend. For example:
2536 ;;; (defun foo (x)
2537 ;;; (let ((a (aref x 3)))
2538 ;;; (cons a 3)))
2539 ;;; The call to AREF in this example is form number 5. Assuming this
2540 ;;; DEFUN is the 11'th top level form, the source-path for the AREF
2541 ;;; call is as follows:
2542 ;;; (5 1 0 1 3 11)
2543 ;;; Given the DEFUN, 3 gets you the LET, 1 gets you the bindings, 0
2544 ;;; gets the first binding, and 1 gets the AREF form.
2546 ;;; This returns a table mapping form numbers to source-paths. A
2547 ;;; source-path indicates a descent into the TOPLEVEL-FORM form,
2548 ;;; going directly to the subform corressponding to the form number.
2549 ;;;
2550 ;;; The vector elements are in the same format as the compiler's
2551 ;;; NODE-SOURCE-PATH; that is, the first element is the form number and
2552 ;;; the last is the TOPLEVEL-FORM number.
2560 translations)
2581 ;;; FORM is a top level form, and path is a source-path into it. This
2582 ;;; returns the form indicated by the source-path. Context is the
2583 ;;; number of enclosing forms to return instead of directly returning
2584 ;;; the source-path form. When context is non-zero, the form returned
2585 ;;; contains a marker, #:****HERE****, immediately before the form
2586 ;;; indicated by path.
2589 ;; Get to the form indicated by path or the enclosing form indicated
2590 ;; by context and path.
2598 ;; Recursively rebuild the source form resulting from the above
2599 ;; descent, copying the beginning of each subform up to the next
2600 ;; subform we descend into according to path. At the bottom of the
2601 ;; recursion, we return the form indicated by path preceded by our
2602 ;; marker, and this gets spliced into the resulting list structure
2603 ;; on the way back up.
2607 form
2617 ;;; Given a code location, return the associated form-number
2618 ;;; translations and the actual top level form.
2631 ;;; To suppress the read-time evaluation #. macro during source read,
2632 ;;; *READTABLE* is modified.
2633 ;;;
2634 ;;; FIXME: This breaks #+#.(cl:if ...) Maybe we need a SAFE-READ-EVAL, which
2635 ;;; this code can use for side- effect free #. calls?
2636 ;;;
2637 ;;; FIXME: This also knows nothing of custom readtables. The assumption
2638 ;;; is that the current readtable is a decent approximation for what
2639 ;;; we want, but that's lossy.
2647 rt)
2648 rt))
2650 ;;; Locate the source file (if it still exists) and grab the top level
2651 ;;; form. If the file is modified, we use the top level form offset
2652 ;;; instead of the recorded character offset.
2661 local-tlf-offset))
2663 ;; FIXME: External format?
2671 "~%; File has been modified since compilation:~%; ~A~@
2672 ; Using form offset instead of character position.~%"
2673 namestring)
2678 \f
2679 ;;;; PREPROCESS-FOR-EVAL
2681 ;;; Return a function of one argument that evaluates form in the
2682 ;;; lexical context of the BASIC-CODE-LOCATION LOC, or signal a
2683 ;;; NO-DEBUG-VARS condition when the LOC's DEBUG-FUN has no
2684 ;;; DEBUG-VAR information available.
2685 ;;;
2686 ;;; The returned function takes the frame to get values from as its
2687 ;;; argument, and it returns the values of FORM. The returned function
2688 ;;; can signal the following conditions: INVALID-VALUE,
2689 ;;; AMBIGUOUS-VAR-NAME, and FRAME-FUN-MISMATCH.
2704 (:more-context
2706 (:more-count
2722 (:valid
2724 (:more
2728 0
2730 (:unknown
2734 (:ambiguous
2743 ;; This prevents these functions from being used in any
2744 ;; location other than a function return location, so maybe
2745 ;; this should only check whether FRAME's DEBUG-FUN is the
2746 ;; same as LOC's.
2752 ;;; EVAL-IN-FRAME
2756 #!+sb-doc
2757 "Evaluate FORM in the lexical context of FRAME's current code location,
2758 returning the results of the evaluation."
2760 \f
2761 ;;;; breakpoints
2763 ;;;; user-visible interface
2765 ;;; Create and return a breakpoint. When program execution encounters
2766 ;;; the breakpoint, the system calls HOOK-FUN. HOOK-FUN takes the
2767 ;;; current frame for the function in which the program is running and
2768 ;;; the breakpoint object.
2769 ;;;
2770 ;;; WHAT and KIND determine where in a function the system invokes
2771 ;;; HOOK-FUN. WHAT is either a code-location or a DEBUG-FUN. KIND is
2772 ;;; one of :CODE-LOCATION, :FUN-START, or :FUN-END. Since the starts
2773 ;;; and ends of functions may not have code-locations representing
2774 ;;; them, designate these places by supplying WHAT as a DEBUG-FUN and
2775 ;;; KIND indicating the :FUN-START or :FUN-END. When WHAT is a
2776 ;;; DEBUG-FUN and kind is :FUN-END, then HOOK-FUN must take two
2777 ;;; additional arguments, a list of values returned by the function
2778 ;;; and a FUN-END-COOKIE.
2779 ;;;
2780 ;;; INFO is information supplied by and used by the user.
2781 ;;;
2782 ;;; FUN-END-COOKIE is a function. To implement :FUN-END
2783 ;;; breakpoints, the system uses starter breakpoints to establish the
2784 ;;; :FUN-END breakpoint for each invocation of the function. Upon
2785 ;;; each entry, the system creates a unique cookie to identify the
2786 ;;; invocation, and when the user supplies a function for this
2787 ;;; argument, the system invokes it on the frame and the cookie. The
2788 ;;; system later invokes the :FUN-END breakpoint hook on the same
2789 ;;; cookie. The user may save the cookie for comparison in the hook
2790 ;;; function.
2791 ;;;
2792 ;;; Signal an error if WHAT is an unknown code-location.
2799 what))
2804 ;; This slot is filled in due to calling CODE-LOCATION-UNKNOWN-P.
2807 :unknown-return-partner
2808 info)))
2811 ;; (There used to be more cases back before sbcl-0.7.0,,
2812 ;; when we did special tricks to debug the IR1
2813 ;; interpreter.)
2814 )
2815 bpt))
2818 (:fun-start
2820 (:fun-end
2837 bpt))))))
2839 ;;; These are unique objects created upon entry into a function by a
2840 ;;; :FUN-END breakpoint's starter hook. These are only created
2841 ;;; when users supply :FUN-END-COOKIE to MAKE-BREAKPOINT. Also,
2842 ;;; the :FUN-END breakpoint's hook is called on the same cookie
2843 ;;; when it is created.
2849 ;; a pointer to the bogus-lra created for :FUN-END breakpoints
2850 bogus-lra
2851 ;; the DEBUG-FUN associated with this cookie
2852 debug-fun)
2854 ;;; This maps bogus-lra-components to cookies, so that
2855 ;;; HANDLE-FUN-END-BREAKPOINT can find the appropriate cookie for the
2856 ;;; breakpoint hook.
2859 ;;; This returns a hook function for the start helper breakpoint
2860 ;;; associated with a :FUN-END breakpoint. The returned function
2861 ;;; makes a fake LRA that all returns go through, and this piece of
2862 ;;; fake code actually breaks. Upon return from the break, the code
2863 ;;; provides the returnee with any values. Since the returned function
2864 ;;; effectively activates FUN-END-BPT on each entry to DEBUG-FUN's
2865 ;;; function, we must establish breakpoint-data about FUN-END-BPT.
2873 #!-fp-and-pc-standard-save
2876 #!+fp-and-pc-standard-save
2881 lra-save-offset
2882 lra-sc-offset))
2884 lra-save-offset
2885 lra-sc-offset)
2886 lra)
2898 ;;; This takes a FUN-END-COOKIE and a frame, and it returns
2899 ;;; whether the cookie is still valid. A cookie becomes invalid when
2900 ;;; the frame that established the cookie has exited. Sometimes cookie
2901 ;;; holders are unaware of cookie invalidation because their
2902 ;;; :FUN-END breakpoint hooks didn't run due to THROW'ing.
2903 ;;;
2904 ;;; This takes a frame as an efficiency hack since the user probably
2905 ;;; has a frame object in hand when using this routine, and it saves
2906 ;;; repeated parsing of the stack and consing when asking whether a
2907 ;;; series of cookies is valid.
2911 #!-fp-and-pc-standard-save
2915 #!+fp-and-pc-standard-save
2921 lra
2924 \f
2925 ;;;; ACTIVATE-BREAKPOINT
2927 ;;; Cause the system to invoke the breakpoint's hook function until
2928 ;;; the next call to DEACTIVATE-BREAKPOINT or DELETE-BREAKPOINT. The
2929 ;;; system invokes breakpoint hook functions in the opposite order
2930 ;;; that you activate them.
2936 (:code-location
2944 ;; (There used to be more cases back before sbcl-0.7.0, when
2945 ;; we did special tricks to debug the IR1 interpreter.)
2946 )))
2947 (:fun-start
2951 ;; (There used to be more cases back before sbcl-0.7.0, when
2952 ;; we did special tricks to debug the IR1 interpreter.)
2953 ))
2954 (:fun-end
2959 ;; may already be active by some other :FUN-END breakpoint
2962 ;; (There used to be more cases back before sbcl-0.7.0, when
2963 ;; we did special tricks to debug the IR1 interpreter.)
2964 ))))
2965 breakpoint)
2972 breakpoint
2987 breakpoint
2991 debug-fun))))))
3007 \f
3008 ;;;; DEACTIVATE-BREAKPOINT
3010 ;;; Stop the system from invoking the breakpoint's hook function.
3021 ;; (There used to be more cases back before sbcl-0.7.0, when
3022 ;; we did special tricks to debug the IR1 interpreter.)
3023 ))))
3024 breakpoint)
3046 breakpoint)
3047 \f
3048 ;;;; BREAKPOINT-INFO
3050 ;;; Return the user-maintained info associated with breakpoint. This
3051 ;;; is SETF'able.
3059 \f
3060 ;;;; BREAKPOINT-ACTIVE-P and DELETE-BREAKPOINT
3067 ;;; Free system storage and remove computational overhead associated
3068 ;;; with breakpoint. After calling this, breakpoint is completely
3069 ;;; impotent and can never become active again.
3088 nil))))))
3089 breakpoint)
3090 \f
3091 ;;;; C call out stubs
3093 ;;; This actually installs the break instruction in the component. It
3094 ;;; returns the overwritten bits. You must call this in a context in
3095 ;;; which GC is disabled, so that Lisp doesn't move objects around
3096 ;;; that C is pointing to.
3101 ;;; This removes the break instruction and replaces the original
3102 ;;; instruction. You must call this in a context in which GC is disabled
3103 ;;; so Lisp doesn't move objects around that C is pointing to.
3113 ;;;; breakpoint handlers (layer between C and exported interface)
3115 ;;; This maps components to a mapping of offsets to BREAKPOINT-DATAs.
3118 ;;; This returns the BREAKPOINT-DATA object associated with component cross
3119 ;;; offset. If none exists, this makes one, installs it, and returns it.
3126 data))))
3135 ;;; We use this when there are no longer any active breakpoints
3136 ;;; corresponding to DATA.
3138 ;; Again, this looks brittle. Is there no danger of being interrupted
3139 ;; here?
3149 ;;; The C handler for interrupts calls this when it has a
3150 ;;; debugging-tool break instruction. This does *not* handle all
3151 ;;; breaks; for example, it does not handle breaks for internal
3152 ;;; errors.
3158 offset))
3164 offset component signal-context)))))
3166 ;;; This holds breakpoint-datas while invoking the breakpoint hooks
3167 ;;; associated with that particular component and location. While they
3168 ;;; are executing, if we hit the location again, we ignore the
3169 ;;; breakpoint to avoid infinite recursion. fun-end breakpoints
3170 ;;; must work differently since the breakpoint-data is unique for each
3171 ;;; invocation.
3174 ;;; This handles code-location and DEBUG-FUN :FUN-START
3175 ;;; breakpoints.
3183 ;; At this point breakpoints may not hold the same list as
3184 ;; BREAKPOINT-DATA-BREAKPOINTS since invoking hooks may have allowed
3185 ;; a breakpoint deactivation. In fact, if all breakpoints were
3186 ;; deactivated then data is invalid since it was deleted and so the
3187 ;; correct one must be looked up if it is to be used. If there are
3188 ;; no more breakpoints active at this location, then the normal
3189 ;; instruction has been put back, and we do not need to
3190 ;; DO-DISPLACED-INST.
3193 ;; The breakpoint is still active, so we need to execute the
3194 ;; displaced instruction and leave the breakpoint instruction
3195 ;; behind. The best way to do this is different on each machine,
3196 ;; so we just leave it up to the C code.
3199 ;; Some platforms have no usable sigreturn() call. If your
3200 ;; implementation of arch_do_displaced_inst() _does_ sigreturn(),
3201 ;; it's polite to warn here
3209 frame
3210 ;; If this is an :UNKNOWN-RETURN-PARTNER, then pass the
3211 ;; hook function the original breakpoint, so that users
3212 ;; aren't forced to confront the fact that some
3213 ;; breakpoints really are two.
3216 bpt)))))
3225 ;; KLUDGE: This argument is ignored on
3226 ;; x86oids in this scenario, but is
3227 ;; declared to be a SAP.
3230 nil)))
3237 offset))
3243 ;;; Either HANDLE-BREAKPOINT calls this for :FUN-END breakpoints
3244 ;;; [old C code] or HANDLE-FUN-END-BREAKPOINT calls this directly
3245 ;;; [new C code].
3247 ;; FIXME: This looks brittle: what if we are interrupted somewhere
3248 ;; here? ...or do we have interrupts disabled here?
3260 frame bpt
3262 cookie))))
3266 scp
3280 results)))
3282 \f
3283 ;;;; MAKE-BOGUS-LRA (used for :FUN-END breakpoints)
3288 ;; One more for a fixup vector
3291 ;;; Make a bogus LRA object that signals a breakpoint trap when
3292 ;;; returned to. If the breakpoint trap handler returns, REAL-LRA is
3293 ;;; returned to. Three values are returned: the bogus LRA object, the
3294 ;;; code component it is part of, and the PC offset for the trap
3295 ;;; instruction.
3298 ;; These are really code labels, not variables: but this way we get
3299 ;; their addresses.
3308 src-start src-end dst-start trap-loc)
3313 ;; Set up the widetag and header of LRA
3314 ;; The header contains the same thing as the code object header,
3315 ;; the number of boxed words, which include slots and
3316 ;; constants and it has to be double word aligned.
3317 ;;
3318 ;; It used to be a part of the fun_end_breakpoint_guts
3319 ;; but its position and value depend on the offsets
3320 ;; and alignment of code object slots.
3324 bogus-lra-constants
3339 ;; We used to set the header value of the LRA here to the
3340 ;; offset from the enclosing component to the LRA header, but
3341 ;; MAKE-LISP-OBJ actually checks the value before we get a
3342 ;; chance to set it, so it's now done in arch-assem.S.
3344 \f
3345 ;;;; miscellaneous
3347 ;;; This appears here because it cannot go with the DEBUG-FUN
3348 ;;; interface since DO-DEBUG-BLOCK-LOCATIONS isn't defined until after
3349 ;;; the DEBUG-FUN routines.
3351 ;;; Return a code-location before the body of a function and after all
3352 ;;; the arguments are in place; or if that location can't be
3353 ;;; determined due to a lack of debug information, return NIL.
3360 debug-fun))
3361 nil))
3362 ;; (There used to be more cases back before sbcl-0.7.0, when
3363 ;; we did special tricks to debug the IR1 interpreter.)
3364 ))
3366 \f
3367 ;;;; Single-stepping
3369 ;;; The single-stepper works by inserting conditional trap instructions
3370 ;;; into the generated code (see src/compiler/*/call.lisp), currently:
3371 ;;;
3372 ;;; 1) Before the code generated for a function call that was
3373 ;;; translated to a VOP
3374 ;;; 2) Just before the call instruction for a full call
3375 ;;;
3376 ;;; In both cases, the trap will only be executed if stepping has been
3377 ;;; enabled, in which case it'll ultimately be handled by
3378 ;;; HANDLE-SINGLE-STEP-TRAP, which will either signal a stepping condition,
3379 ;;; or replace the function that's about to be called with a wrapper
3380 ;;; which will signal the condition.
3384 ;; The following calls must get tail-call eliminated for
3385 ;; *STEP-FRAME* to get set correctly on non-x86.
3394 ;; If there was not enough debug information available, there's no
3395 ;; sense in signaling the condition.
3401 ;; KLUDGE: Use the first non-foreign frame as the
3402 ;; *STACK-TOP-HINT*. Getting the frame from the signal
3403 ;; context as on x86 would be cleaner, but
3404 ;; SIGNAL-CONTEXT-FRAME doesn't seem seem to work at all
3405 ;; on non-x86.
3407 while frame
3413 ;; We could theoretically store information in
3414 ;; the debug-info about to determine the
3415 ;; arguments here, but for now let's just pass
3416 ;; on it.
3419 ;;; This function will replace the fdefn / function that was in the
3420 ;;; register at CALLEE-REGISTER-OFFSET with a wrapper function. To
3421 ;;; ensure that the full call will use the wrapper instead of the
3422 ;;; original, conditional trap must be emitted before the fdefn /
3423 ;;; function is converted into a raw address.
3425 ;; Fetch the function / fdefn we're about to call from the
3426 ;; appropriate register.
3430 ;; If there was not enough debug information available, there's no
3431 ;; sense in signaling the condition.
3439 args)))
3440 ;; Signal a step condition
3444 ;; And proceed based on its return value.
3446 ;; STEP-INTO was selected. Use *STEP-OUT* to
3447 ;; let the stepper know that selecting the
3448 ;; STEP-OUT restart is valid inside this
3450 ;; Pass the return values of the call to
3451 ;; STEP-VALUES, which will signal a
3452 ;; condition with them in the VALUES slot.
3455 step-info
3457 ;; If the user selected the STEP-OUT
3458 ;; restart during the call, resume
3459 ;; stepping
3462 ;; STEP-NEXT / CONTINUE / OUT selected:
3463 ;; Disable the stepper for the duration of
3464 ;; the call.
3471 fdefn))
3473 ;; And then store the wrapper in the same place.
3475 ;; %SET-CONTEXT-REGISTER is a function, so the address of
3476 ;; NEW-CALLEE gets converted to a fixnum before passing, which
3477 ;; won't keep NEW-CALLEE pinned down. Once it's inside
3478 ;; CONTEXT, which is registered in thread->interrupt_contexts,
3479 ;; it will properly point to NEW-CALLEE.
3483 ;;; Given a signal context, fetch the step-info that's been stored in
3484 ;;; the debug info at the trap point.
3490 pc-offset
3491 nil)))
3498 nil)))))
3500 ;;; Return the frame that triggered a single-step condition. Used to
3501 ;;; provide a *STACK-TOP-HINT*.