From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: inlinable functions instead of macros
Date: Wed, 22 Aug 2012 02:28:52 -0700 [thread overview]
Message-ID: <5034A654.2080909@cs.ucla.edu> (raw)
In-Reply-To: <jwvzk5okufw.fsf-monnier+emacs@gnu.org>
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.
next prev parent reply other threads:[~2012-08-22 9:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-17 23:48 inlinable functions instead of macros Stefan Monnier
2012-08-17 23:59 ` Paul Eggert
2012-08-18 22:15 ` Daniel Colascione
2012-08-18 22:55 ` John Yates
2012-08-19 4:22 ` Richard Stallman
2012-08-21 17:50 ` Stefan Monnier
2012-08-22 9:24 ` C backtraces for Emacs Paul Eggert
2012-08-22 16:01 ` Eli Zaretskii
2012-08-22 16:39 ` Paul Eggert
2012-08-23 0:40 ` Daniel Colascione
2012-08-23 16:55 ` Eli Zaretskii
2012-08-24 10:48 ` Paul Eggert
2012-08-25 4:41 ` Paul Eggert
2012-08-25 5:57 ` Eli Zaretskii
2012-08-22 9:28 ` Paul Eggert [this message]
2012-08-22 9:48 ` inlinable functions instead of macros Andreas Schwab
2012-08-22 14:31 ` Stefan Monnier
2012-08-24 21:37 ` Paul Eggert
2012-08-25 1:38 ` Tom Tromey
2012-08-25 2:58 ` Paul Eggert
2012-08-25 5:35 ` Eli Zaretskii
2012-08-25 20:13 ` Tom Tromey
2012-08-26 4:42 ` Paul Eggert
2012-08-25 2:05 ` Stefan Monnier
2012-08-26 5:31 ` Paul Eggert
2012-08-22 16:03 ` Eli Zaretskii
2012-08-18 19:08 ` Richard Stallman
2012-08-18 20:57 ` Paul Eggert
2012-08-18 21:03 ` Eli Zaretskii
2012-08-18 21:31 ` Paul Eggert
2012-08-19 2:45 ` Eli Zaretskii
2012-08-18 21:14 ` Óscar Fuentes
2012-08-19 17:28 ` Florian Weimer
2012-08-20 20:38 ` Sam Steingold
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=5034A654.2080909@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/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.