| blob | 3dd5aea59ff1ae058be71bec24cf2eeeb1ee12a3 |
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.
18 ;; Compilation to memory stores each toplevel form given to %COMPILE.
19 ;; That form can generate multiple functions, and those functions can
20 ;; be in one or more code components. They all point at the same form.
21 form
24 ;;; FIXME: There are an awful lot of package prefixes in this code.
25 ;;; Couldn't we have SB-DI use the SB-C and SB-VM packages?
26 \f
27 ;;;; conditions
29 ;;;; The interface to building debugging tools signals conditions that
30 ;;;; prevent it from adhering to its contract. These are
31 ;;;; serious-conditions because the program using the interface must
32 ;;;; handle them before it can correctly continue execution. These
33 ;;;; debugging conditions are not errors since it is no fault of the
34 ;;;; programmers that the conditions occur. The interface does not
35 ;;;; provide for programs to detect these situations other than
36 ;;;; calling a routine that detects them and signals a condition. For
37 ;;;; example, programmers call A which may fail to return successfully
38 ;;;; due to a lack of debug information, and there is no B the they
39 ;;;; could have called to realize A would fail. It is not an error to
40 ;;;; have called A, but it is an error for the program to then ignore
41 ;;;; the signal generated by A since it cannot continue without A's
42 ;;;; correctly returning a value or performing some operation.
43 ;;;;
44 ;;;; Use DEBUG-SIGNAL to signal these conditions.
47 ()
48 (:documentation
49 "All DEBUG-CONDITIONs inherit from this type. These are serious conditions
55 (:documentation
56 "The system could not return values from a frame with DEBUG-FUN since
62 "~&Cannot return values from ~:[frame~;~:*~S~] since ~
63 the debug information lacks details about returning ~
64 values here."
65 fun)))))
86 (:documentation
87 "The DEBUG-FUN has no lambda list since argument DEBUG-VARs are
108 \f
109 ;;;; errors and DEBUG-SIGNAL
111 ;;; The debug-internals code tries to signal all programmer errors as
112 ;;; subtypes of DEBUG-ERROR. There are calls to ERROR signalling
113 ;;; SIMPLE-ERRORs, but these dummy checks in the code and shouldn't
114 ;;; come up.
115 ;;;
116 ;;; While under development, this code also signals errors in code
117 ;;; branches that remain unimplemented.
120 (:documentation
121 "All programmer errors from using the interface for building debugging
147 ()
160 stream
161 "~&Form was preprocessed for ~S,~% but called on ~S:~% ~S"
166 ;;; This signals debug-conditions. If they go unhandled, then signal
167 ;;; an UNHANDLED-DEBUG-CONDITION error.
168 ;;;
169 ;;; ??? Get SIGNAL in the right package!
174 \f
175 ;;;; structures
176 ;;;;
177 ;;;; Most of these structures model information stored in internal
178 ;;;; data structures created by the compiler. Whenever comments
179 ;;;; preface an object or type with "compiler", they refer to the
180 ;;;; internal compiler thing, not to the object or type with the same
181 ;;;; name in the "SB-DI" package.
183 ;;;; DEBUG-VARs
185 ;;; These exist for caching data stored in packed binary form in
186 ;;; compiler DEBUG-FUNs.
189 ;; string name of the variable.
191 ;; package containing the variable. NIL when the variable's name is
192 ;; uninterned.
194 ;; a unique integer identification relative to other variables with the same
195 ;; symbol
197 ;; Does the variable always have a valid value?
202 "~A:~A ~W"
208 "Return the integer that makes DEBUG-VAR's name and package unique
213 (:constructor make-compiled-debug-var
217 ;; storage class and offset (unexported)
219 ;; storage class and offset when saved somewhere
221 ;; For indirect closures the fp of the parent frame is stored in the
222 ;; normal SC+OFFSETs above, and this has the offset into the frame
225 ;;;; DEBUG-FUNs
227 ;;; These exist for caching data stored in packed binary form in
228 ;;; compiler DEBUG-FUNs. There should only be one DEBUG-FUN in existence
229 ;;; for any function; that is, all CODE-LOCATIONs and other objects
230 ;;; that reference DEBUG-FUNs point to unique objects. This is
231 ;;; due to the overhead in cached information.
235 ;; some representation of the function arguments. See
236 ;; DEBUG-FUN-LAMBDA-LIST.
237 ;; NOTE: must parse vars before parsing arg list stuff.
239 ;; cached DEBUG-VARS information (unexported).
240 ;; These are sorted by their name.
242 ;; cached debug-block information. This is NIL when we have tried to
243 ;; parse the packed binary info, but none is available.
245 ;; the actual function if available
253 (:constructor make-bogus-debug-fun
262 ;;;; DEBUG-BLOCKs
264 ;;; These exist for caching data stored in packed binary form in compiler
265 ;;; DEBUG-BLOCKs.
268 ;; This indicates whether the block is a special glob of code shared
269 ;; by various functions and tucked away elsewhere in a component.
270 ;; This kind of block has no start code-location. This slot is in
271 ;; all debug-blocks since it is an exported interface.
282 ;; code-location information for the block
287 ;; the DEBUG-FUN containing this CODE-LOCATION
289 ;; This is initially :UNSURE. Upon first trying to access an
290 ;; :UNPARSED slot, if the data is unavailable, then this becomes T,
291 ;; and the code-location is unknown. If the data is available, this
292 ;; becomes NIL, a known location. We can't use a separate type
293 ;; code-location for this since we must return code-locations before
294 ;; we can tell whether they're known or unknown. For example, when
295 ;; parsing the stack, we don't want to unpack all the variables and
296 ;; blocks just to make frames.
298 ;; the DEBUG-BLOCK containing CODE-LOCATION. XXX Possibly toss this
299 ;; out and just find it in the blocks cache in DEBUG-FUN.
301 ;; This is the number of forms processed by the compiler or loader
302 ;; before the top level form containing this code-location.
304 ;; This is the depth-first number of the node that begins
305 ;; code-location within its top level form.
308 ;;;; frames
310 ;;; These represent call frames on the stack.
313 ;; the next frame up, or NIL when top frame
314 ;; KLUDGE - (OR NULL FRAME), and not (OR FRAME NULL), because PARSE-1-DSD
315 ;; warns; we're so bad at understanding recursive structure.
317 ;; the previous frame down, or NIL when the bottom frame. Before
318 ;; computing the next frame down, this slot holds the frame pointer
319 ;; to the control stack for the given frame. This lets us get the
320 ;; next frame down and the return-pc for that frame.
322 ;; the DEBUG-FUN for the function whose call this frame represents
324 ;; the CODE-LOCATION where the frame's DEBUG-FUN will continue
325 ;; running when program execution returns to this frame. If someone
326 ;; interrupted this frame, the result could be an unknown
327 ;; CODE-LOCATION.
329 ;; an a-list of catch-tags to code-locations
331 ;; pointer to frame on control stack (unexported)
333 ;; This is the frame's number for prompt printing. Top is zero.
338 (:constructor make-compiled-frame
342 ;; This indicates whether someone interrupted the frame.
343 ;; (unexported). If escaped, this is a pointer to the state that was
344 ;; saved when we were interrupted, an os_context_t, i.e. the third
345 ;; argument to an SA_SIGACTION-style signal handler.
350 "~S~:[~;, interrupted~]"
353 \f
355 ;;;; breakpoints
357 ;;; This is an internal structure that manages information about a
358 ;;; breakpoint locations. See *COMPONENT-BREAKPOINT-OFFSETS*.
362 ;; This is the component in which the breakpoint lies.
364 ;; This is the byte offset into the component.
366 ;; The original instruction replaced by the breakpoint.
368 ;; A list of user breakpoints at this location.
381 ;; This is the function invoked when execution encounters the
382 ;; breakpoint. It takes a frame, the breakpoint, and optionally a
383 ;; list of values. Values are supplied for :FUN-END breakpoints as
384 ;; values to return for the function containing the breakpoint.
385 ;; :FUN-END breakpoint hook functions also take a cookie argument.
386 ;; See the COOKIE-FUN slot.
388 ;; CODE-LOCATION or DEBUG-FUN
390 ;; :CODE-LOCATION, :FUN-START, or :FUN-END for that kind
391 ;; of breakpoint. :UNKNOWN-RETURN-PARTNER if this is the partner of
392 ;; a :code-location breakpoint at an :UNKNOWN-RETURN code-location.
396 ;; Status helps the user and the implementation.
398 ;; This is a backpointer to a breakpoint-data.
400 ;; With code-locations whose type is :UNKNOWN-RETURN, there are
401 ;; really two breakpoints: one at the multiple-value entry point,
402 ;; and one at the single-value entry point. This slot holds the
403 ;; breakpoint for the other one, or NIL if this isn't at an
404 ;; :UNKNOWN-RETURN code location.
406 ;; :FUN-END breakpoints use a breakpoint at the :FUN-START
407 ;; to establish the end breakpoint upon function entry. We do this
408 ;; by frobbing the LRA to jump to a special piece of code that
409 ;; breaks and provides the return values for the returnee. This slot
410 ;; points to the start breakpoint, so we can activate, deactivate,
411 ;; and delete it.
413 ;; This is a hook users supply to get a dynamically unique cookie
414 ;; for identifying :FUN-END breakpoint executions. That is, if
415 ;; there is one :FUN-END breakpoint, but there may be multiple
416 ;; pending calls of its function on the stack. This function takes
417 ;; the cookie, and the hook function takes the cookie too.
419 ;; This slot users can set with whatever information they find useful.
425 "~S~:[~;~:*~S~]"
440 ;; double-checked idiom has to ensure that no other CPU
441 ;; can see a just-made hash-table until all the slots of
442 ;; the instance are definitely published before the
443 ;; global var points to it.
450 (:constructor %make-compiled-debug-fun
453 ;; compiler's dumped DEBUG-FUN information (unexported)
456 ;; code object (unexported).
458 ;; the :FUN-START breakpoint (if any) used to facilitate
459 ;; function end breakpoints
462 ;;; This maps SB-C::COMPILED-DEBUG-FUNs to SB-DI::COMPILED-DEBUG-FUNs, so we
463 ;;; can get at cached stuff and not duplicate COMPILED-DEBUG-FUN
464 ;;; structures.
467 ;;; Make a SB-DI::COMPILED-DEBUG-FUN for a SB-C::COMPILED-DEBUG-FUN and its
468 ;;; component. This maps the latter to the former in
469 ;;; *COMPILED-DEBUG-FUNS*. If there already is a COMPILED-DEBUG-FUN,
470 ;;; then this returns it from *COMPILED-DEBUG-FUNS*.
477 \f
478 ;;;; CODE-LOCATIONs
483 str)))
487 (:constructor make-known-code-location
492 ;; an index into DEBUG-FUN's component slot
494 ;; a bit-vector indexed by a variable's position in
495 ;; DEBUG-FUN-DEBUG-VARS indicating whether the variable has a
496 ;; valid value at this code-location. (unexported).
498 ;; (unexported) To see SB-C::LOCATION-KIND, do
499 ;; (SB-KERNEL:TYPEXPAND 'SB-C::LOCATION-KIND).
503 \f
504 ;;;; frames
506 ;;; This is used in FIND-ESCAPED-FRAME and with the "breakpoint return" objects
507 ;;; and LRAs used for :FUN-END breakpoints. When a code object's
508 ;;; debug-info slot is :BPT-LRA, then the REAL-LRA-SLOT contains the
509 ;;; real location to continue executing, as opposed to the intermediary object
510 ;;; which appeared in some frame's LRA location.
511 ;;; NB: If you change change REAL-LRA-SLOT, then you must also change
512 ;;; "#define REAL_LRA_SLOT" in breakpoint.c. These have unfortunately
513 ;;; different values, because this slot is relative to the object base
514 ;;; address, whereas the one in C is an index into code->constants.
516 ;; * For non-x86: a single boxed constant holds the true LRA.
517 ;; Additionally, MIPS gets a boxed slot for the cookie
518 ;; that formerly went in a weak hash-table.
519 ;; * For x86[-64]: one boxed constant holds the code object to which
520 ;; to return, one holds the displacement into that object,
521 ;; and one holds the cookie
532 #+stack-grows-downward-not-upward
535 #-stack-grows-downward-not-upward
540 #+stack-grows-downward-not-upward
548 sb-alien:int
551 ;;; There are many opportunities for things to go wrong when searching
552 ;;; the heap for a code component. One possible problem occurs when
553 ;;; component_ptr_from_pc() searches for a code component on a page which
554 ;;; gets partially evacuated on x86[-64]. Suppose it contains pinned code
555 ;;; preceded by some objects that got forwarded. The scan performed by
556 ;;; gc_search_space could be interrupted in the middle, and resume execution
557 ;;; looking at a forwarding pointer, which gets the fatal "no size function".
558 ;;; Morover, excess delay between finding an object and creating a Lisp
559 ;;; descriptor introduces additional potential for error.
560 ;;; So we do two things to mitigate that problem:
561 ;;; (1) use unsafe %MAKE-LISP-OBJ, since we've already determined
562 ;;; where the code object starts with certainty, and we don't need
563 ;;; yet another search to test validity of the address.
564 ;;; (2) wrap the calls in WITH-CODE-PAGES-PINNED.
565 ;;;
566 ;;; Here's a concrete example, assuming the following objects exists:
567 ;;; 0x8000: vector header |
568 ;;; 0x8008: vector length | object 1
569 ;;; 0x8010: vector contents |
570 ;;; : ... v
571 ;;; 0x8100: code object | object 2
572 ;;; : ...
573 ;;; thread A is backtracing, and currently in component_ptr_to_pc(),
574 ;;; looking at 0x8000. Suppose the code is pinned, and that a garbage collection
575 ;;; will partially evacuate the page, and that partial evacuation zero-fills
576 ;;; the unused ranges (which it no longer does). Consider these schedules:
577 ;;;
578 ;;; Thread A Thread B
579 ;;; -------- --------
580 ;;; read header @ 0x8000
581 ;;; GC happens. zero-fill from 0x8000:0x8100
582 ;;; read length @ 0x8008 => 0
583 ;;; (skip to next object)
584 ;;; read header @ 0x8010 => junk
585 ;;;
586 ;;; In this schedule, thread A reads a word which is not a valid object header.
587 ;;;
588 ;;; But partial evacution no longer zeros the freed subranges - instead it writes
589 ;;; an unboxed array header so that only two words are touched per unused subrange.
590 ;;; This causes a different problem: The array may appear to contain forwarding
591 ;;; pointers to live objects that were moved off the page, and those pointers
592 ;;; appear to be embedded in the unboxed array.
593 ;;;
594 ;;; Use of WITHOUT-GCING is unfortunate - it's always preferable to
595 ;;; try to pin individual objects - but to do better we would have to
596 ;;; implement page-wide hazard pointers informing GC not to do anything
597 ;;; to any object on a specified page.
598 ;;;
599 ;;; On top of the considerations about dynamic space, there is a further issue
600 ;;; with allocation of immobile code. The allocator creates transient inconsistent
601 ;;; states when it reuses holes. Even if the header could be written atomically,
602 ;;; there can be junk in the remaining bytes of the hole that gets rewritten as
603 ;;; a smaller hole. It's evident that acquiring the allocator mutex works around
604 ;;; that glitch, as without such precaution, 'compiler.pure.lisp' would routinely
605 ;;; crash when run in multiple threads. A better fix would be to preseve invariants
606 ;;; at all times when allocating, both for the new hole that results from the hole
607 ;;; that gets cut down to size, and for the new object per se. Example:
608 ;;; | hole ............................ | 1 Kb
609 ;;; ^ new-object here ^ smaller hole starts here
610 ;;; (512 bytes)
611 ;;;
612 ;;; We first need to atomically write the header of the smaller hole
613 ;;; (which can't even be seen until the new object header is written).
614 ;;; This establishes that there won't be an inconsistent state.
615 ;;; Then we need to atomically write the new object header.
616 ;;; I suspect that both atomic writes should use double-wide CAS,
617 ;;; because if the object header is written using lispword-sized writes,
618 ;;; then the object can be sized wrong, and in this case it does cause problems
619 ;;; because the remaining bytes are not zero-filled. The allocator is similar
620 ;;; to malloc() in that regard.
625 ;; FIXME: It's accessing *dynspace-codeblob-tree*, which
626 ;; isn't gc-safe when done from C (especially on the
627 ;; precise gc backends).
637 ;;;; (OR X86 X86-64) support
644 ;; While theoretically we should inhibit GC any time we search the heap,
645 ;; in practice this function can only be called for code that is somewhere
646 ;; on the stack, and therefore conservatively pinned.
649 code)))
651 ;;; Check for a valid return address - it could be any valid C/Lisp
652 ;;; address.
653 ;;;
654 ;;; XXX Could be a little smarter.
659 ;; not the first page (which is unmapped)
660 ;;
661 ;; FIXME: Where is this documented? Is it really true of every CPU
662 ;; architecture? Is it even necessarily true in current SBCL?
664 ;; not a Lisp stack pointer
667 ;;; Try to find a valid previous stack. This is complex on the x86 as
668 ;;; it can jump between C and Lisp frames. To help find a valid frame
669 ;;; it searches backwards.
670 ;;;
671 ;;; XXX Should probably check whether it has reached the bottom of the
672 ;;; stack.
673 ;;;
674 ;;; XXX Should handle interrupted frames, both Lisp and C. At present
675 ;;; it manages to find a fp trail, see linux hack below.
689 \f
690 ;;; Return the top frame of the control stack as it was before calling
691 ;;; this function.
696 nil))
698 ;;; Flush all of the frames above FRAME, and renumber all the frames
699 ;;; below FRAME.
714 #+c-stack-is-control-stack
720 #+sb-thread
722 #-sb-thread
724 ;; This is slightly dangerous - the right thing would be
725 ;; to access using SAP-REF-WORD and compare like a few lines below.
726 ;; Why does #-sb-thread even check for this at all?
733 when
751 ocfp-save-offset))))
753 sap>
754 #-stack-grows-downward-not-upward
755 sap<
756 caller-fp fp)
760 return-pc-save-offset)))))))))))
765 #+fp-and-pc-standard-save
766 sb-c:return-pc-passing-offset
767 #-fp-and-pc-standard-save
776 ;; No handy backend (or compiler) defined constant for this one,
777 ;; so construct it here and now.
778 (sb-c:make-sc+offset control-stack-sc-number #-riscv lra-save-offset #+riscv sb-vm::ra-save-offset))))
782 #+fp-and-pc-standard-save
783 sb-c:old-fp-passing-offset
784 #-fp-and-pc-standard-save
793 ;; No handy backend (or compiler) defined constant for this one,
794 ;; so construct it here and now.
813 new-lra
815 new-lra)
817 ;;; Return the frame immediately below FRAME on the stack; or when
818 ;;; FRAME is the bottom of the stack, return NIL.
821 ;; We have to access the old-fp and return-pc out of frame and pass
822 ;; them to COMPUTE-CALLING-FRAME.
834 frame))
843 down)))
851 ;;; This returns a frame for the one existing in time immediately
852 ;;; prior to the frame referenced by current-fp. This is current-fp's
853 ;;; caller or the next frame down the control stack. If there is no
854 ;;; down frame, this returns NIL for the bottom of the stack. UP-FRAME
855 ;;; is the up link for the resulting frame object, and it is null when
856 ;;; we call this to get the top of the stack.
857 ;;;
858 ;;; The current frame contains the pointer to the temporally previous
859 ;;; frame we want, and the current frame contains the pc at which we
860 ;;; will continue executing upon returning to that previous frame.
861 ;;;
862 ;;; Note: Sometimes LRA is actually a fixnum. This happens when lisp
863 ;;; calls into C. In this case, the code object is stored on the stack
864 ;;; after the LRA, and the LRA is the word offset.
879 code
880 #+ppc64
882 other-pointer-lowtag)))))
888 n-word-bytes)
889 nil)
891 0
892 nil)))
899 (:undefined-function
902 (:foreign-function
914 escaped)
916 escaped))))))
936 (:undefined-function
939 (:foreign-function
950 escaped)
952 escaped))))))
959 ;; First check for an escaped frame.
964 ;; If it's escaped it may be a function end breakpoint trap.
967 ;; If :bpt-lra grab the real lra.
978 (:undefined-function
981 (:foreign-function
992 escaped)
994 ;; If we have an interrupt-context that's not on
995 ;; our stack at all, and we're computing the
996 ;; from from a saved FP, we're probably looking
997 ;; at an interrupted syscall.
1019 finally
1031 code))))
1033 :format-control
1034 "Attempt to RETURN-FROM a block or GO to a tag that no longer exists~@[ in ~s~]"
1039 ;; We wrap WITH-PINNED-OBJECTS around CODE, but in truth this can go wrong if the
1040 ;; code was transported after taking a PC and before getting here. i.e. there is
1041 ;; nothing to be gained by arranging that while we calculate CODE-INSTRUCTIONS
1042 ;; the code can't move if it already moved.
1043 ;; The precisely GCed backends would be a lot more correct with respect to
1044 ;; debug-related stuff if we just never move code that is on-stack.
1074 ;; KLUDGE: Detect undefined functions by a range-check
1075 ;; against the trampoline address and the following
1076 ;; function in the runtime.
1082 ;; We were in an assembly routine. Therefore, use the
1083 ;; LRA as the pc.
1084 ;;
1085 ;; FIXME: Should this be WARN or ERROR or what?
1087 pc-offset code))
1104 ;; We were in an assembly routine.
1110 "Set PC-OFFSET to zero and continue backtrace."
1111 'bug
1112 :format-control
1113 "~@<PC-OFFSET (~D) not in code object. Frame details:~
1114 ~2I~:@_PC: #X~X~:@_CODE: ~S~:@_CODE FUN: ~S~:@_LRA: ~
1115 #X~X~:@_COMPUTED RETURN: #X~X.~:>"
1116 :format-arguments
1119 code
1123 #+riscv
1128 lra-save-offset)
1129 computed-return))
1130 ;; We failed to pinpoint where PC is, but set
1131 ;; pc-offset to 0 to keep the backtrace from
1132 ;; exploding.
1140 nil))
1145 "Finds the PC for the return from an assembly routine properly.
1146 For some architectures (such as PPC) this will not be the $LRA
1147 register."
1153 code-header-len)
1154 return-machine-address))))
1156 ;;; Find the code object corresponding to the object represented by
1157 ;;; bits and return it. We assume bogus functions correspond to the
1158 ;;; undefined-function.
1167 ;; The GC constraint on the program counter on precisely-scavenged
1168 ;; backends is that it partakes of the interior-pointer nature.
1169 ;; Which means that it may be within the scope of an object other
1170 ;; than that pointed to by reg_CODE / $CODE. This is necessarily
1171 ;; the case during function call and return: whichever the outbound
1172 ;; function is has reg_CODE set up for itself, and the inbound
1173 ;; function cannot have reg_CODE set up until after the program
1174 ;; counter is within its body, otherwise a badly timed signal can
1175 ;; mess things up entirely. In practical terms, this means that we
1176 ;; need to do the same sort of pairing of interior pointers that the
1177 ;; GC does these days (see scavenge_interrupt_context() in
1178 ;; gc-common.c for details), but limiting to "things that can be
1179 ;; code objects". -- AB, 2018-Jan-11
1180 ;;
1181 ;; Oh, and as of this writing, AFAIK, the only precisely-scavenged
1182 ;; backends that are actually interrupt-safe around function calls
1183 ;; are PPC, ARM64, and probably ARM. PPC and ARM64 because they
1184 ;; have thread support, and GC load testing on PPC is how this
1185 ;; constraint was found in the first place. Probably ARM because I
1186 ;; wrote the bulk of the ARM backend well after I fixed function
1187 ;; calling on PPC and rewrote scavenge_interrupt_context() so that
1188 ;; things behaved reliably. -- AB, 2018-Jan-11
1190 ;; Unlike with the prior implementation, we cannot presume
1191 ;; that a FUNCTION is amenable to FUN-CODE-HEADER (it might
1192 ;; be a closure, and that is unlikely to be at all useful).
1193 ;; Fortunately, WIDETAG-OF comes up with sane values for
1194 ;; all object types, and we can pick off the SIMPLE-FUN
1195 ;; case easily enough.
1198 object)
1199 #-riscv
1206 nil)))))
1208 ;; If we can't actually pair the PC then we presume that
1209 ;; we're in an assembly-routine and that reg_CODE is, in
1210 ;; fact, the right thing to use... And that it will do
1211 ;; no harm to return it here anyway even if it isn't.
1213 #+ppc64
1216 code
1218 #-ppc64
1226 \f
1227 ;;;; frame utilities
1251 ;; Non-escaped frame means that this frame calls something.
1252 ;; And the PC points to where something should return.
1253 ;; The return adress may be in the next
1254 ;; function, e.g. in local tail calls the
1255 ;; function will be entered just after the
1256 ;; CALL.
1257 ;; See debug.impure.lisp/:local-tail-call for a test-case
1262 ;;; This returns a COMPILED-DEBUG-FUN for COMPONENT and PC. We fetch the
1263 ;;; SB-C::DEBUG-INFO and run down its FUN-MAP to get a
1264 ;;; SB-C::COMPILED-DEBUG-FUN from the PC. The result only needs to
1265 ;;; reference the COMPONENT, for function constants, and the
1266 ;;; SB-C::COMPILED-DEBUG-FUN.
1285 ;;; This returns a code-location for the COMPILED-DEBUG-FUN,
1286 ;;; DEBUG-FUN, and the pc into its code vector. If we stopped at a
1287 ;;; breakpoint, find the CODE-LOCATION for that breakpoint. Otherwise,
1288 ;;; make an :UNSURE code location, so it can be filled in when we
1289 ;;; figure out what is going on.
1292 escaped
1295 pc nil)))
1300 what)))))
1303 ;;; Return an alist mapping catch tags to CODE-LOCATIONs. These are
1304 ;;; CODE-LOCATIONs at which execution would continue with frame as the
1305 ;;; top frame if someone threw to the corresponding tag.
1316 #+ppc64
1318 other-pointer-lowtag))))
1321 n-word-bytes)))
1325 catch (* catch-block-entry-pc-slot
1326 n-word-bytes)))
1333 other-pointer-lowtag)
1335 n-word-bytes)))))
1346 reversed-result))
1351 ;;; Modify the value of the OLD-TAG catches in FRAME to NEW-TAG
1359 value)))
1374 \f
1375 ;;;; operations on DEBUG-FUNs
1377 ;;; Execute the forms in a context with BLOCK-VAR bound to each
1378 ;;; DEBUG-BLOCK in DEBUG-FUN successively. Result is an optional
1379 ;;; form to execute for return values, and DO-DEBUG-FUN-BLOCKS
1380 ;;; returns nil if there is no result form. This signals a
1381 ;;; NO-DEBUG-BLOCKS condition when the DEBUG-FUN lacks
1382 ;;; DEBUG-BLOCK information.
1393 ;;; Execute body in a context with VAR bound to each DEBUG-VAR in
1394 ;;; DEBUG-FUN. This returns the value of executing result (defaults to
1395 ;;; nil). This may iterate over only some of DEBUG-FUN's variables or
1396 ;;; none depending on debug policy; for example, possibly the
1397 ;;; compilation only preserved argument information.
1409 ;;; Compute byte offset of FUNCTION into CODE-INSTRUCTIONS of its code,
1410 ;;; which is the byte offset from the base of its code
1411 ;;; minus the number of bytes in the boxed portion of its code header.
1418 ;;; Return the object of type FUNCTION associated with the DEBUG-FUN,
1419 ;;; or NIL if the function is unavailable or is non-existent as a user
1420 ;;; callable function object.
1435 result))
1437 cached-value)))
1439 ;;; Return the name of the function represented by DEBUG-FUN. This may
1440 ;;; be a string or a cons; do not assume it is a symbol.
1447 ;; Frames named (.EVAL. special-operator) should show the operator name
1448 ;; in backtraces, but if the debugger needs to detect that the frame is
1449 ;; interpreted for other purposes, it can specify PRETTY = NIL.
1452 pretty)
1476 ;; Return the name of the closure, if named, otherwise nil.
1482 ;; Frames named (.APPLY. something) are interpreted function applicators.
1483 ;; Show them as the name of the interpreted function being applied.
1484 #+sb-fasteval
1487 ;; Find a variable named FUN.
1493 (%fun-name
1496 sb-c:closure-sc
1500 ;;; Return a DEBUG-FUN that represents debug information for FUN.
1516 ;; KLUDGE: comment from CMU CL:
1517 ;; This used to be the non-interpreted branch, but
1518 ;; William wrote it to return the debug-fun of fun's XEP
1519 ;; instead of fun's debug-fun. The above code does this
1520 ;; more correctly, but it doesn't get or eliminate all
1521 ;; appropriate cases. It mostly works, and probably
1522 ;; works for all named functions anyway.
1523 ;; -- WHN 20000120
1527 ;;; Return the kind of the function, which is one of :OPTIONAL, :MORE
1528 ;;; :EXTERNAL, :TOPLEVEL, :CLEANUP, or NIL.
1530 ;; FIXME: This "is one of" information should become part of the function
1531 ;; declamation, not just a doc string
1537 nil)))
1539 ;;; Is there any variable information for DEBUG-FUN?
1543 ;;; Return a list of DEBUG-VARs in DEBUG-FUN having the same name
1544 ;;; and package as SYMBOL. If SYMBOL is uninterned, then this returns
1545 ;;; a list of DEBUG-VARs without package names and with the same name
1546 ;;; as symbol. The result of this function is limited to the
1547 ;;; availability of variable information in DEBUG-FUN; for
1548 ;;; example, possibly DEBUG-FUN only knows about its arguments.
1560 vars)))
1562 ;;; Return a list of DEBUG-VARs in DEBUG-FUN whose names contain
1563 ;;; NAME-PREFIX-STRING as an initial substring. The result of this
1564 ;;; function is limited to the availability of variable information in
1565 ;;; debug-fun; for example, possibly debug-fun only knows
1566 ;;; about its arguments.
1577 ;; Find names from pos to variable's len that contain prefix.
1586 prefix-len)
1587 prefix-len)
1591 res))))
1593 ;;; This returns a position in VARIABLES for one containing NAME as an
1594 ;;; initial substring. END is the length of VARIABLES if supplied.
1608 ;;; Return a list representing the lambda-list for DEBUG-FUN. The
1609 ;;; list has the following structure:
1610 ;;; (required-var1 required-var2
1611 ;;; ...
1612 ;;; (:optional var3 suppliedp-var4)
1613 ;;; (:optional var5)
1614 ;;; ...
1615 ;;; (:rest var6) (:rest var7)
1616 ;;; ...
1617 ;;; (:keyword keyword-symbol var8 suppliedp-var9)
1618 ;;; (:keyword keyword-symbol var10)
1619 ;;; ...
1620 ;;; )
1621 ;;; Each VARi is a DEBUG-VAR; however it may be the symbol :DELETED if
1622 ;;; it is unreferenced in DEBUG-FUN. This signals a
1623 ;;; LAMBDA-LIST-UNAVAILABLE condition when there is no argument list
1624 ;;; information.
1630 ;;; Return the MORE-CONTEXT and MORE-COUNT vars of a DEBUG-FUN.
1637 ;;; Note: If this has to compute the lambda list, it caches it in DEBUG-FUN.
1645 args
1650 nil)
1653 ;; If the packed information is there (whether empty or not) as
1654 ;; opposed to being nil, then returned our cached value (nil).
1655 nil)
1657 ;; Our cached value is nil, and the packed lambda-list information
1658 ;; is nil, so we don't have anything available.
1662 ;;; A compact "vector" is either the element itself or a vector
1670 vector)
1675 vector)))
1699 tag-and-info)
1700 result))
1703 :deleted
1707 do
1714 ;; The next two args are the &MORE arg context and
1715 ;; count.
1718 ;; SUPPLIED-P var immediately following keyword or
1719 ;; optional. Stick the extra var in the result element
1720 ;; representing the keyword or optional, which is the
1721 ;; previous one.
1724 ;; The keyword of a keyword parameter. Store it so the next
1725 ;; element can be used to form a (:keyword KEYWORD VALUE)
1726 ;; entry.
1729 ;; The previous element was the keyword of a keyword
1730 ;; parameter and is stored in KEYWORD. The current element
1731 ;; is the index of the value (or a deleted
1732 ;; marker). Construct and push the complete entry.
1735 ;; We saw an optional marker, so the following non-symbols
1736 ;; are indexes (or deleted markers) indicating optional
1737 ;; variables.
1740 ;; Deleted required, optional or keyword argument.
1743 ;; Required arg at beginning of args array.
1749 ;;; This is used in COMPILED-DEBUG-FUN-LAMBDA-LIST.
1760 \f
1761 ;;;; unpacking variable and basic block data
1763 ;;; The argument is a debug internals structure. This returns the
1764 ;;; DEBUG-BLOCKs for DEBUG-FUN, regardless of whether we have unpacked
1765 ;;; them yet. It signals a NO-DEBUG-BLOCKS condition if it can't
1766 ;;; return the blocks.
1776 ;;; Return a SIMPLE-VECTOR of DEBUG-BLOCKs or NIL. NIL indicates there
1777 ;;; was no basic block information.
1784 parsed)))
1788 ;;; This does some of the work of PARSE-DEBUG-BLOCKS.
1793 debug-fun))
1798 blocks)))
1799 ;; KLUDGE: 8 is a hard-wired constant in the compiler for the
1800 ;; element size of the packed binary representation of the
1801 ;; blocks data.
1805 elsewhere-p
1809 result-blocks
1811 locations
1812 prev-live
1813 prev-form-number)
1820 elsewhere-p)
1840 prev-form-number)
1846 prev-live)
1867 pc debug-fun block tlf-offset
1868 form-number live-set kind
1869 step-info context)
1870 locations)
1874 ;;; VARS is the parsed variables for a minimal debug function. We need
1875 ;;; to assign names of the form ARG-NNN. We must pad with leading
1876 ;;; zeros, since the arguments must be in alphabetical order.
1885 ;;; Parse the packed representation of DEBUG-VARs from
1886 ;;; DEBUG-FUN's SB-C::COMPILED-DEBUG-FUN, returning a vector
1887 ;;; of DEBUG-VARs, or NIL if there was no information to parse.
1890 debug-fun))
1899 ;; Return a simple-vector not whatever packed-vars may be.
1905 prev-name)
1907 ;; The routines in the "SB-C" package are macros that advance the
1908 ;; index.
1914 prev-name)
1919 flags)
1922 flags)
1923 nil)
1925 default-package)))
1931 nil))
1935 nil)))
1941 prev-name name)))
1944 name package id
1948 buffer))
1953 result))))
1955 ;;; The argument is a debug internals structure. This returns NIL if
1956 ;;; there is no variable information. It returns an empty
1957 ;;; simple-vector if there were no locals in the function. Otherwise
1958 ;;; it returns a SIMPLE-VECTOR of DEBUG-VARs.
1968 vars)))
1970 ;;; COMPILED-DEBUG-FUN-LAMBDA-LIST calls this when a
1971 ;;; COMPILED-DEBUG-FUN has no lambda list information cached. It
1972 ;;; returns the lambda list as the first value and whether there was
1973 ;;; any argument information as the second value. Therefore,
1974 ;;; (VALUES NIL T) means there were no arguments, but (VALUES NIL NIL)
1975 ;;; means there was no argument information.
1977 ;; This file could not be slammed if COERCE is inlined because it thinks :UNPARSED
1978 ;; (i.e. not a sequence) can be returned as the DEBUG-VARS. But it can't, and a running
1979 ;; image was able to recompile the function with no decl and no warning. What's up with that?
1987 t))
1991 t)))))
1992 \f
1993 ;;;; unpacking packed debug functions
1995 ;;; sleazoid "macro" to keep our indentation sane in UNCOMPACT-FUN-MAP
1999 name
2006 :vars
2011 :blocks
2017 blocks))
2018 :tlf-number
2021 :arguments
2042 buffer))
2047 buffer)))
2050 buffer))
2053 buffer)))))
2056 :returns
2077 :closure-save
2081 #+unwind-to-frame-and-call-vop
2084 :start-pc
2088 :elsewhere-pc
2091 ;;; Return a normal function map derived from a packed debug info
2092 ;;; function map. This involves looping parsing PACKED-DEBUG-FUNs and
2093 ;;; then building a vector out of them.
2117 ;;; a map from packed DEBUG-INFO function maps to unpacked
2118 ;;; versions thereof
2121 ;;; Return a FUN-MAP for a given COMPILED-DEBUG-INFO object. If the
2122 ;;; info is packed, and has not been parsed, then parse it.
2128 \f
2129 ;;;; CODE-LOCATIONs
2131 ;;; If we're sure of whether code-location is known, return T or NIL.
2132 ;;; If we're :UNSURE, then try to fill in the code-location's slots.
2133 ;;; This determines whether there is any debug-block information, and
2134 ;;; if code-location is known.
2135 ;;;
2136 ;;; ??? IF this conses closures every time it's called, then break off the
2137 ;;; :UNSURE part to get the HANDLER-CASE into another function.
2142 (:unsure
2147 ;;; Return the DEBUG-BLOCK containing code-location if it is available.
2148 ;;; Some debug policies inhibit debug-block information, and if none
2149 ;;; is available, then this signals a NO-DEBUG-BLOCKS condition.
2156 ;; (There used to be more cases back before sbcl-0.7.0, when
2157 ;; we did special tricks to debug the IR1 interpreter.)
2158 )
2159 block)))
2161 ;;; Store and return BASIC-CODE-LOCATION's debug-block. We determines
2162 ;;; the correct one using the code-location's pc. We use
2163 ;;; DEBUG-FUN-DEBUG-BLOCKS to return the cached block information
2164 ;;; or signal a NO-DEBUG-BLOCKS condition. The blocks are sorted by
2165 ;;; their first code-location's pc, in ascending order. Therefore, as
2166 ;;; soon as we find a block that starts with a pc greater than
2167 ;;; basic-code-location's pc, we know the previous block contains the
2168 ;;; pc. If we get to the last block, then the code-location is either
2169 ;;; in the second to last block or the last block, and we have to be
2170 ;;; careful in determining this since the last block could be code at
2171 ;;; the end of the function. We have to check for the last block being
2172 ;;; code first in order to see how to compare the code-location's pc.
2176 basic-code-location))
2192 debug-fun)))
2194 last))
2195 ((< pc
2209 ;;; Return the CODE-LOCATION's DEBUG-SOURCE.
2217 ;;; Returns the number of top level forms before the one containing
2218 ;;; CODE-LOCATION as seen by the compiler in some compilation unit. (A
2219 ;;; compilation unit is not necessarily a single file, see the section
2220 ;;; on debug-sources.)
2229 ;; This check should be unnecessary. We're missing
2230 ;; debug info the compiler should have dumped.
2233 ;; (There used to be more cases back before sbcl-0.7.0,,
2234 ;; when we did special tricks to debug the IR1
2235 ;; interpreter.)
2236 ))
2239 ;;; Return the number of the form corresponding to CODE-LOCATION. The
2240 ;;; form number is derived by a walking the subforms of a top level
2241 ;;; form in depth-first order.
2250 ;; This check should be unnecessary. We're missing
2251 ;; debug info the compiler should have dumped.
2254 ;; (There used to be more cases back before sbcl-0.7.0,,
2255 ;; when we did special tricks to debug the IR1
2256 ;; interpreter.)
2257 ))
2260 ;;; Return the kind of CODE-LOCATION, one of:
2261 ;;; :INTERPRETED, :UNKNOWN-RETURN, :KNOWN-RETURN, :INTERNAL-ERROR,
2262 ;;; :NON-LOCAL-EXIT, :BLOCK-START, :CALL-SITE, :SINGLE-VALUE-RETURN,
2263 ;;; :NON-LOCAL-ENTRY
2272 ;; This check should be unnecessary. We're missing
2273 ;; debug info the compiler should have dumped.
2277 ;; (There used to be more cases back before sbcl-0.7.0,,
2278 ;; when we did special tricks to debug the IR1
2279 ;; interpreter.)
2280 ))
2282 ;;; This returns CODE-LOCATION's live-set if it is available. If
2283 ;;; there is no debug-block information, this returns NIL.
2286 nil
2291 ;; This check should be unnecessary. We're missing
2292 ;; debug info the compiler should have dumped.
2293 ;;
2294 ;; FIXME: This error and comment happen over and over again.
2295 ;; Make them a shared function.
2326 fp x alien-context)
2327 x))))))
2329 ;;; true if OBJ1 and OBJ2 are the same place in the code
2338 ;; (There used to be more cases back before sbcl-0.7.0,,
2339 ;; when we did special tricks to debug the IR1
2340 ;; interpreter.)
2341 ))
2342 ;; (There used to be more cases back before sbcl-0.7.0,,
2343 ;; when we did special tricks to debug IR1-interpreted code.)
2344 ))
2349 ;;; Fill in CODE-LOCATION's :UNPARSED slots, returning T or NIL
2350 ;;; depending on whether the code-location was known in its
2351 ;;; DEBUG-FUN's debug-block information. This may signal a
2352 ;;; NO-DEBUG-BLOCKS condition due to DEBUG-FUN-DEBUG-BLOCKS, and
2353 ;;; it assumes the %UNKNOWN-P slot is already set or going to be set.
2369 ;; There may be multiple locations in multiple blocks at a given PC, prefer
2370 ;; the :internal-error ones.
2389 t)))
2390 \f
2391 ;;;; operations on DEBUG-BLOCKs
2393 ;;; Execute FORMS in a context with CODE-VAR bound to each
2394 ;;; CODE-LOCATION in DEBUG-BLOCK, and return the value of RESULT.
2405 ;;; Return the name of the function represented by DEBUG-FUN.
2406 ;;; This may be a string or a cons; do not assume it is a symbol.
2413 "??? Can't get name of debug-block's function."
2416 ;; (There used to be more cases back before sbcl-0.7.0, when we
2417 ;; did special tricks to debug the IR1 interpreter.)
2418 ))
2424 ;; (There used to be more cases back before sbcl-0.7.0, when we
2425 ;; did special tricks to debug the IR1 interpreter.)
2426 ))
2427 \f
2428 ;;;; operations on debug variables
2430 ;;; Return the symbol from interning DEBUG-VAR-NAME in the package DEBUG-VAR-PACKAGE.
2438 ;;; Return the value stored for DEBUG-VAR in frame, or if the value is
2439 ;;; not :VALID, then signal an INVALID-VALUE error.
2446 ;;; Returns the value stored for DEBUG-VAR in frame. The value may be
2447 ;;; invalid. This is SETFable.
2453 res)))
2455 ;;; This returns what is stored for the variable represented by
2456 ;;; DEBUG-VAR relative to the FRAME. This may be an indirect value
2457 ;;; cell if the variable is both closed over and set.
2462 ;; Indirect are accessed through a frame pointer of the parent.
2471 escaped))
2473 escaped))
2478 escaped))
2485 ;;; a helper function for working with possibly-invalid values:
2486 ;;; Do (%MAKE-LISP-OBJ VAL) only if the value looks valid.
2487 ;;;
2488 ;;; (Such values can arise in registers on machines with conservative
2489 ;;; GC, and might also arise in debug variable locations when
2490 ;;; those variables are invalid.)
2491 ;;;
2492 ;;; NOTE for precisely GC'd platforms:
2493 ;;; this function is not GC-safe in the slightest when creating
2494 ;;; a pointer to an object in dynamic space. If a GC occurs between
2495 ;;; the start of the call to VALID-TAGGED-POINTER-P and the end of
2496 ;;; %MAKE-LISP-OBJ then the object could move before the boxed pointer
2497 ;;; is constructed. This can happen on CHENEYGC if an asynchronous
2498 ;;; interrupt occurs within the window. This can happen on GENCGC
2499 ;;; under the same circumstances, but is more likely due to all GENCGC
2500 ;;; platforms supporting threaded operation.
2502 ;;; On x86oids we are able to eliminate the vulnerable window
2503 ;;; by conservatively pinning an object (i.e. storing a bit pattern
2504 ;;; that would be the address of an object, assuming it is an object)
2505 ;;; whether or not there is actually an object to pin.
2506 ;;; To see the GC-safeness problem without WITH-PINNED-OBJECTS, consider
2507 ;;; the following sequence of events, and suppose for the sake of argument
2508 ;;; that tagged pointer #x104003 is valid at the moment of call.
2509 ;;; Assume 1 low zero bit in a fixnum, so the register contains #x208006.
2510 ;;; 1. move-to-word: arg-passing-reg <- #x104003 ; implicit pin
2511 ;;; /* at this point the fixnum whose representation is #x208006
2512 ;;; was spilled to stack prior to call, *and* the descriptor bits
2513 ;;; are also in a register. The fixnum pins nothing as it does not
2514 ;;; have Lisp pointer nature. The passing reg pins something */
2515 ;;; 2. call C : will return true, and assume that the arg-passing-reg
2516 ;;; gets clobbered. The return-reg contains 1 for true.
2517 ;;; 3. -- GC triggered by other thread
2518 ;;; transport the object that was #x104003 to somewhere new
2519 ;;; 4. now %MAKE-LISP-OBJ creates a bogus pointer.
2520 ;;; By preemptively using (WITH-PINNED-OBJECTS ((%MAKE-LISP-OBJ)))
2521 ;;; we ensure that the bit pattern #x104003 is on the stack for root scan.
2522 ;;; Unfortunately, WITH-PINNED-OBJECTS can not be used with precise GC
2523 ;;; because random trash is not allowed in a descriptor register.
2524 ;;; If we really wanted to make this safe for precise GC, we could use a
2525 ;;; new special binding, something like *PINNED-WORDS* which would be a list
2526 ;;; of INTEGERs, each of which, _if_ its bit pattern is that of an object
2527 ;;; descriptor, would pin the corresponding object. On the lisp side
2528 ;;; the cons cell in the list would hold the supplied VAL directly.
2531 ;; fixnum
2533 ;; immediate single float, 64-bit only
2536 ;; character
2539 ;; unbound marker
2542 ;; To mitigate the danger of GC running in between testing pointer
2543 ;; validity and returning the object, we must pin a potentially
2544 ;; non-object which is harmless on the conservative backends
2545 ;; but harmful on precise GC.
2553 0
2563 nil)))))))
2566 ;; NOTE: The long-float support in here is obviously decayed. When
2567 ;; the x86oid and non-x86oid versions of this function were unified,
2568 ;; the behavior of long-floats was preserved, which only served to
2569 ;; highlight its brokenness.
2579 escaped
2588 ;; x86oids have no separate number stack, so dummy it
2589 ;; up for them.
2590 #+c-stack-is-control-stack
2593 #-c-stack-is-control-stack
2607 ((#.any-reg-sc-number
2610 (#.character-reg-sc-number
2613 (#.sap-reg-sc-number
2616 (#.signed-reg-sc-number
2620 val)))
2621 (#.unsigned-reg-sc-number
2623 val))
2625 (#.non-descriptor-reg-sc-number
2628 (#.interior-reg-sc-number
2630 #+sb-simd-pack
2633 #+sb-simd-pack
2636 #+sb-simd-pack
2639 #+sb-simd-pack
2642 (%make-simd-pack-ub64
2645 #+sb-simd-pack
2648 (%make-simd-pack-single
2653 #+sb-simd-pack
2656 (%make-simd-pack-double
2659 #+sb-simd-pack-256
2662 #+sb-simd-pack-256
2665 #+sb-simd-pack-256
2668 #+sb-simd-pack-256
2671 (%make-simd-pack-256-ub64
2676 #+sb-simd-pack-256
2679 (%make-simd-pack-256-single
2688 #+sb-simd-pack-256
2691 (%make-simd-pack-256-double
2696 (#.single-reg-sc-number
2698 (#.double-reg-sc-number
2700 #+long-float
2701 (#.long-reg-sc-number
2703 (#.complex-single-reg-sc-number
2705 (#.complex-double-reg-sc-number
2707 #+long-float
2708 (#.complex-long-reg-sc-number
2710 (#.single-stack-sc-number
2713 (#.double-stack-sc-number
2716 #+long-float
2717 (#.long-stack-sc-number
2720 (#.complex-single-stack-sc-number
2725 (#.complex-double-stack-sc-number
2730 #+long-float
2731 (#.complex-long-stack-sc-number
2738 (#.control-stack-sc-number
2740 (#.character-stack-sc-number
2743 (#.unsigned-stack-sc-number
2746 (#.signed-stack-sc-number
2749 (#.sap-stack-sc-number
2752 (#.constant-sc-number
2759 (#.immediate-sc-number
2762 ;;; This stores value as the value of DEBUG-VAR in FRAME. In the
2763 ;;; COMPILED-DEBUG-VAR case, access the current value to determine if
2764 ;;; it is an indirect value cell. This occurs when the variable is
2765 ;;; both closed over and set.
2772 new-value)
2774 ;;; This stores VALUE for the variable represented by debug-var
2775 ;;; relative to the frame. This assumes the location directly contains
2776 ;;; the variable's value; that is, there is no indirect value cell
2777 ;;; currently there in case the variable is both closed over and set.
2783 value escaped)
2788 value))))
2791 ;; Like sub-access-debug-var-slot, this is the unification of two
2792 ;; divergent copy-pasted functions. The astute reviewer will notice
2793 ;; that long-floats are messed up here as well, that x86oids
2794 ;; apparently don't support accessing float values that are in
2795 ;; registers, and that non-x86oids store the real part of a float
2796 ;; for both the real and imaginary parts of a complex on the stack
2797 ;; (but not in registers, oddly enough). Some research has
2798 ;; indicated that the different forms of THE used for validating the
2799 ;; type of complex float components between x86oid and non-x86oid
2800 ;; systems are only significant in the case of using a non-complex
2801 ;; number as input (as the non-x86oid case effectively converts
2802 ;; non-complex numbers to complex ones and the x86oid case will
2803 ;; error out). That said, the error message from entering a value
2804 ;; of the wrong type will be slightly easier to understand on x86oid
2805 ;; systems.
2811 value))
2815 escaped
2818 value))
2825 value))
2827 ;; x86oids have no separate number stack, so dummy it
2828 ;; up for them.
2829 #+c-stack-is-control-stack
2832 #-c-stack-is-control-stack
2845 ((#.any-reg-sc-number
2848 (#.character-reg-sc-number
2850 (#.sap-reg-sc-number
2852 (#.signed-reg-sc-number
2854 (#.unsigned-reg-sc-number
2857 (#.non-descriptor-reg-sc-number
2860 (#.interior-reg-sc-number
2862 #+sb-simd-pack
2865 #+sb-simd-pack
2868 #+sb-simd-pack
2871 #+sb-simd-pack
2877 #+sb-simd-pack
2885 #+sb-simd-pack
2891 #+sb-simd-pack-256
2894 #+sb-simd-pack-256
2897 #+sb-simd-pack-256
2900 #+sb-simd-pack-256
2908 #+sb-simd-pack-256
2920 #+sb-simd-pack-256
2928 (#.single-reg-sc-number
2931 (#.double-reg-sc-number
2933 #+long-float
2934 (#.long-reg-sc-number
2936 (#.complex-single-reg-sc-number
2938 (#.complex-double-reg-sc-number
2940 #+long-float
2941 (#.complex-long-reg-sc-number
2943 (#.single-stack-sc-number
2947 (#.double-stack-sc-number
2951 #+long-float
2952 (#.long-stack-sc-number
2956 (#.complex-single-stack-sc-number
2968 (#.complex-double-stack-sc-number
2980 #+long-float
2981 (#.complex-long-stack-sc-number
2996 (#.control-stack-sc-number
2999 (#.character-stack-sc-number
3003 (#.unsigned-stack-sc-number
3006 (#.signed-stack-sc-number
3010 (#.sap-stack-sc-number
3015 ;;; The method for setting and accessing COMPILED-DEBUG-VAR values use
3016 ;;; this to determine if the value stored is the actual value or an
3017 ;;; indirection cell.
3022 ;;; Return three values reflecting the validity of DEBUG-VAR's value
3023 ;;; at BASIC-CODE-LOCATION:
3024 ;;; :VALID The value is known to be available.
3025 ;;; :INVALID The value is known to be unavailable.
3026 ;;; :UNKNOWN The value's availability is unknown.
3027 ;;;
3028 ;;; If the variable is always alive, then it is valid. If the
3029 ;;; code-location is unknown, then the variable's validity is
3030 ;;; :unknown. Once we've called CODE-LOCATION-UNKNOWN-P, we know the
3031 ;;; live-set information has been cached in the code-location.
3035 ;;; This is the method for DEBUG-VAR-VALIDITY for COMPILED-DEBUG-VARs.
3036 ;;; For safety, make sure basic-code-location is what we think.
3044 :valid
3051 basic-code-location)))))
3054 :debug-var debug-var
3055 :debug-fun
3057 ;; There must be live-set info since basic-code-location is known.
3059 basic-code-location)
3060 pos))
3061 :invalid
3063 \f
3064 ;;;; sources
3066 ;;; This code produces and uses what we call source-paths. A
3067 ;;; source-path is a list whose first element is a form number as
3068 ;;; returned by CODE-LOCATION-FORM-NUMBER and whose last element is a
3069 ;;; top level form number as returned by
3070 ;;; CODE-LOCATION-TOPLEVEL-FORM-NUMBER. The elements from the last to
3071 ;;; the first, exclusively, are the numbered subforms into which to
3072 ;;; descend. For example:
3073 ;;; (defun foo (x)
3074 ;;; (let ((a (aref x 3)))
3075 ;;; (cons a 3)))
3076 ;;; The call to AREF in this example is form number 5. Assuming this
3077 ;;; DEFUN is the 11'th top level form, the source-path for the AREF
3078 ;;; call is as follows:
3079 ;;; (5 1 0 1 3 11)
3080 ;;; Given the DEFUN, 3 gets you the LET, 1 gets you the bindings, 0
3081 ;;; gets the first binding, and 1 gets the AREF form.
3083 ;;; This returns a table mapping form numbers to source-paths. A
3084 ;;; source-path indicates a descent into the TOPLEVEL-FORM form,
3085 ;;; going directly to the subform corressponding to the form number.
3086 ;;;
3087 ;;; The vector elements are in the same format as the compiler's
3088 ;;; NODE-SOURCE-PATH; that is, the first element is the form number and
3089 ;;; the last is the TOPLEVEL-FORM number.
3090 ;;;
3091 ;;; This should be synchronized with SB-C::SUB-FIND-SOURCE-PATHS
3099 translations)
3113 ;; Don't look into quoted constants.
3125 ;;; FORM is a top level form, and path is a source-path into it. This
3126 ;;; returns the form indicated by the source-path. Context is the
3127 ;;; number of enclosing forms to return instead of directly returning
3128 ;;; the source-path form. When context is non-zero, the form returned
3129 ;;; contains a marker, #:****HERE****, immediately before the form
3130 ;;; indicated by path.
3133 ;; Get to the form indicated by path or the enclosing form indicated
3134 ;; by context and path.
3142 ;; Recursively rebuild the source form resulting from the above
3143 ;; descent, copying the beginning of each subform up to the next
3144 ;; subform we descend into according to path. At the bottom of the
3145 ;; recursion, we return the form indicated by path preceded by our
3146 ;; marker, and this gets spliced into the resulting list structure
3147 ;; on the way back up.
3151 form
3161 ;;; Given a code location, return the associated form-number
3162 ;;; translations and the actual top level form.
3163 ;;; Note that functions compiled to memory (via COMPILE or implicitly
3164 ;;; via LOAD if *EVALUATOR-MODE* = :COMPILE) do not save their source form
3165 ;;; in the DEBUG-SOURCE corresponding to their code-component. Instead the
3166 ;;; form hangs off the %SIMPLE-FUN-INFO slot, so that we can get an accurate
3167 ;;; depiction of the source form for any lambda no matter where from.
3180 ;;; To suppress the read-time evaluation #. macro during source read,
3181 ;;; *READTABLE* is modified.
3182 ;;;
3183 ;;; FIXME: This breaks #+#.(cl:if ...) Maybe we need a SAFE-READ-EVAL, which
3184 ;;; this code can use for side- effect free #. calls?
3185 ;;;
3186 ;;; FIXME: This also knows nothing of custom readtables. The assumption
3187 ;;; is that the current readtable is a decent approximation for what
3188 ;;; we want, but that's lossy.
3196 rt)
3197 rt))
3199 ;;; Locate the source file (if it still exists) and grab the top level
3200 ;;; form. If the file is modified, or if we are in the middle of
3201 ;;; loading the file (so that the start positions map is not available
3202 ;;; yet), we use the top level form offset instead of the recorded
3203 ;;; character offset.
3210 ;; FIXME: External format?
3215 start-positions)
3220 "~%; File has been modified since compilation:~%; ~A"
3221 namestring))
3233 \f
3234 ;;;; PREPROCESS-FOR-EVAL
3236 ;;; Return a function of one argument that evaluates form in the
3237 ;;; lexical context of the BASIC-CODE-LOCATION LOC, or signal a
3238 ;;; NO-DEBUG-VARS condition when the LOC's DEBUG-FUN has no
3239 ;;; DEBUG-VAR information available.
3240 ;;;
3241 ;;; The returned function takes the frame to get values from as its
3242 ;;; argument, and it returns the values of FORM. The returned function
3243 ;;; can signal the following conditions: INVALID-VALUE,
3244 ;;; AMBIGUOUS-VAR-NAME, and FRAME-FUN-MISMATCH.
3277 (:valid
3279 (:more
3283 0
3285 (:unknown
3289 (:ambiguous
3293 ;; Process the symbol macros outside of the function to avoid
3294 ;; all those symbol-macrolets from showing in the sources if
3295 ;; there is a problem evaluating this form
3307 ;; This prevents these functions from being used in any
3308 ;; location other than a function return location, so maybe
3309 ;; this should only check whether FRAME's DEBUG-FUN is the
3310 ;; same as LOC's.
3316 ;;; EVAL-IN-FRAME
3320 "Evaluate FORM in the lexical context of FRAME's current code location,
3321 returning the results of the evaluation."
3323 \f
3324 ;;;; breakpoints
3326 ;;;; user-visible interface
3328 ;;; Create and return a breakpoint. When program execution encounters
3329 ;;; the breakpoint, the system calls HOOK-FUN. HOOK-FUN takes the
3330 ;;; current frame for the function in which the program is running and
3331 ;;; the breakpoint object.
3332 ;;;
3333 ;;; WHAT and KIND determine where in a function the system invokes
3334 ;;; HOOK-FUN. WHAT is either a code-location or a DEBUG-FUN. KIND is
3335 ;;; one of :CODE-LOCATION, :FUN-START, or :FUN-END. Since the starts
3336 ;;; and ends of functions may not have code-locations representing
3337 ;;; them, designate these places by supplying WHAT as a DEBUG-FUN and
3338 ;;; KIND indicating the :FUN-START or :FUN-END. When WHAT is a
3339 ;;; DEBUG-FUN and kind is :FUN-END, then HOOK-FUN must take two
3340 ;;; additional arguments, a list of values returned by the function
3341 ;;; and a FUN-END-COOKIE.
3342 ;;;
3343 ;;; INFO is information supplied by and used by the user.
3344 ;;;
3345 ;;; FUN-END-COOKIE is a function. To implement :FUN-END
3346 ;;; breakpoints, the system uses starter breakpoints to establish the
3347 ;;; :FUN-END breakpoint for each invocation of the function. Upon
3348 ;;; each entry, the system creates a unique cookie to identify the
3349 ;;; invocation, and when the user supplies a function for this
3350 ;;; argument, the system invokes it on the frame and the cookie. The
3351 ;;; system later invokes the :FUN-END breakpoint hook on the same
3352 ;;; cookie. The user may save the cookie for comparison in the hook
3353 ;;; function.
3354 ;;;
3355 ;;; Signal an error if WHAT is an unknown code-location.
3362 what))
3367 ;; This slot is filled in due to calling CODE-LOCATION-UNKNOWN-P.
3370 :unknown-return-partner
3371 info)))
3374 ;; (There used to be more cases back before sbcl-0.7.0,,
3375 ;; when we did special tricks to debug the IR1
3376 ;; interpreter.)
3377 )
3378 bpt))
3381 (:fun-start
3383 (:fun-end
3400 bpt))))))
3402 ;;; These are unique objects created upon entry into a function by a
3403 ;;; :FUN-END breakpoint's starter hook. These are only created
3404 ;;; when users supply :FUN-END-COOKIE to MAKE-BREAKPOINT. Also,
3405 ;;; the :FUN-END breakpoint's hook is called on the same cookie
3406 ;;; when it is created.
3412 ;; a pointer to the bpt-lra created for :FUN-END breakpoints
3414 ;; the DEBUG-FUN associated with this cookie
3417 ;;; This returns a hook function for the start helper breakpoint
3418 ;;; associated with a :FUN-END breakpoint. The returned function
3419 ;;; makes a fake LRA that all returns go through, and this piece of
3420 ;;; fake code actually breaks. Upon return from the break, the code
3421 ;;; provides the returnee with any values. Since the returned function
3422 ;;; effectively activates FUN-END-BPT on each entry to DEBUG-FUN's
3423 ;;; function, we must establish breakpoint-data about FUN-END-BPT.
3444 ;;; This takes a FUN-END-COOKIE and a frame, and it returns
3445 ;;; whether the cookie is still valid. A cookie becomes invalid when
3446 ;;; the frame that established the cookie has exited. Sometimes cookie
3447 ;;; holders are unaware of cookie invalidation because their
3448 ;;; :FUN-END breakpoint hooks didn't run due to THROW'ing.
3449 ;;;
3450 ;;; This takes a frame as an efficiency hack since the user probably
3451 ;;; has a frame object in hand when using this routine, and it saves
3452 ;;; repeated parsing of the stack and consing when asking whether a
3453 ;;; series of cookies is valid.
3460 lra
3463 \f
3464 ;;;; ACTIVATE-BREAKPOINT
3466 ;;; Cause the system to invoke the breakpoint's hook function until
3467 ;;; the next call to DEACTIVATE-BREAKPOINT or DELETE-BREAKPOINT. The
3468 ;;; system invokes breakpoint hook functions in the opposite order
3469 ;;; that you activate them.
3475 (:code-location
3483 ;; (There used to be more cases back before sbcl-0.7.0, when
3484 ;; we did special tricks to debug the IR1 interpreter.)
3485 )))
3486 (:fun-start
3490 ;; (There used to be more cases back before sbcl-0.7.0, when
3491 ;; we did special tricks to debug the IR1 interpreter.)
3492 ))
3493 (:fun-end
3498 ;; may already be active by some other :FUN-END breakpoint
3501 ;; (There used to be more cases back before sbcl-0.7.0, when
3502 ;; we did special tricks to debug the IR1 interpreter.)
3503 ))))
3504 breakpoint)
3511 breakpoint
3519 single-value-return-byte-offset
3526 breakpoint
3530 debug-fun))))))
3546 \f
3547 ;;;; DEACTIVATE-BREAKPOINT
3549 ;;; Stop the system from invoking the breakpoint's hook function.
3560 ;; (There used to be more cases back before sbcl-0.7.0, when
3561 ;; we did special tricks to debug the IR1 interpreter.)
3562 ))))
3563 breakpoint)
3585 breakpoint)
3586 \f
3587 ;;;; BREAKPOINT-INFO
3589 ;;; Return the user-maintained info associated with breakpoint. This
3590 ;;; is SETF'able.
3598 value)
3599 \f
3600 ;;;; BREAKPOINT-ACTIVE-P and DELETE-BREAKPOINT
3607 ;;; Free system storage and remove computational overhead associated
3608 ;;; with breakpoint. After calling this, breakpoint is completely
3609 ;;; impotent and can never become active again.
3628 nil))))))
3629 breakpoint)
3630 \f
3631 ;;;; C call out stubs
3633 ;;; This actually installs the break instruction in the component. It
3634 ;;; returns the overwritten bits. You must call this in a context in
3635 ;;; which GC is disabled, so that Lisp doesn't move objects around
3636 ;;; that C is pointing to.
3641 ;;; This removes the break instruction and replaces the original
3642 ;;; instruction. You must call this in a context in which GC is disabled
3643 ;;; so Lisp doesn't move objects around that C is pointing to.
3653 ;;;; breakpoint handlers (layer between C and exported interface)
3655 ;;; This maps components to a mapping of offsets to BREAKPOINT-DATAs.
3656 ;;; FIXME: these data should hang off of the component itself.
3660 ;;; This returns the BREAKPOINT-DATA object associated with component cross
3661 ;;; offset. If none exists, this makes one, installs it, and returns it.
3665 ;; Well, this has at least these three problems if not more:
3666 ;; 1. For the double-checked lock pattern to be correct we have to
3667 ;; re-check whether a key is in the table within the scope of the lock.
3668 ;; 2. The push should probably be a PUSHNEW, but even better, it too
3669 ;; needs to be locked or else dups can occur. Maybe use our newfangled
3670 ;; ordered lockfree linked lists.
3671 ;; 3. The hash-table should probably be weak keyed
3676 data))))
3685 ;;; We use this when there are no longer any active breakpoints
3686 ;;; corresponding to DATA.
3688 ;; Again, this looks brittle. Is there no danger of being interrupted
3689 ;; here?
3699 ;;; The C handler for interrupts calls this when it has a
3700 ;;; debugging-tool break instruction. This does *not* handle all
3701 ;;; breaks; for example, it does not handle breaks for internal
3702 ;;; errors.
3708 offset))
3714 offset component signal-context)))))
3716 ;;; This holds breakpoint-datas while invoking the breakpoint hooks
3717 ;;; associated with that particular component and location. While they
3718 ;;; are executing, if we hit the location again, we ignore the
3719 ;;; breakpoint to avoid infinite recursion. fun-end breakpoints
3720 ;;; must work differently since the breakpoint-data is unique for each
3721 ;;; invocation.
3724 ;;; This handles code-location and DEBUG-FUN :FUN-START
3725 ;;; breakpoints.
3733 ;; At this point breakpoints may not hold the same list as
3734 ;; BREAKPOINT-DATA-BREAKPOINTS since invoking hooks may have allowed
3735 ;; a breakpoint deactivation. In fact, if all breakpoints were
3736 ;; deactivated then data is invalid since it was deleted and so the
3737 ;; correct one must be looked up if it is to be used. If there are
3738 ;; no more breakpoints active at this location, then the normal
3739 ;; instruction has been put back, and we do not need to
3740 ;; DO-DISPLACED-INST.
3743 ;; The breakpoint is still active, so we need to execute the
3744 ;; displaced instruction and leave the breakpoint instruction
3745 ;; behind. The best way to do this is different on each machine,
3746 ;; so we just leave it up to the C code.
3749 ;; Some platforms have no usable sigreturn() call. If your
3750 ;; implementation of arch_do_displaced_inst() _does_ sigreturn(),
3751 ;; it's polite to warn here
3759 frame
3760 ;; If this is an :UNKNOWN-RETURN-PARTNER, then pass the
3761 ;; hook function the original breakpoint, so that users
3762 ;; aren't forced to confront the fact that some
3763 ;; breakpoints really are two.
3766 bpt)))))
3772 ;; KLUDGE: This argument is ignored on
3773 ;; x86oids in this scenario, but is
3774 ;; declared to be a SAP.
3777 nil)))
3784 offset))
3790 ;;; Either HANDLE-BREAKPOINT calls this for :FUN-END breakpoints
3791 ;;; [old C code] or HANDLE-FUN-END-BREAKPOINT calls this directly
3792 ;;; [new C code].
3794 ;; FIXME: This looks brittle: what if we are interrupted somewhere
3795 ;; here? ...or do we have interrupts disabled here?
3803 frame bpt
3805 cookie))))
3809 scp
3821 results))
3823 \f
3824 ;;;; MAKE-BPT-LRA (used for :FUN-END breakpoints)
3826 ;;; FIXME: why does this imply that it makes an LRA when it actually makes
3827 ;;; a code blob? Despite the rename in git rev 2437d7f139 apparently I took a cue
3828 ;;; from the former name ("MAKE-BOGUS-LRA") as if that spoke the truth.
3829 ;;; Make a breakpoint LRA object that signals a breakpoint trap when returned to.
3830 ;;; If the breakpoint trap handler returns, REAL-LRA is returned to.
3831 ;;; Three values are returned: the new LRA object, the code component it is part of,
3832 ;;; and the PC offset for the trap instruction.
3833 ;;; Note: you can't cache these, because object identity confers a full dynamic
3834 ;;; state of the program, not merely a return PC location.
3835 ;;; (I tried changing this to DEFUN-CACHED, which failed a regression test)
3837 (declare (type #-(or x86 x86-64 arm64 riscv) lra #+(or x86 x86-64 arm64 riscv) system-area-pointer real-lra))
3838 real-lra
3846 ;; These are really code labels, not variables: but this way we get
3847 ;; their addresses.
3850 src-start)))
3853 nil
3854 ;; Ensure required boxed header alignment.
3856 (+ length
3857 n-word-bytes ; Jump Table prefix word
3858 ;; Alignment padding, LRA header
3860 ;; 2 extra raw bytes represent CODE-N-ENTRIES (which is zero)
3871 ;; CODE-OBJECT is implicitly pinned after leaving WITH-PINNED-OBJECTS
3872 ;; (and would be pinned even if the W-P-O were deleted), so we're OK
3873 ;; to return a SAP to the instructions.
3874 ;; TRAP-OFFSET is the distance from CODE-INSTRUCTIONS to the trapping
3875 ;; opcode, for which we have to account for the jump table prefix word.
3879 ;; Skip over the jump table prefix, and align properly for LRA header
3881 ;; Compute the LRA->code backpointer in words
3884 lowtag-mask)))
3894 ;; FIXME: what does "3" represent in this formula?
3896 \f
3897 ;;;; miscellaneous
3899 ;;; This appears here because it cannot go with the DEBUG-FUN
3900 ;;; interface since DO-DEBUG-BLOCK-LOCATIONS isn't defined until after
3901 ;;; the DEBUG-FUN routines.
3903 ;;; Return a code-location before the body of a function and after all
3904 ;;; the arguments are in place; or if that location can't be
3905 ;;; determined due to a lack of debug information, return NIL.
3912 debug-fun))
3913 nil))
3914 ;; (There used to be more cases back before sbcl-0.7.0, when
3915 ;; we did special tricks to debug the IR1 interpreter.)
3916 ))
3918 \f
3919 ;;;; Single-stepping
3921 ;;; The single-stepper works by inserting conditional trap instructions
3922 ;;; into the generated code (see src/compiler/*/call.lisp), currently:
3923 ;;;
3924 ;;; 1) Before the code generated for a function call that was
3925 ;;; translated to a VOP
3926 ;;; 2) Just before the call instruction for a full call
3927 ;;;
3928 ;;; In both cases, the trap will only be executed if stepping has been
3929 ;;; enabled, in which case it'll ultimately be handled by
3930 ;;; HANDLE-SINGLE-STEP-TRAP, which will either signal a stepping condition,
3931 ;;; or replace the function that's about to be called with a wrapper
3932 ;;; which will signal the condition.
3936 ;; The following calls must get tail-call eliminated for
3937 ;; *STEP-FRAME* to get set correctly on non-x86.
3946 ;; If there was not enough debug information available, there's no
3947 ;; sense in signaling the condition.
3952 ;; We could theoretically store information in
3953 ;; the debug-info about to determine the
3954 ;; arguments here, but for now let's just pass
3955 ;; on it.
3958 ;;; This function will replace the fdefn / function that was in the
3959 ;;; register at CALLEE-REGISTER-OFFSET with a wrapper function. To
3960 ;;; ensure that the full call will use the wrapper instead of the
3961 ;;; original, conditional trap must be emitted before the fdefn /
3962 ;;; function is converted into a raw address.
3964 ;; Fetch the function / fdefn we're about to call from the
3965 ;; appropriate register.
3967 #+linkage-space
3969 #-linkage-space
3973 ;; If there was not enough debug information available, there's no
3974 ;; sense in signaling the condition.
3982 args)))
3983 ;; Signal a step condition
3987 ;; And proceed based on its return value.
3989 ;; STEP-INTO was selected. Use *STEP-OUT* to
3990 ;; let the stepper know that selecting the
3991 ;; STEP-OUT restart is valid inside this
3993 ;; Pass the return values of the call to
3994 ;; STEP-VALUES, which will signal a
3995 ;; condition with them in the VALUES slot.
3998 step-info
4000 ;; If the user selected the STEP-OUT
4001 ;; restart during the call, resume
4002 ;; stepping
4005 ;; STEP-NEXT / CONTINUE / OUT selected:
4006 ;; Disable the stepper for the duration of
4007 ;; the call.
4012 #-linkage-space
4016 fdefn))
4018 ;; And then store the wrapper in the same place.
4020 ;; %SET-CONTEXT-REGISTER is a function, so the address of
4021 ;; NEW-CALLEE gets converted to a fixnum before passing, which
4022 ;; won't keep NEW-CALLEE pinned down. Once it's inside
4023 ;; CONTEXT, which is registered in thread->interrupt_contexts,
4024 ;; it will properly point to NEW-CALLEE.
4027 ;; the new callee is a funcallable instance that jumps to FUN.
4028 ;; Point the callee register to the address of the FIN's trampoline word
4034 #+untagged-fdefns
4036 #-untagged-fdefns
4039 ;;; Given a signal context, fetch the step-info that's been stored in
4040 ;;; the debug info at the trap point.
4046 pc-offset
4047 nil)))
4054 nil)))))
4056 ;;; Return the frame that triggered a single-step condition. Used to
4057 ;;; provide a *STACK-TOP-HINT*.
4062 ;;;; fetching errorful function name
4064 ;;; This flag is used to prevent infinite recursive lossage when
4065 ;;; we can't find the caller for some reason.
4074 frame)