(sb!alien:define-alien-routine component-ptr-from-pc (system-area-pointer)
(pc system-area-pointer))
-#!+(or x86 x86-64)
+#!+gencgc
(sb!alien:define-alien-routine valid-lisp-pointer-p sb!alien:int
(pointer system-area-pointer))
;; unbound marker
(= val sb!vm:unbound-marker-widetag)
;; pointer
- #!+(or x86 x86-64)
+ #!+gencgc
(not (zerop (valid-lisp-pointer-p (int-sap val))))
;; FIXME: There is no fundamental reason not to use the above
;; function on other platforms as well, but I didn't have
;; others available while doing this. --NS 2007-06-21
- #!-(or x86 x86-64)
+ #!-gencgc
(and (logbitp 0 val)
(or (< sb!vm:read-only-space-start val
(* sb!vm:*read-only-space-free-pointer*
(lispobj *)pointer));
}
-#if defined(LISP_FEATURE_X86) || defined(LISP_FEATURE_X86_64)
-
/* Helper for valid_lisp_pointer_p and
* possibly_valid_dynamic_space_pointer.
*
}
break;
case OTHER_POINTER_LOWTAG:
+
+#if !defined(LISP_FEATURE_X86) && !defined(LISP_FEATURE_X86_64)
+ /* The all-architecture test below is good as far as it goes,
+ * but an LRA object is similar to a FUN-POINTER: It is
+ * embedded within a CODE-OBJECT pointed to by start_addr, and
+ * cannot be found by simply walking the heap, therefore we
+ * need to check for it. -- AB, 2010-Jun-04 */
+ if ((widetag_of(start_addr[0]) == CODE_HEADER_WIDETAG)) {
+ lispobj *potential_lra =
+ (lispobj *)(((unsigned long)pointer) - OTHER_POINTER_LOWTAG);
+ if ((widetag_of(potential_lra[0]) == RETURN_PC_HEADER_WIDETAG) &&
+ ((potential_lra - HeaderValue(potential_lra[0])) == start_addr)) {
+ return 1; /* It's as good as we can verify. */
+ }
+ }
+#endif
+
if ((unsigned long)pointer !=
((unsigned long)start_addr+OTHER_POINTER_LOWTAG)) {
if (gencgc_verbose) {
return 0;
}
+#if defined(LISP_FEATURE_X86) || defined(LISP_FEATURE_X86_64)
+
/* Is there any possibility that pointer is a valid Lisp object
* reference, and/or something else (e.g. subroutine call return
* address) which should prevent us from moving the referred-to thing?
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.39.5"
+"1.0.39.6"