From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64 Date: Sat, 6 May 2017 16:23:14 -0700 Organization: UCLA Computer Science Department Message-ID: <82beda4e-1f31-4dce-b5b4-6344f01f44ce@cs.ucla.edu> References: <83mvb8riq0.fsf@gnu.org> <83a878r2d0.fsf@gnu.org> <60379b71-bd6a-5f6f-dec1-523d6f4b2016@cs.ucla.edu> <83vapihdgs.fsf@gnu.org> <83shkmgfnh.fsf@gnu.org> <777fd9a2-232a-e52c-0a51-3d287567fb2e@cs.ucla.edu> <83efw5hkby.fsf@gnu.org> <764aeab0-964a-3225-d236-d44853f888a0@cs.ucla.edu> <83lgqafopt.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------A62E9EBAB997AD9979CD3071" X-Trace: blaine.gmane.org 1494113018 29982 195.159.176.226 (6 May 2017 23:23:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 May 2017 23:23:38 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cc: p.stephani2@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 07 01:23:30 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d792v-0007cX-Tv for ged-emacs-devel@m.gmane.org; Sun, 07 May 2017 01:23:30 +0200 Original-Received: from localhost ([::1]:52997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d792y-0003RI-CM for ged-emacs-devel@m.gmane.org; Sat, 06 May 2017 19:23:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d792q-0003Pz-Kg for emacs-devel@gnu.org; Sat, 06 May 2017 19:23:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d792p-0006Cd-5M for emacs-devel@gnu.org; Sat, 06 May 2017 19:23:24 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55412) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d792j-0006AQ-NY; Sat, 06 May 2017 19:23:17 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 64E84160070; Sat, 6 May 2017 16:23:16 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8JpLvHo_45m7; Sat, 6 May 2017 16:23:15 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E9F4E1600B9; Sat, 6 May 2017 16:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WT8NN0xDICuH; Sat, 6 May 2017 16:23:14 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.153.188.248]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B55CD160070; Sat, 6 May 2017 16:23:14 -0700 (PDT) In-Reply-To: <83lgqafopt.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214639 Archived-At: This is a multi-part message in MIME format. --------------A62E9EBAB997AD9979CD3071 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Eli Zaretskii wrote: > Maybe we should poll this list about this In effect we've already probed about it in this thread. Others are welcom= e to=20 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=20 typically is nowadays. It's been "yes" in the major GNU/Linux distributio= ns for=20 years, and even MinGW now ships a Python-enabled GDB. So this should not = be a=20 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=20 Lisp_Object from integer values when debugging, which is worth some scree= n real=20 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 cla= rity=20 caused by GDB's now distinguishing Lisp_Object values from C integers. I = don't=20 see this as turning into a real problem, but if I'm wrong I suppose we ca= n=20 rename XIL to something more mnemonic. > (gdb) p Qnil > $2 =3D 0 > (gdb) p ignore > $3 =3D XIL(0) Ah, I didn't think about pretty-printing constants. I fixed that by insta= lling=20 the first attached patch. I also tried out a somewhat-older GDB implement= ation=20 (Ubuntu LTS) and fixed some other glitches in the second attached patch.=20 However, we shouldn't need to spend a lot of time worrying about glitches= with=20 ancient debuggers, as we can expect developers to be reasonably up-to-dat= e. > something whose value is zero is numerically equal to something > whose value is XIL(0). Sure, because XIL(0) =3D=3D 0 when --enable-lisp-object-types=3Dno. Prett= y-printing=20 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= =20 pretty-printer should output a string that you can paste back into GDB. (= In=20 contrast, the long-established "pp" command should output a string that y= ou can=20 paste into Elisp.) GDB could pretty-print the Lisp integer 27 as=20 "make_number(27)", for example. --------------A62E9EBAB997AD9979CD3071 Content-Type: text/x-diff; name="0001-Pretty-print-const-Lisp_Objects-in-.gdbinit.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Pretty-print-const-Lisp_Objects-in-.gdbinit.patch" =46rom 7cd7f5b4032092389a00e23af3ab435628febed3 Mon Sep 17 00:00:00 2001 From: Paul Eggert 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=3DUTF-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 =E2=80=98Lisp_Object const=E2=80=99. 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 =3D val.type + type =3D val.type.unqualified () typename =3D type.tag or type.name basic_type =3D gdb.types.get_basic_type (type) basic_typename =3D basic_type.tag or basic_type.name --=20 2.7.4 --------------A62E9EBAB997AD9979CD3071 Content-Type: text/x-diff; name="0002-Port-.gdbinit-to-GDB-7.11.1-Python-2.7.12.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-Port-.gdbinit-to-GDB-7.11.1-Python-2.7.12.patch" =46rom f31689c803a13836ef3528d6e2b4c98c767c42c7 Mon Sep 17 00:00:00 2001 From: Paul Eggert 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) =20 def build_pretty_printer (): pp =3D 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 =20 #ifdef CHECK_LISP_OBJECT_TYPE =20 -typedef struct { EMACS_INT i; } Lisp_Object; +typedef struct Lisp_Object { EMACS_INT i; } Lisp_Object; =20 #define LISP_INITIALLY(i) {i} =20 --=20 2.7.4 --------------A62E9EBAB997AD9979CD3071--