[Top][All Lists]

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

Re: inlinable functions instead of macros

From: Daniel Colascione
Subject: Re: inlinable functions instead of macros
Date: Sat, 18 Aug 2012 15:15:12 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 8/17/12 4:59 PM, Paul Eggert wrote:
> On 08/17/2012 04:48 PM, Stefan Monnier wrote:
>> While inlinable functions are much cleaner than macros, they have
>> a very serious downside: you just end up with
>> lisp.h:2416: Emacs fatal error: assertion failed: found == !EQ 
>> (blv->defcell, blv->valcell)
>> I.e. the file&line info is always the same rather than giving the
>> file&line where the inlinable function was called.
> On systems that use glibc we could adjust eassert so that it
> also prints a backtrace, using glibc's 'backtrace' function.  See
> <http://www.gnu.org/software/libc/manual/html_node/Backtraces.html>.
> This would not be quite the same thing, as it would print function
> names, insn offsets, and return addresses; but it would recapture
> some of the ground lost here, and the backtrace info would in some
> cases be more useful than what we have now.

On Windows, we solved this problem a long time ago by teaching the
operating system itself how to walk stack frames. When a program
crashes, the OS captures a minidump containing the faulting stack,
instruction pointer, register contents, and (optionally) things like
data segments. If you have one of these minidumps, you don't need
particularly good assertion-failure output: you have everything you
need in the minidump, which you can load into the debugger and examine.

I hear Google's breakpad provides similar facilities for other systems.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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