[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11935: XINT etc. should be functions

From: Paul Eggert
Subject: bug#11935: XINT etc. should be functions
Date: Tue, 24 Jul 2012 21:07:28 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0

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 (address@hidden) 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.

reply via email to

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