[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64
From: |
Paul Eggert |
Subject: |
Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64 |
Date: |
Sat, 6 May 2017 16:23:14 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
0001-Pretty-print-const-Lisp_Objects-in-.gdbinit.patch
Description: Text Data
0002-Port-.gdbinit-to-GDB-7.11.1-Python-2.7.12.patch
Description: Text Data
- Enabling --enable-check-lisp-object-type by default on x86 and AMD64 (was: Re: bug#26597: 25.1; Compilation error on master with --enable-check-lisp-object-type), Philipp Stephani, 2017/05/01
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Paul Eggert, 2017/05/02
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Eli Zaretskii, 2017/05/02
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Paul Eggert, 2017/05/02
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Eli Zaretskii, 2017/05/03
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Paul Eggert, 2017/05/03
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Eli Zaretskii, 2017/05/03
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Eli Zaretskii, 2017/05/04
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Paul Eggert, 2017/05/05
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64, Eli Zaretskii, 2017/05/06
- Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64,
Paul Eggert <=