1.0.39.6: valid_lisp_pointer_p() is gencgc-specific, not x86oid-specific.
authorAlastair Bridgewater <lisphacker@users.sourceforge.net>
Sun, 6 Jun 2010 19:43:30 +0000 (19:43 +0000)
committerAlastair Bridgewater <lisphacker@users.sourceforge.net>
Sun, 6 Jun 2010 19:43:30 +0000 (19:43 +0000)
  * Changed SB-KERNEL:MAKE-LISP-OBJ (src/code/debug-int) to use
valid-lisp-pointer-p on all gencgc targets, not just x86oids.

  * Changed valid_lisp_pointer_p() (src/runtime/gencgc.c) to build on
all targets, not just x86oids.

  * Added a special-case to looks_like_valid_lisp_pointer_p() to
correctly handle LRA objects (RETURN_PC_HEADER_WIDETAG) on non-x86oid
targets (though, really, we probably should have an :IMPLICIT-LRA
feature for this sort of nonsense).

src/code/debug-int.lisp
src/runtime/gencgc.c
version.lisp-expr

index 63b899b..9554efe 100644 (file)
 (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))
 
@@ -1970,12 +1970,12 @@ register."
        ;; 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*
index 9ce74d4..c856c86 100644 (file)
@@ -2214,8 +2214,6 @@ search_dynamic_space(void *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.
  *
@@ -2304,6 +2302,23 @@ looks_like_valid_lisp_pointer_p(lispobj *pointer, lispobj *start_addr)
         }
         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) {
@@ -2499,6 +2514,8 @@ valid_lisp_pointer_p(lispobj *pointer)
         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?
index 74e2e5a..4b1d5b8 100644 (file)
@@ -17,4 +17,4 @@
 ;;; 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"