Re: inlinable functions instead of macros

[Paul Eggert]

On 08/21/2012 10:50 AM, Stefan Monnier wrote:

> Could some please check our inlinable functions and move any easserts in
> them to a macro (i.e. rename the function, replace the old name with
> a macro that does the assert and calls the inlinable function)?

I took a look at doing this, but it's problematic.

I assume we want to do this only with the "small" functions -- where
we're not interested in the function itself, but in the function's
caller.  Doing it with all inlinable functions would not be useful,
since so many functions are inlinable these days.

Unfortunately wrapping "small" functions with macros breaks down in
the common case where the caller is another "small" function.  For
example, set_hash_key_slot is a "small" function, and it calls another
"small" function gc_aset, which invokes eassert.  If both functions
are wrapped, an assertion failure in the inner reports the outer's
location, instead of what's wanted (the outer's caller's location).

How about if we try the following instead?  It's easier to implement
and is less intrusive to the code.  The idea is to use the <execinfo.h>
change that I mentioned in my previous message (a change we
should do independently anyway).  With that change, when an assertion
fails, it will generate output that looks like this:

alloc.c:800: Emacs fatal error: assertion failed: 0 <= nitems && 0 < item_size
./temacs[0x5bbdaf]
./temacs[0x5bf5e2]
./temacs[0x549cbd]
./temacs[0x417681]
/lib64/libc.so.6(__libc_start_main+0xed)[0x3b3082135d]
./temacs[0x418d85]

You can then find out the source locations corresponding to the
backtrace by giving those addresses to the debugger, like this:

$ gdb temacs
...
(gdb) b *0x5bbdaf
Breakpoint 2 at 0x5bbdaf: file alloc.c, line 6698.
(gdb) b *0x5bf5e2
Breakpoint 3 at 0x5bf5e2: file alloc.c, line 802.
(gdb) b *0x549cbd
Breakpoint 4 at 0x549cbd: file emacs.c, line 1799.

The top of the stack is 'die' itself; the second slot is the "small"
function xnmalloc; the third slot is the "big" function sort_args,
where it calls xnmalloc.

This gives all the information that the current scheme does, plus
more, because you have a full backtrace.  Once we have this, we
shouldn't need to create extra macro wrappers and address the extra
hassles that they'd cause.