bug#27098: 26.0.50; Wrong display of negative Lisp_Object values

bug#27098: 26.0.50; Wrong display of negative Lisp_Object values

[Eli Zaretskii]

To reproduce, run Emacs under GDB with src/.gdbinit in effect, then
display a Lisp_Object value.  On my system, where Lis_Object values
are 64-bit values with the sign bit set, I see something like this:

  (gdb) print current_buffer->name_
  $1 = XIL(0x-7ffffffffe851450)

which displays the negative sign after the 0x prefix.  But even if we
remove the minus, the value after it is misleading:

  (gdb) print current_buffer->name_.i
  $2 = -9223372036829942864
  (gdb) print/x current_buffer->name_.i
  $3 = 0x80000000017aebb0

Is it possible to tweak the Python parts of src/.gdbinit to display
XIL(0x80000000017aebb0), not XIL(0x-7ffffffffe851450)?

In GNU Emacs 26.0.50 (build 531, i686-pc-mingw32)
 of 2017-05-27 built on HOME-C4E4A596F7
Repository revision: 6f63c7cb6a02d913d195410e4df85fad5832db06
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int
 --with-modules 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs pcase cl-lib dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 101600 11038)
 (symbols 56 21118 1)
 (miscs 48 42 108)
 (strings 16 21005 4762)
 (string-bytes 1 595878)
 (vectors 16 14676)
 (vector-slots 8 480299 6161)
 (floats 8 54 93)
 (intervals 40 269 104)
 (buffers 864 11))

bug#27098: 26.0.50; Wrong display of negative Lisp_Object values

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

I installed the attached, which should fix the bug, and also improve display of 
integers while we're in the neighborhood.

[-- Attachment #2: 0001-Improve-.gdbinit-Lisp-value-pretty-printing.patch --]
[-- Type: text/x-patch, Size: 3476 bytes --]

From 17a62fe533f5d550f2a766b4b8d7bdfde233093c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 29 May 2017 17:15:11 -0700
Subject: [PATCH] Improve .gdbinit Lisp value pretty-printing

* src/.gdbinit (to_string): Use an unsigned representation for
Lisp values, as requested by Eli Zaretskii (Bug#27098).
Also, use "make_number(N)" for Lisp integers.
---
 src/.gdbinit | 51 +++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/src/.gdbinit b/src/.gdbinit
index 80aa95b..b5a974b 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1300,18 +1300,52 @@ if hasattr(gdb, 'printing'):
 
     def to_string (self):
       "Yield a string that can be fed back into GDB."
+
+      # This implementation should work regardless of C compiler, and
+      # it should not attempt to run any code in the inferior.
+      EMACS_INT_WIDTH = int(gdb.lookup_symbol("EMACS_INT_WIDTH")[0].value())
+      USE_LSB_TAG = int(gdb.lookup_symbol("USE_LSB_TAG")[0].value())
+      GCTYPEBITS = 3
+      VALBITS = EMACS_INT_WIDTH - GCTYPEBITS
+      Lisp_Int0 = 2
+      Lisp_Int1 = 6 if USE_LSB_TAG else 3
+
+      # Unpack the Lisp value from its containing structure, if necessary.
       val = self.val
       basic_type = gdb.types.get_basic_type (val.type)
       if (basic_type.code == gdb.TYPE_CODE_STRUCT
           and gdb.types.has_field (basic_type, "i")):
         val = val["i"]
-      # Yield "XIL(N)", where N is a C integer.  This helps humans
-      # distinguish Lisp_Object values from ordinary integers even
-      # when Lisp_Object is an integer.  Perhaps some day the
-      # pretty-printing could be fancier.
+
+      # For nil, yield "XIL(0)", which is easier to read than "XIL(0x0)".
       if not val:
-        return "XIL(0)" # Easier to read than "XIL(0x0)".
-      return "XIL(0x%x)" % int(val)
+        return "XIL(0)"
+
+      # Extract the integer representation of the value and its Lisp type.
+      ival = int(val)
+      itype = ival >> (0 if USE_LSB_TAG else VALBITS)
+      itype = itype & ((1 << GCTYPEBITS) - 1)
+
+      # For a Lisp integer N, yield "make_number(N)".
+      if itype == Lisp_Int0 or itype == Lisp_Int1:
+        if USE_LSB_TAG:
+          ival = ival >> (GCTYPEBITS - 1)
+        elif (ival >> VALBITS) & 1:
+          ival = ival | (-1 << VALBITS)
+        else:
+          ival = ival & ((1 << VALBITS) - 1)
+        return "make_number(%d)" % ival
+
+      # For non-integers other than nil yield "XIL(N)", where N is a C integer.
+      # This helps humans distinguish Lisp_Object values from ordinary
+      # integers even when Lisp_Object is an integer.
+      # Perhaps some day the pretty-printing could be fancier.
+      # Prefer the unsigned representation to negative values, converting
+      # by hand as val.cast(gdb.lookup_type("EMACS_UINT") does not work in
+      # GDB 7.12.1; see <http://patchwork.sourceware.org/patch/11557/>.
+      if ival < 0:
+        ival = ival + (1 << EMACS_INT_WIDTH)
+      return "XIL(0x%x)" % ival
 
   def build_pretty_printer ():
     pp = Emacs_Pretty_Printers ("Emacs")
@@ -1321,3 +1355,8 @@ if hasattr(gdb, 'printing'):
   gdb.printing.register_pretty_printer (gdb.current_objfile (),
                                         build_pretty_printer (), True)
 end
+
+# GDB mishandles indentation with leading tabs when feeding it to Python.
+# Local Variables:
+# indent-tabs-mode: nil
+# End:
-- 
2.7.4

bug#27098: 26.0.50; Wrong display of negative Lisp_Object values

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 29 May 2017 17:19:56 -0700
> 
> I installed the attached, which should fix the bug, and also improve display of 
> integers while we're in the neighborhood.

Thanks!