Re: inlinable functions instead of macros

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]