Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64

[Paul Eggert <eggert@cs.ucla.edu>]

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

Eli Zaretskii wrote:

> Maybe we should poll this list about this

In effect we've already probed about it in this thread. Others are welcome to 
chime in.

> even the latest GDB can be built without Python. It's a configure-time option.

The configure-time option defaults to "yes" if Python is installed, which it 
typically is nowadays. It's been "yes" in the major GNU/Linux distributions for 
years, and even MinGW now ships a Python-enabled GDB. So this should not be a 
major problem for developers in practice.

> I'm not sure I like this XIL(something) feature.  For starters, it
> deviates from the format I'm used to, and takes precious screen
> estate.

One gets used to it, and it has the advantage of easily distinguishing 
Lisp_Object from integer values when debugging, which is worth some screen real 
estate.

> It also might confuse people who know GDB but won't
> immediately grasp what "XIL" is.

The confusion won't last long, and any confusion is outweighed by the clarity 
caused by GDB's now distinguishing Lisp_Object values from C integers. I don't 
see this as turning into a real problem, but if I'm wrong I suppose we can 
rename XIL to something more mnemonic.

>   (gdb) p Qnil
>   $2 = 0
>   (gdb) p ignore
>   $3 = XIL(0)

Ah, I didn't think about pretty-printing constants. I fixed that by installing 
the first attached patch. I also tried out a somewhat-older GDB implementation 
(Ubuntu LTS) and fixed some other glitches in the second attached patch. 
However, we shouldn't need to spend a lot of time worrying about glitches with 
ancient debuggers, as we can expect developers to be reasonably up-to-date.

> something whose value is zero is numerically equal to something
> whose value is XIL(0).

Sure, because XIL(0) == 0 when --enable-lisp-object-types=no. Pretty-printing 
doesn't change that.

> As for "some day the pretty-printing could be fancier": what exactly
> did you want to implement?

I wasn't planning anything exactly. The general principle is that the GDB 
pretty-printer should output a string that you can paste back into GDB. (In 
contrast, the long-established "pp" command should output a string that you can 
paste into Elisp.) GDB could pretty-print the Lisp integer 27 as 
"make_number(27)", for example.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Pretty-print-const-Lisp_Objects-in-.gdbinit.patch --]
[-- Type: text/x-diff; name="0001-Pretty-print-const-Lisp_Objects-in-.gdbinit.patch", Size: 1233 bytes --]

From 7cd7f5b4032092389a00e23af3ab435628febed3 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 6 May 2017 14:24:12 -0700
Subject: [PATCH 1/2] Pretty-print const Lisp_Objects in .gdbinit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/.gdbinit (Emacs_Pretty_Printers.__call__):
Compare unqualified type to Lisp_Object, to do the right thing
when the expression has type ‘Lisp_Object const’.
Problem reported by Eli Zaretskii in:
http://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00138.html
---
 src/.gdbinit | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/.gdbinit b/src/.gdbinit
index 0596188..29689e2 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1280,7 +1280,7 @@ if hasattr(gdb, 'printing'):
        RegexpCollectionPrettyPrinter except when printing Lisp_Object."""
     def __call__ (self, val):
       """Look up the pretty-printer for the provided value."""
-      type = val.type
+      type = val.type.unqualified ()
       typename = type.tag or type.name
       basic_type = gdb.types.get_basic_type (type)
       basic_typename = basic_type.tag or basic_type.name
-- 
2.7.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Port-.gdbinit-to-GDB-7.11.1-Python-2.7.12.patch --]
[-- Type: text/x-diff; name="0002-Port-.gdbinit-to-GDB-7.11.1-Python-2.7.12.patch", Size: 1395 bytes --]

From f31689c803a13836ef3528d6e2b4c98c767c42c7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 6 May 2017 15:29:16 -0700
Subject: [PATCH 2/2] Port .gdbinit to GDB 7.11.1 + Python 2.7.12

* src/.gdbinit (Lisp_Object_Printer.to_string):
Explicitly convert integer val to 'int', so that
older GDBs do not complain about the conversion.
* src/lisp.h (Lisp_Object) [CHECK_LISP_OBJECT_TYPE]:
Give the struct a tag, so that older GDB pretty-printers have a
tag to hang their hat on.
---
 src/.gdbinit | 2 +-
 src/lisp.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/.gdbinit b/src/.gdbinit
index 29689e2..80aa95b 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1311,7 +1311,7 @@ if hasattr(gdb, 'printing'):
       # pretty-printing could be fancier.
       if not val:
         return "XIL(0)" # Easier to read than "XIL(0x0)".
-      return "XIL(0x%x)" % val
+      return "XIL(0x%x)" % int(val)
 
   def build_pretty_printer ():
     pp = Emacs_Pretty_Printers ("Emacs")
diff --git a/src/lisp.h b/src/lisp.h
index 5d4c64a..de3a548 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -546,7 +546,7 @@ enum Lisp_Fwd_Type
 
 #ifdef CHECK_LISP_OBJECT_TYPE
 
-typedef struct { EMACS_INT i; } Lisp_Object;
+typedef struct Lisp_Object { EMACS_INT i; } Lisp_Object;
 
 #define LISP_INITIALLY(i) {i}
 
-- 
2.7.4