| blob | 6ff6e00098263b77ccb7b9c8a96cd5c6532c1a30 |
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.
1274 ;; Return the name of the closure, if named, otherwise nil.
1284 #!+precise-arg-count-error
1290 closure-save))
1291 #!-precise-arg-count-error
1293 closure-save))))
1295 ;; The logic in CLEAN-FRAME-CALL is based on the frame name,
1296 ;; so if the simple-fun is named (XEP mumble) then the closure
1297 ;; needs to pretend to be named similarly.
1303 closure-name))))))))
1305 ;;; Return a DEBUG-FUN that represents debug information for FUN.
1320 ;; KLUDGE: comment from CMU CL:
1321 ;; This used to be the non-interpreted branch, but
1322 ;; William wrote it to return the debug-fun of fun's XEP
1323 ;; instead of fun's debug-fun. The above code does this
1324 ;; more correctly, but it doesn't get or eliminate all
1325 ;; appropriate cases. It mostly works, and probably
1326 ;; works for all named functions anyway.
1327 ;; -- WHN 20000120
1333 ;;; Return the kind of the function, which is one of :OPTIONAL,
1334 ;;; :EXTERNAL, :TOPLEVEL, :CLEANUP, or NIL.
1336 ;; FIXME: This "is one of" information should become part of the function
1337 ;; declamation, not just a doc string
1343 nil)))
1345 ;;; Is there any variable information for DEBUG-FUN?
1349 ;;; Return a list of DEBUG-VARs in DEBUG-FUN having the same name
1350 ;;; and package as SYMBOL. If SYMBOL is uninterned, then this returns
1351 ;;; a list of DEBUG-VARs without package names and with the same name
1352 ;;; as symbol. The result of this function is limited to the
1353 ;;; availability of variable information in DEBUG-FUN; for
1354 ;;; example, possibly DEBUG-FUN only knows about its arguments.
1366 vars)))
1368 ;;; Return a list of DEBUG-VARs in DEBUG-FUN whose names contain
1369 ;;; NAME-PREFIX-STRING as an initial substring. The result of this
1370 ;;; function is limited to the availability of variable information in
1371 ;;; debug-fun; for example, possibly debug-fun only knows
1372 ;;; about its arguments.
1383 ;; Find names from pos to variable's len that contain prefix.
1392 prefix-len)
1393 prefix-len)
1397 res))))
1399 ;;; This returns a position in VARIABLES for one containing NAME as an
1400 ;;; initial substring. END is the length of VARIABLES if supplied.
1414 ;;; Return a list representing the lambda-list for DEBUG-FUN. The
1415 ;;; list has the following structure:
1416 ;;; (required-var1 required-var2
1417 ;;; ...
1418 ;;; (:optional var3 suppliedp-var4)
1419 ;;; (:optional var5)
1420 ;;; ...
1421 ;;; (:rest var6) (:rest var7)
1422 ;;; ...
1423 ;;; (:keyword keyword-symbol var8 suppliedp-var9)
1424 ;;; (:keyword keyword-symbol var10)
1425 ;;; ...
1426 ;;; )
1427 ;;; Each VARi is a DEBUG-VAR; however it may be the symbol :DELETED if
1428 ;;; it is unreferenced in DEBUG-FUN. This signals a
1429 ;;; LAMBDA-LIST-UNAVAILABLE condition when there is no argument list
1430 ;;; information.
1436 ;;; Note: If this has to compute the lambda list, it caches it in DEBUG-FUN.
1444 args
1449 nil)
1452 ;; If the packed information is there (whether empty or not) as
1453 ;; opposed to being nil, then returned our cached value (nil).
1454 nil)
1456 ;; Our cached value is nil, and the packed lambda-list information
1457 ;; is nil, so we don't have anything available.
1461 ;;; COMPILED-DEBUG-FUN-LAMBDA-LIST calls this when a
1462 ;;; COMPILED-DEBUG-FUN has no lambda list information cached. It
1463 ;;; returns the lambda list as the first value and whether there was
1464 ;;; any argument information as the second value. Therefore,
1465 ;;; (VALUES NIL T) means there were no arguments, but (VALUES NIL NIL)
1466 ;;; means there was no argument information.
1475 t))
1490 ;; Deleted required arg at beginning of args array.
1495 ;; SUPPLIED-P var immediately following keyword or
1496 ;; optional. Stick the extra var in the result
1497 ;; element representing the keyword or optional,
1498 ;; which is the previous one.
1499 ;;
1500 ;; FIXME: NCONC used for side-effect: the effect is defined,
1501 ;; but this is bad style no matter what.
1509 res))
1511 ;; The next two args are the &MORE arg context and count.
1517 res))
1519 ;; &KEY arg
1521 ele
1524 res))))
1526 ;; We saw an optional marker, so the following
1527 ;; non-symbols are indexes indicating optional
1528 ;; variables.
1531 ;; Required arg at beginning of args array.
1536 ;;; This is used in COMPILED-DEBUG-FUN-LAMBDA-LIST.
1547 \f
1548 ;;;; unpacking variable and basic block data
1554 ;;; PARSE-DEBUG-BLOCKS and PARSE-DEBUG-VARS
1555 ;;; use this to unpack binary encoded information. It returns the
1556 ;;; values returned by the last form in body.
1557 ;;;
1558 ;;; This binds buffer-var to *parsing-buffer*, makes sure it starts at
1559 ;;; element zero, and makes sure if we unwind, we nil out any set
1560 ;;; elements for GC purposes.
1561 ;;;
1562 ;;; This also binds other-var to *other-parsing-buffer* when it is
1563 ;;; supplied, making sure it starts at element zero and that we nil
1564 ;;; out any elements if we unwind.
1565 ;;;
1566 ;;; This defines the local macro RESULT that takes a buffer, copies
1567 ;;; its elements to a resulting simple-vector, nil's out elements, and
1568 ;;; restarts the buffer at element zero. RESULT returns the
1569 ;;; simple-vector.
1592 ;;; The argument is a debug internals structure. This returns the
1593 ;;; DEBUG-BLOCKs for DEBUG-FUN, regardless of whether we have unpacked
1594 ;;; them yet. It signals a NO-DEBUG-BLOCKS condition if it can't
1595 ;;; return the blocks.
1610 ;;; Return a SIMPLE-VECTOR of DEBUG-BLOCKs or NIL. NIL indicates there
1611 ;;; was no basic block information.
1619 ;;; This does some of the work of PARSE-DEBUG-BLOCKS.
1623 debug-fun))
1625 ;; KLUDGE: 8 is a hard-wired constant in the compiler for the
1626 ;; element size of the packed binary representation of the
1627 ;; blocks data.
1650 live-set-len blocks i))
1653 pc debug-fun block tlf-offset
1654 form-number live-set kind
1655 step-info)
1656 locations-buffer)
1665 ;;; The argument is a debug internals structure. This returns NIL if
1666 ;;; there is no variable information. It returns an empty
1667 ;;; simple-vector if there were no locals in the function. Otherwise
1668 ;;; it returns a SIMPLE-VECTOR of DEBUG-VARs.
1677 vars)))
1679 ;;; VARS is the parsed variables for a minimal debug function. We need
1680 ;;; to assign names of the form ARG-NNN. We must pad with leading
1681 ;;; zeros, since the arguments must be in alphabetical order.
1690 ;; The cross-compiler won't dump literal package
1691 ;; references because the target package objects
1692 ;; aren't created until partway through
1693 ;; cold-init. In lieu of adding smarts to the
1694 ;; build framework to handle this, we use an
1695 ;; explicit load-time-value form.
1698 ;;; Parse the packed representation of DEBUG-VARs from
1699 ;;; DEBUG-FUN's SB!C::COMPILED-DEBUG-FUN, returning a vector
1700 ;;; of DEBUG-VARs, or NIL if there was no information to parse.
1703 debug-fun))
1714 result))
1723 flags))
1735 id
1736 live
1737 sc-offset
1738 save-sc-offset
1739 indirect-sc-offset
1742 buffer)))))))
1743 \f
1744 ;;;; CODE-LOCATIONs
1746 ;;; If we're sure of whether code-location is known, return T or NIL.
1747 ;;; If we're :UNSURE, then try to fill in the code-location's slots.
1748 ;;; This determines whether there is any debug-block information, and
1749 ;;; if code-location is known.
1750 ;;;
1751 ;;; ??? IF this conses closures every time it's called, then break off the
1752 ;;; :UNSURE part to get the HANDLER-CASE into another function.
1757 (:unsure
1762 ;;; Return the DEBUG-BLOCK containing code-location if it is available.
1763 ;;; Some debug policies inhibit debug-block information, and if none
1764 ;;; is available, then this signals a NO-DEBUG-BLOCKS condition.
1771 ;; (There used to be more cases back before sbcl-0.7.0, when
1772 ;; we did special tricks to debug the IR1 interpreter.)
1773 )
1774 block)))
1776 ;;; Store and return BASIC-CODE-LOCATION's debug-block. We determines
1777 ;;; the correct one using the code-location's pc. We use
1778 ;;; DEBUG-FUN-DEBUG-BLOCKS to return the cached block information
1779 ;;; or signal a NO-DEBUG-BLOCKS condition. The blocks are sorted by
1780 ;;; their first code-location's pc, in ascending order. Therefore, as
1781 ;;; soon as we find a block that starts with a pc greater than
1782 ;;; basic-code-location's pc, we know the previous block contains the
1783 ;;; pc. If we get to the last block, then the code-location is either
1784 ;;; in the second to last block or the last block, and we have to be
1785 ;;; careful in determining this since the last block could be code at
1786 ;;; the end of the function. We have to check for the last block being
1787 ;;; code first in order to see how to compare the code-location's pc.
1791 basic-code-location))
1807 debug-fun)))
1809 last))
1810 ((< pc
1824 ;;; Return the CODE-LOCATION's DEBUG-SOURCE.
1832 ;;; Returns the number of top level forms before the one containing
1833 ;;; CODE-LOCATION as seen by the compiler in some compilation unit. (A
1834 ;;; compilation unit is not necessarily a single file, see the section
1835 ;;; on debug-sources.)
1844 ;; This check should be unnecessary. We're missing
1845 ;; debug info the compiler should have dumped.
1848 ;; (There used to be more cases back before sbcl-0.7.0,,
1849 ;; when we did special tricks to debug the IR1
1850 ;; interpreter.)
1851 ))
1854 ;;; Return the number of the form corresponding to CODE-LOCATION. The
1855 ;;; form number is derived by a walking the subforms of a top level
1856 ;;; form in depth-first order.
1865 ;; This check should be unnecessary. We're missing
1866 ;; debug info the compiler should have dumped.
1869 ;; (There used to be more cases back before sbcl-0.7.0,,
1870 ;; when we did special tricks to debug the IR1
1871 ;; interpreter.)
1872 ))
1875 ;;; Return the kind of CODE-LOCATION, one of:
1876 ;;; :INTERPRETED, :UNKNOWN-RETURN, :KNOWN-RETURN, :INTERNAL-ERROR,
1877 ;;; :NON-LOCAL-EXIT, :BLOCK-START, :CALL-SITE, :SINGLE-VALUE-RETURN,
1878 ;;; :NON-LOCAL-ENTRY
1887 ;; This check should be unnecessary. We're missing
1888 ;; debug info the compiler should have dumped.
1892 ;; (There used to be more cases back before sbcl-0.7.0,,
1893 ;; when we did special tricks to debug the IR1
1894 ;; interpreter.)
1895 ))
1897 ;;; This returns CODE-LOCATION's live-set if it is available. If
1898 ;;; there is no debug-block information, this returns NIL.
1901 nil
1905 ;; This check should be unnecessary. We're missing
1906 ;; debug info the compiler should have dumped.
1907 ;;
1908 ;; FIXME: This error and comment happen over and over again.
1909 ;; Make them a shared function.
1914 ;;; true if OBJ1 and OBJ2 are the same place in the code
1923 ;; (There used to be more cases back before sbcl-0.7.0,,
1924 ;; when we did special tricks to debug the IR1
1925 ;; interpreter.)
1926 ))
1927 ;; (There used to be more cases back before sbcl-0.7.0,,
1928 ;; when we did special tricks to debug IR1-interpreted code.)
1929 ))
1934 ;;; Fill in CODE-LOCATION's :UNPARSED slots, returning T or NIL
1935 ;;; depending on whether the code-location was known in its
1936 ;;; DEBUG-FUN's debug-block information. This may signal a
1937 ;;; NO-DEBUG-BLOCKS condition due to DEBUG-FUN-DEBUG-BLOCKS, and
1938 ;;; it assumes the %UNKNOWN-P slot is already set or going to be set.
1963 \f
1964 ;;;; operations on DEBUG-BLOCKs
1966 ;;; Execute FORMS in a context with CODE-VAR bound to each
1967 ;;; CODE-LOCATION in DEBUG-BLOCK, and return the value of RESULT.
1978 ;;; Return the name of the function represented by DEBUG-FUN.
1979 ;;; This may be a string or a cons; do not assume it is a symbol.
1986 "??? Can't get name of debug-block's function."
1989 ;; (There used to be more cases back before sbcl-0.7.0, when we
1990 ;; did special tricks to debug the IR1 interpreter.)
1991 ))
1997 ;; (There used to be more cases back before sbcl-0.7.0, when we
1998 ;; did special tricks to debug the IR1 interpreter.)
1999 ))
2000 \f
2001 ;;;; operations on debug variables
2006 ;;; FIXME: Make sure that this isn't called anywhere that it wouldn't
2007 ;;; be acceptable to have NIL returned, or that it's only called on
2008 ;;; DEBUG-VARs whose symbols have non-NIL packages.
2012 ;;; Return the value stored for DEBUG-VAR in frame, or if the value is
2013 ;;; not :VALID, then signal an INVALID-VALUE error.
2020 ;;; Returns the value stored for DEBUG-VAR in frame. The value may be
2021 ;;; invalid. This is SETFable.
2027 res)))
2029 ;;; This returns what is stored for the variable represented by
2030 ;;; DEBUG-VAR relative to the FRAME. This may be an indirect value
2031 ;;; cell if the variable is both closed over and set.
2036 ;; Indirect are accessed through a frame pointer of the parent.
2045 escaped))
2047 escaped))
2052 escaped))
2059 ;;; a helper function for working with possibly-invalid values:
2060 ;;; Do (%MAKE-LISP-OBJ VAL) only if the value looks valid.
2061 ;;;
2062 ;;; (Such values can arise in registers on machines with conservative
2063 ;;; GC, and might also arise in debug variable locations when
2064 ;;; those variables are invalid.)
2065 ;;;
2066 ;;; NOTE: this function is not GC-safe in the slightest when creating
2067 ;;; a pointer to an object in dynamic space. If a GC occurs between
2068 ;;; the start of the call to VALID-LISP-POINTER-P and the end of
2069 ;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
2070 ;;; is constructed. This can happen on CHENEYGC if an asynchronous
2071 ;;; interrupt occurs within the window. This can happen on GENCGC
2072 ;;; under the same circumstances, but is more likely due to all GENCGC
2073 ;;; platforms supporting threaded operation. This is somewhat
2074 ;;; mitigated on x86oids due to the conservative stack and interrupt
2075 ;;; context "scavenging" on such platforms, but there still may be a
2076 ;;; vulnerable window.
2079 ;; fixnum
2081 ;; immediate single float, 64-bit only
2084 ;; character
2087 ;; unbound marker
2089 ;; undefined_tramp doesn't validate properly as a pointer, and
2090 ;; the actual value can vary by backend (x86oids need not
2091 ;; apply)
2098 ;; pointer
2105 nil))))
2108 ;; NOTE: The long-float support in here is obviously decayed. When
2109 ;; the x86oid and non-x86oid versions of this function were unified,
2110 ;; the behavior of long-floats was preserved, which only served to
2111 ;; highlight its brokenness.
2115 escaped
2122 escaped
2135 ;; x86oids have no separate number stack, so dummy it
2136 ;; up for them.
2145 #!-alpha
2148 #!+alpha
2180 val)))
2183 val))
2194 #!+long-float
2201 #!+long-float
2212 #!+long-float
2226 #!+long-float
2249 (#.constant-sc-number
2258 ;;; This stores value as the value of DEBUG-VAR in FRAME. In the
2259 ;;; COMPILED-DEBUG-VAR case, access the current value to determine if
2260 ;;; it is an indirect value cell. This occurs when the variable is
2261 ;;; both closed over and set.
2268 new-value)
2270 ;;; This stores VALUE for the variable represented by debug-var
2271 ;;; relative to the frame. This assumes the location directly contains
2272 ;;; the variable's value; that is, there is no indirect value cell
2273 ;;; currently there in case the variable is both closed over and set.
2279 value escaped)
2284 value))))
2287 ;; Like sub-access-debug-var-slot, this is the unification of two
2288 ;; divergent copy-pasted functions. The astute reviewer will notice
2289 ;; that long-floats are messed up here as well, that x86oids
2290 ;; apparently don't support accessing float values that are in
2291 ;; registers, and that non-x86oids store the real part of a float
2292 ;; for both the real and imaginary parts of a complex on the stack
2293 ;; (but not in registers, oddly enough). Some research has
2294 ;; indicated that the different forms of THE used for validating the
2295 ;; type of complex float components between x86oid and non-x86oid
2296 ;; systems are only significant in the case of using a non-complex
2297 ;; number as input (as the non-x86oid case effectively converts
2298 ;; non-complex numbers to complex ones and the x86oid case will
2299 ;; error out). That said, the error message from entering a value
2300 ;; of the wrong type will be slightly easier to understand on x86oid
2301 ;; systems.
2305 escaped
2308 value))
2312 escaped
2316 value))
2329 ;; x86oids have no separate number stack, so dummy it
2330 ;; up for them.
2339 #!-alpha
2341 (* nfp-save-offset
2343 #!+alpha
2346 (* nfp-save-offset
2386 #!+long-float
2407 #!+long-float
2440 #!+long-float
2476 ;;; The method for setting and accessing COMPILED-DEBUG-VAR values use
2477 ;;; this to determine if the value stored is the actual value or an
2478 ;;; indirection cell.
2483 ;;; Return three values reflecting the validity of DEBUG-VAR's value
2484 ;;; at BASIC-CODE-LOCATION:
2485 ;;; :VALID The value is known to be available.
2486 ;;; :INVALID The value is known to be unavailable.
2487 ;;; :UNKNOWN The value's availability is unknown.
2488 ;;;
2489 ;;; If the variable is always alive, then it is valid. If the
2490 ;;; code-location is unknown, then the variable's validity is
2491 ;;; :unknown. Once we've called CODE-LOCATION-UNKNOWN-P, we know the
2492 ;;; live-set information has been cached in the code-location.
2499 ;;; This is the method for DEBUG-VAR-VALIDITY for COMPILED-DEBUG-VARs.
2500 ;;; For safety, make sure basic-code-location is what we think.
2508 :valid
2515 basic-code-location)))))
2518 :debug-var debug-var
2519 :debug-fun
2521 ;; There must be live-set info since basic-code-location is known.
2523 basic-code-location)
2524 pos))
2525 :invalid
2527 \f
2528 ;;;; sources
2530 ;;; This code produces and uses what we call source-paths. A
2531 ;;; source-path is a list whose first element is a form number as
2532 ;;; returned by CODE-LOCATION-FORM-NUMBER and whose last element is a
2533 ;;; top level form number as returned by
2534 ;;; CODE-LOCATION-TOPLEVEL-FORM-NUMBER. The elements from the last to
2535 ;;; the first, exclusively, are the numbered subforms into which to
2536 ;;; descend. For example:
2537 ;;; (defun foo (x)
2538 ;;; (let ((a (aref x 3)))
2539 ;;; (cons a 3)))
2540 ;;; The call to AREF in this example is form number 5. Assuming this
2541 ;;; DEFUN is the 11'th top level form, the source-path for the AREF
2542 ;;; call is as follows:
2543 ;;; (5 1 0 1 3 11)
2544 ;;; Given the DEFUN, 3 gets you the LET, 1 gets you the bindings, 0
2545 ;;; gets the first binding, and 1 gets the AREF form.
2547 ;;; This returns a table mapping form numbers to source-paths. A
2548 ;;; source-path indicates a descent into the TOPLEVEL-FORM form,
2549 ;;; going directly to the subform corressponding to the form number.
2550 ;;;
2551 ;;; The vector elements are in the same format as the compiler's
2552 ;;; NODE-SOURCE-PATH; that is, the first element is the form number and
2553 ;;; the last is the TOPLEVEL-FORM number.
2554 ;;;
2555 ;;; This should be synchronized with SB-C::SUB-FIND-SOURCE-PATHS
2563 translations)
2577 ;; Don't look into quoted constants.
2589 ;;; FORM is a top level form, and path is a source-path into it. This
2590 ;;; returns the form indicated by the source-path. Context is the
2591 ;;; number of enclosing forms to return instead of directly returning
2592 ;;; the source-path form. When context is non-zero, the form returned
2593 ;;; contains a marker, #:****HERE****, immediately before the form
2594 ;;; indicated by path.
2597 ;; Get to the form indicated by path or the enclosing form indicated
2598 ;; by context and path.
2606 ;; Recursively rebuild the source form resulting from the above
2607 ;; descent, copying the beginning of each subform up to the next
2608 ;; subform we descend into according to path. At the bottom of the
2609 ;; recursion, we return the form indicated by path preceded by our
2610 ;; marker, and this gets spliced into the resulting list structure
2611 ;; on the way back up.
2615 form
2625 ;;; Given a code location, return the associated form-number
2626 ;;; translations and the actual top level form.
2639 ;;; To suppress the read-time evaluation #. macro during source read,
2640 ;;; *READTABLE* is modified.
2641 ;;;
2642 ;;; FIXME: This breaks #+#.(cl:if ...) Maybe we need a SAFE-READ-EVAL, which
2643 ;;; this code can use for side- effect free #. calls?
2644 ;;;
2645 ;;; FIXME: This also knows nothing of custom readtables. The assumption
2646 ;;; is that the current readtable is a decent approximation for what
2647 ;;; we want, but that's lossy.
2655 rt)
2656 rt))
2658 ;;; Locate the source file (if it still exists) and grab the top level
2659 ;;; form. If the file is modified, we use the top level form offset
2660 ;;; instead of the recorded character offset.
2669 local-tlf-offset))
2671 ;; FIXME: External format?
2679 "~%; File has been modified since compilation:~%; ~A~@
2680 ; Using form offset instead of character position.~%"
2681 namestring)
2686 \f
2687 ;;;; PREPROCESS-FOR-EVAL
2689 ;;; Return a function of one argument that evaluates form in the
2690 ;;; lexical context of the BASIC-CODE-LOCATION LOC, or signal a
2691 ;;; NO-DEBUG-VARS condition when the LOC's DEBUG-FUN has no
2692 ;;; DEBUG-VAR information available.
2693 ;;;
2694 ;;; The returned function takes the frame to get values from as its
2695 ;;; argument, and it returns the values of FORM. The returned function
2696 ;;; can signal the following conditions: INVALID-VALUE,
2697 ;;; AMBIGUOUS-VAR-NAME, and FRAME-FUN-MISMATCH.
2712 (:more-context
2714 (:more-count
2730 (:valid
2732 (:more
2736 0
2738 (:unknown
2742 (:ambiguous
2751 ;; This prevents these functions from being used in any
2752 ;; location other than a function return location, so maybe
2753 ;; this should only check whether FRAME's DEBUG-FUN is the
2754 ;; same as LOC's.
2760 ;;; EVAL-IN-FRAME
2764 #!+sb-doc
2765 "Evaluate FORM in the lexical context of FRAME's current code location,
2766 returning the results of the evaluation."
2768 \f
2769 ;;;; breakpoints
2771 ;;;; user-visible interface
2773 ;;; Create and return a breakpoint. When program execution encounters
2774 ;;; the breakpoint, the system calls HOOK-FUN. HOOK-FUN takes the
2775 ;;; current frame for the function in which the program is running and
2776 ;;; the breakpoint object.
2777 ;;;
2778 ;;; WHAT and KIND determine where in a function the system invokes
2779 ;;; HOOK-FUN. WHAT is either a code-location or a DEBUG-FUN. KIND is
2780 ;;; one of :CODE-LOCATION, :FUN-START, or :FUN-END. Since the starts
2781 ;;; and ends of functions may not have code-locations representing
2782 ;;; them, designate these places by supplying WHAT as a DEBUG-FUN and
2783 ;;; KIND indicating the :FUN-START or :FUN-END. When WHAT is a
2784 ;;; DEBUG-FUN and kind is :FUN-END, then HOOK-FUN must take two
2785 ;;; additional arguments, a list of values returned by the function
2786 ;;; and a FUN-END-COOKIE.
2787 ;;;
2788 ;;; INFO is information supplied by and used by the user.
2789 ;;;
2790 ;;; FUN-END-COOKIE is a function. To implement :FUN-END
2791 ;;; breakpoints, the system uses starter breakpoints to establish the
2792 ;;; :FUN-END breakpoint for each invocation of the function. Upon
2793 ;;; each entry, the system creates a unique cookie to identify the
2794 ;;; invocation, and when the user supplies a function for this
2795 ;;; argument, the system invokes it on the frame and the cookie. The
2796 ;;; system later invokes the :FUN-END breakpoint hook on the same
2797 ;;; cookie. The user may save the cookie for comparison in the hook
2798 ;;; function.
2799 ;;;
2800 ;;; Signal an error if WHAT is an unknown code-location.
2807 what))
2812 ;; This slot is filled in due to calling CODE-LOCATION-UNKNOWN-P.
2815 :unknown-return-partner
2816 info)))
2819 ;; (There used to be more cases back before sbcl-0.7.0,,
2820 ;; when we did special tricks to debug the IR1
2821 ;; interpreter.)
2822 )
2823 bpt))
2826 (:fun-start
2828 (:fun-end
2845 bpt))))))
2847 ;;; These are unique objects created upon entry into a function by a
2848 ;;; :FUN-END breakpoint's starter hook. These are only created
2849 ;;; when users supply :FUN-END-COOKIE to MAKE-BREAKPOINT. Also,
2850 ;;; the :FUN-END breakpoint's hook is called on the same cookie
2851 ;;; when it is created.
2857 ;; a pointer to the bogus-lra created for :FUN-END breakpoints
2858 bogus-lra
2859 ;; the DEBUG-FUN associated with this cookie
2860 debug-fun)
2862 ;;; This maps bogus-lra-components to cookies, so that
2863 ;;; HANDLE-FUN-END-BREAKPOINT can find the appropriate cookie for the
2864 ;;; breakpoint hook.
2867 ;;; This returns a hook function for the start helper breakpoint
2868 ;;; associated with a :FUN-END breakpoint. The returned function
2869 ;;; makes a fake LRA that all returns go through, and this piece of
2870 ;;; fake code actually breaks. Upon return from the break, the code
2871 ;;; provides the returnee with any values. Since the returned function
2872 ;;; effectively activates FUN-END-BPT on each entry to DEBUG-FUN's
2873 ;;; function, we must establish breakpoint-data about FUN-END-BPT.
2881 #!-fp-and-pc-standard-save
2884 #!+fp-and-pc-standard-save
2889 lra-save-offset
2890 lra-sc-offset))
2892 lra-save-offset
2893 lra-sc-offset)
2894 lra)
2906 ;;; This takes a FUN-END-COOKIE and a frame, and it returns
2907 ;;; whether the cookie is still valid. A cookie becomes invalid when
2908 ;;; the frame that established the cookie has exited. Sometimes cookie
2909 ;;; holders are unaware of cookie invalidation because their
2910 ;;; :FUN-END breakpoint hooks didn't run due to THROW'ing.
2911 ;;;
2912 ;;; This takes a frame as an efficiency hack since the user probably
2913 ;;; has a frame object in hand when using this routine, and it saves
2914 ;;; repeated parsing of the stack and consing when asking whether a
2915 ;;; series of cookies is valid.
2919 #!-fp-and-pc-standard-save
2923 #!+fp-and-pc-standard-save
2929 lra
2932 \f
2933 ;;;; ACTIVATE-BREAKPOINT
2935 ;;; Cause the system to invoke the breakpoint's hook function until
2936 ;;; the next call to DEACTIVATE-BREAKPOINT or DELETE-BREAKPOINT. The
2937 ;;; system invokes breakpoint hook functions in the opposite order
2938 ;;; that you activate them.
2944 (:code-location
2952 ;; (There used to be more cases back before sbcl-0.7.0, when
2953 ;; we did special tricks to debug the IR1 interpreter.)
2954 )))
2955 (:fun-start
2959 ;; (There used to be more cases back before sbcl-0.7.0, when
2960 ;; we did special tricks to debug the IR1 interpreter.)
2961 ))
2962 (:fun-end
2967 ;; may already be active by some other :FUN-END breakpoint
2970 ;; (There used to be more cases back before sbcl-0.7.0, when
2971 ;; we did special tricks to debug the IR1 interpreter.)
2972 ))))
2973 breakpoint)
2980 breakpoint
2995 breakpoint
2999 debug-fun))))))
3015 \f
3016 ;;;; DEACTIVATE-BREAKPOINT
3018 ;;; Stop the system from invoking the breakpoint's hook function.
3029 ;; (There used to be more cases back before sbcl-0.7.0, when
3030 ;; we did special tricks to debug the IR1 interpreter.)
3031 ))))
3032 breakpoint)
3054 breakpoint)
3055 \f
3056 ;;;; BREAKPOINT-INFO
3058 ;;; Return the user-maintained info associated with breakpoint. This
3059 ;;; is SETF'able.
3067 \f
3068 ;;;; BREAKPOINT-ACTIVE-P and DELETE-BREAKPOINT
3075 ;;; Free system storage and remove computational overhead associated
3076 ;;; with breakpoint. After calling this, breakpoint is completely
3077 ;;; impotent and can never become active again.
3096 nil))))))
3097 breakpoint)
3098 \f
3099 ;;;; C call out stubs
3101 ;;; This actually installs the break instruction in the component. It
3102 ;;; returns the overwritten bits. You must call this in a context in
3103 ;;; which GC is disabled, so that Lisp doesn't move objects around
3104 ;;; that C is pointing to.
3109 ;;; This removes the break instruction and replaces the original
3110 ;;; instruction. You must call this in a context in which GC is disabled
3111 ;;; so Lisp doesn't move objects around that C is pointing to.
3121 ;;;; breakpoint handlers (layer between C and exported interface)
3123 ;;; This maps components to a mapping of offsets to BREAKPOINT-DATAs.
3126 ;;; This returns the BREAKPOINT-DATA object associated with component cross
3127 ;;; offset. If none exists, this makes one, installs it, and returns it.
3134 data))))
3143 ;;; We use this when there are no longer any active breakpoints
3144 ;;; corresponding to DATA.
3146 ;; Again, this looks brittle. Is there no danger of being interrupted
3147 ;; here?
3157 ;;; The C handler for interrupts calls this when it has a
3158 ;;; debugging-tool break instruction. This does *not* handle all
3159 ;;; breaks; for example, it does not handle breaks for internal
3160 ;;; errors.
3166 offset))
3172 offset component signal-context)))))
3174 ;;; This holds breakpoint-datas while invoking the breakpoint hooks
3175 ;;; associated with that particular component and location. While they
3176 ;;; are executing, if we hit the location again, we ignore the
3177 ;;; breakpoint to avoid infinite recursion. fun-end breakpoints
3178 ;;; must work differently since the breakpoint-data is unique for each
3179 ;;; invocation.
3182 ;;; This handles code-location and DEBUG-FUN :FUN-START
3183 ;;; breakpoints.
3191 ;; At this point breakpoints may not hold the same list as
3192 ;; BREAKPOINT-DATA-BREAKPOINTS since invoking hooks may have allowed
3193 ;; a breakpoint deactivation. In fact, if all breakpoints were
3194 ;; deactivated then data is invalid since it was deleted and so the
3195 ;; correct one must be looked up if it is to be used. If there are
3196 ;; no more breakpoints active at this location, then the normal
3197 ;; instruction has been put back, and we do not need to
3198 ;; DO-DISPLACED-INST.
3201 ;; The breakpoint is still active, so we need to execute the
3202 ;; displaced instruction and leave the breakpoint instruction
3203 ;; behind. The best way to do this is different on each machine,
3204 ;; so we just leave it up to the C code.
3207 ;; Some platforms have no usable sigreturn() call. If your
3208 ;; implementation of arch_do_displaced_inst() _does_ sigreturn(),
3209 ;; it's polite to warn here
3217 frame
3218 ;; If this is an :UNKNOWN-RETURN-PARTNER, then pass the
3219 ;; hook function the original breakpoint, so that users
3220 ;; aren't forced to confront the fact that some
3221 ;; breakpoints really are two.
3224 bpt)))))
3233 ;; KLUDGE: This argument is ignored on
3234 ;; x86oids in this scenario, but is
3235 ;; declared to be a SAP.
3238 nil)))
3245 offset))
3251 ;;; Either HANDLE-BREAKPOINT calls this for :FUN-END breakpoints
3252 ;;; [old C code] or HANDLE-FUN-END-BREAKPOINT calls this directly
3253 ;;; [new C code].
3255 ;; FIXME: This looks brittle: what if we are interrupted somewhere
3256 ;; here? ...or do we have interrupts disabled here?
3268 frame bpt
3270 cookie))))
3274 scp
3288 results)))
3290 \f
3291 ;;;; MAKE-BOGUS-LRA (used for :FUN-END breakpoints)
3296 ;; One more for a fixup vector
3299 ;;; Make a bogus LRA object that signals a breakpoint trap when
3300 ;;; returned to. If the breakpoint trap handler returns, REAL-LRA is
3301 ;;; returned to. Three values are returned: the bogus LRA object, the
3302 ;;; code component it is part of, and the PC offset for the trap
3303 ;;; instruction.
3306 ;; These are really code labels, not variables: but this way we get
3307 ;; their addresses.
3316 src-start src-end dst-start trap-loc)
3321 ;; Set up the widetag and header of LRA
3322 ;; The header contains the same thing as the code object header,
3323 ;; the number of boxed words, which include slots and
3324 ;; constants and it has to be double word aligned.
3325 ;;
3326 ;; It used to be a part of the fun_end_breakpoint_guts
3327 ;; but its position and value depend on the offsets
3328 ;; and alignment of code object slots.
3332 bogus-lra-constants
3347 ;; We used to set the header value of the LRA here to the
3348 ;; offset from the enclosing component to the LRA header, but
3349 ;; MAKE-LISP-OBJ actually checks the value before we get a
3350 ;; chance to set it, so it's now done in arch-assem.S.
3352 \f
3353 ;;;; miscellaneous
3355 ;;; This appears here because it cannot go with the DEBUG-FUN
3356 ;;; interface since DO-DEBUG-BLOCK-LOCATIONS isn't defined until after
3357 ;;; the DEBUG-FUN routines.
3359 ;;; Return a code-location before the body of a function and after all
3360 ;;; the arguments are in place; or if that location can't be
3361 ;;; determined due to a lack of debug information, return NIL.
3368 debug-fun))
3369 nil))
3370 ;; (There used to be more cases back before sbcl-0.7.0, when
3371 ;; we did special tricks to debug the IR1 interpreter.)
3372 ))
3374 \f
3375 ;;;; Single-stepping
3377 ;;; The single-stepper works by inserting conditional trap instructions
3378 ;;; into the generated code (see src/compiler/*/call.lisp), currently:
3379 ;;;
3380 ;;; 1) Before the code generated for a function call that was
3381 ;;; translated to a VOP
3382 ;;; 2) Just before the call instruction for a full call
3383 ;;;
3384 ;;; In both cases, the trap will only be executed if stepping has been
3385 ;;; enabled, in which case it'll ultimately be handled by
3386 ;;; HANDLE-SINGLE-STEP-TRAP, which will either signal a stepping condition,
3387 ;;; or replace the function that's about to be called with a wrapper
3388 ;;; which will signal the condition.
3392 ;; The following calls must get tail-call eliminated for
3393 ;; *STEP-FRAME* to get set correctly on non-x86.
3402 ;; If there was not enough debug information available, there's no
3403 ;; sense in signaling the condition.
3409 ;; KLUDGE: Use the first non-foreign frame as the
3410 ;; *STACK-TOP-HINT*. Getting the frame from the signal
3411 ;; context as on x86 would be cleaner, but
3412 ;; SIGNAL-CONTEXT-FRAME doesn't seem seem to work at all
3413 ;; on non-x86.
3415 while frame
3421 ;; We could theoretically store information in
3422 ;; the debug-info about to determine the
3423 ;; arguments here, but for now let's just pass
3424 ;; on it.
3427 ;;; This function will replace the fdefn / function that was in the
3428 ;;; register at CALLEE-REGISTER-OFFSET with a wrapper function. To
3429 ;;; ensure that the full call will use the wrapper instead of the
3430 ;;; original, conditional trap must be emitted before the fdefn /
3431 ;;; function is converted into a raw address.
3433 ;; Fetch the function / fdefn we're about to call from the
3434 ;; appropriate register.
3438 ;; If there was not enough debug information available, there's no
3439 ;; sense in signaling the condition.
3447 args)))
3448 ;; Signal a step condition
3452 ;; And proceed based on its return value.
3454 ;; STEP-INTO was selected. Use *STEP-OUT* to
3455 ;; let the stepper know that selecting the
3456 ;; STEP-OUT restart is valid inside this
3458 ;; Pass the return values of the call to
3459 ;; STEP-VALUES, which will signal a
3460 ;; condition with them in the VALUES slot.
3463 step-info
3465 ;; If the user selected the STEP-OUT
3466 ;; restart during the call, resume
3467 ;; stepping
3470 ;; STEP-NEXT / CONTINUE / OUT selected:
3471 ;; Disable the stepper for the duration of
3472 ;; the call.
3479 fdefn))
3481 ;; And then store the wrapper in the same place.
3483 ;; %SET-CONTEXT-REGISTER is a function, so the address of
3484 ;; NEW-CALLEE gets converted to a fixnum before passing, which
3485 ;; won't keep NEW-CALLEE pinned down. Once it's inside
3486 ;; CONTEXT, which is registered in thread->interrupt_contexts,
3487 ;; it will properly point to NEW-CALLEE.
3491 ;;; Given a signal context, fetch the step-info that's been stored in
3492 ;;; the debug info at the trap point.
3498 pc-offset
3499 nil)))
3506 nil)))))
3508 ;;; Return the frame that triggered a single-step condition. Used to
3509 ;;; provide a *STACK-TOP-HINT*.