From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: inlinable functions instead of macros Date: Wed, 22 Aug 2012 02:28:52 -0700 Organization: UCLA Computer Science Department Message-ID: <5034A654.2080909@cs.ucla.edu> References: <502EDAF3.6030005@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1345627736 15493 80.91.229.3 (22 Aug 2012 09:28:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2012 09:28:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 11:28:56 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T47F8-0005ns-Ns for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2012 11:28:54 +0200 Original-Received: from localhost ([::1]:33372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T47F7-0003PX-1B for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2012 05:28:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T47F4-0003PS-KP for emacs-devel@gnu.org; Wed, 22 Aug 2012 05:28:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T47F2-0000lB-8Q for emacs-devel@gnu.org; Wed, 22 Aug 2012 05:28:50 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:41727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T47F2-0000l6-0K for emacs-devel@gnu.org; Wed, 22 Aug 2012 05:28:48 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9B066A60001; Wed, 22 Aug 2012 02:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZMyycPa-Oup; Wed, 22 Aug 2012 02:28:47 -0700 (PDT) Original-Received: from [192.168.1.3] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1497639E800E; Wed, 22 Aug 2012 02:28:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152739 Archived-At: 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 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.