In GDB scripts, don't assume that EMACS_INT fits in long.

* etc/emacs-buffer.gdb ($valmask): Don't assume EMACS_INT fits in 'long'.
* src/.gdbinit (xreload): Likewise.

2 files changed, 6 insertions, 1 deletions

diff --git a/src/.gdbinit b/src/.gdbinit
index 74dbd7a4197..7cd828733b1 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1259,7 +1259,9 @@ end
 
 define xreload
   set $tagmask = (((long)1 << gdb_gctypebits) - 1)
-  set $valmask = gdb_use_lsb ? ~($tagmask) : ((long)1 << gdb_valbits) - 1
+  # The consing_since_gc business widens the 1 to EMACS_INT,
+  # a symbol not directly visible to GDB.
+  set $valmask = gdb_use_lsb ? ~($tagmask) : ((consing_since_gc - consing_since_gc + 1) << gdb_valbits) - 1
 end
 document xreload
   When starting Emacs a second time in the same gdb session under
diff --git a/src/ChangeLog b/src/ChangeLog
index 911799b2bd2..bd376e9b855 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,5 +1,8 @@
 2012-02-20  Paul Eggert  <eggert@cs.ucla.edu>
 
+        * .gdbinit (xreload): Don't assume EMACS_INT fits in 'long'
+        when computing $valmask.
+
         Fix crash due to non-contiguous EMACS_INT (Bug#10780).
         * lisp.h (VALBITS): Move definition up, so that USE_LSB_TAG can use it.
         (USE_LSB_TAG): Do not define if UINTPTR_MAX >> VALBITS == 0.