all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: p.stephani2@gmail.com, emacs-devel@gnu.org
Subject: Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64
Date: Sat, 06 May 2017 10:07:10 +0300	[thread overview]
Message-ID: <83lgqafopt.fsf@gnu.org> (raw)
In-Reply-To: <764aeab0-964a-3225-d236-d44853f888a0@cs.ucla.edu> (message from Paul Eggert on Fri, 5 May 2017 16:23:52 -0700)

> Cc: p.stephani2@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 5 May 2017 16:23:52 -0700
> 
> On 05/03/2017 11:22 AM, Eli Zaretskii wrote:
> > This is better, but how sure we are people's GDB is built with Python
> > support?
> 
> We can ask developers to upgrade. GDB pretty-printing has worked with 
> embedded Python for several years (since GDB 7.3 in 2011, I believe). We 
> are not talking about general Emacs users here, only developers who are 
> building bleeding-edge Emacs from Git.

We are talking about anyone who could submit backtraces from the Git
master builds.  I don't know who that might be (e.g., aren't there
snapshots of master provided by the various GNU/Linux distros?), but
even if we only consider people who are on this list, I'm not sure how
many of them have GDB built with Python support.  Maybe we should poll
this list about this, it cannot be that hard.

> It's reasonable to expect these folks to have reasonably modern
> tools

The GDB version is not the issue here, because even the latest GDB can
be built without Python.  It's a configure-time option.

> > Why not make this part of .gdbinit itself? 
> 
> Sure, we can do that.
> 
> > Also, the Python script should be a bit smarter, to support also the
> > compilation without --enable-check-lisp-object-type.  When I try this
> > script in such a build, GDB crashes when displaying a backtrace.
> Also doable.

Thanks.

> +    def to_string (self):
> +      "Yield a string that can be fed back into GDB."
> +      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.
> +      if not val:
> +        return "XIL(0)" # Easier to read than "XIL(0x0)".
> +      return "XIL(0x%x)" % val

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.  It also might confuse people who know GDB but won't
immediately grasp what "XIL" is.  It also introduces certain
inconsistencies, e.g. (in a build without --enable-check-lisp-object-type):

  (gdb) fr 28
  #28 0x011586e2 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1112
  1112        val = internal_condition_case (command_loop_1, Qerror, cmd_error);
  (gdb) p ignore == Qnil
  $1 = 1
  (gdb) p Qnil
  $2 = 0
  (gdb) p ignore
  $3 = XIL(0)

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

As for "some day the pretty-printing could be fancier": what exactly
did you want to implement?  Guile has a pretty elaborate GDB support
for printing Scheme values, perhaps you could look there for
inspiration.



  reply	other threads:[~2017-05-06  7:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 20:05 bug#26597: 25.1; Compilation error on master with --enable-check-lisp-object-type Philipp Stephani
2017-04-22  7:42 ` Eli Zaretskii
2017-04-22 11:57   ` Philipp Stephani
2017-04-22 13:35     ` Andreas Schwab
2017-05-01 11:26       ` Philipp Stephani
2017-04-22 13:36     ` Eli Zaretskii
2017-05-01 11:32       ` 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-02 22:14         ` Enabling --enable-check-lisp-object-type by default on x86 and AMD64 Paul Eggert
2017-05-03  2:38           ` Eli Zaretskii
2017-05-03  3:24             ` Paul Eggert
2017-05-03 14:48               ` Eli Zaretskii
2017-05-03 18:08                 ` Paul Eggert
2017-05-03 18:22                   ` Eli Zaretskii
2017-05-04 14:33                     ` Eli Zaretskii
2017-05-05 23:23                     ` Paul Eggert
2017-05-06  7:07                       ` Eli Zaretskii [this message]
2017-05-06 23:23                         ` Paul Eggert
2017-05-01 12:20     ` bug#26597: 25.1; Compilation error on master with --enable-check-lisp-object-type Stefan Monnier
2017-05-01 14:33       ` Philipp Stephani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lgqafopt.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.