GNU bug report logs - #11935
XINT etc. should be functions

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Fri, 13 Jul 2012 15:15:02 UTC

Severity: wishlist

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #62 received at 11935 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 11935 <at> debbugs.gnu.org
Subject: Re: bug#11935: XINT etc. should be functions
Date: Tue, 24 Jul 2012 21:07:28 -0700
On 07/24/2012 02:57 PM, Stefan Monnier wrote:

> It seems to define XLI first as
> a macro then as a function.  Is that right?

Yes.  The macro is purely for performance with -O0.
The function is for all other purposes, including
having XLI work in expressions given to GDB.

> why is it any better than using only the macro form?

Mostly for debuggability, though there's also a small
performance win when compiling with default (-O2)
optimization.  Having the functions makes GDB more useful
when printing expressions.  Here's a trivial example:

  (gdb) p SYMBOLP (Qnil)
  $3 = 1

With the patch, this works if one compiles with -g -O0,
regardless of whether -DINLINING=0 is also specified.
This is because SYMBOLP is defined as a function,
regardless of whether it is also defined as a macro.

Also, having the functions makes backtraces work better,
even when compiling with default optimization.  For example,
here's the start of a GDB backtrace of a patched Emacs
compiled with default optimization:

   (gdb) where
   #0  XTYPE (a=0) at lisp.h:461
   #1  VECTORLIKEP (x=0) at lisp.h:2018
   #2  PSEUDOVECTORP (code=2, a=0) at lisp.h:2080
   #3  PROCESSP (a=0) at lisp.h:2102
   #4  Fget_process (name=0) at process.c:680
   #5  0x0000000000573e87 in eval_sub (form=form <at> entry=16514534) at eval.c:2146
   ...

When the macro forms are used, levels #0 through #3 are lost,
which makes things harder to follow, particularly when one
is not expert in the code.

This debuggability win is partly lost when compiling with
plain -O0, because then some functions turn into macros.
But that's OK, since one can compile with -O0 -DINLINING=0
to get nicer debugging.





This bug report was last modified 5 years and 119 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.