# HG changeset patch
# User Eli Zaretskii <eliz@gnu.org>
# Date 985632238 0
# Node ID f8dd0e40dc346aa38fa6d31ff6a3118b13005386
# Parent  b7aa7cc5bd4b1111f8a392e97d5b3b5db6246a11
Make it clear that last_marked[] holds pointers to Lisp objects, not
the objects themselves.

diff -r b7aa7cc5bd4b -r f8dd0e40dc34 etc/DEBUG
--- a/etc/DEBUG	Mon Mar 26 17:54:34 2001 +0000
+++ b/etc/DEBUG	Mon Mar 26 18:43:58 2001 +0000
@@ -410,10 +410,13 @@
 
 ** Debugging problems which happen in GC
 
-The array `last_marked' (defined on alloc.c) can be used to display
-up to 500 last objects marked by the garbage collection process.  The
-variable `last_marked_index' holds the index into the `last_marked'
-array one place beyond where the very last marked object is stored.
+The array `last_marked' (defined on alloc.c) can be used to display up
+to 500 last objects marked by the garbage collection process.
+Whenever a Lisp object is marked by the garbage collector, it records
+the pointer to that object in the `last_marked' array.  The variable
+`last_marked_index' holds the index into the `last_marked' array one
+place beyond where the pointer to the very last marked object is
+stored.
 
 The single most important goal in debugging GC problems is to find the
 Lisp data structure that got corrupted.  This is not easy since GC