[Top][All Lists]

[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: Eli Zaretskii
Subject: Re: Enabling --enable-check-lisp-object-type by default on x86 and AMD64
Date: Sat, 06 May 2017 10:07:10 +0300

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> 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.


> +    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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]