From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: CVS emacs on Windows still crashes loading bongo.el Date: Wed, 28 May 2008 18:09:56 +0200 Message-ID: <861w3mqujv.fsf@lola.quinscape.zz> References: <86ej7m63kd.fsf@lola.quinscape.zz> <483D80A9.2040508@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1211991106 27705 80.91.229.12 (28 May 2008 16:11:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 May 2008 16:11:46 +0000 (UTC) Cc: Dieter Deyke , Dieter Deyke , emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 28 18:12:26 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K1OGF-0000ki-OT for ged-emacs-devel@m.gmane.org; Wed, 28 May 2008 18:12:24 +0200 Original-Received: from localhost ([127.0.0.1]:51968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1OFU-0002Sk-6X for ged-emacs-devel@m.gmane.org; Wed, 28 May 2008 12:11:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1ODw-0001jG-2P for emacs-devel@gnu.org; Wed, 28 May 2008 12:10:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1ODv-0001iv-4i for emacs-devel@gnu.org; Wed, 28 May 2008 12:09:59 -0400 Original-Received: from [199.232.76.173] (port=50836 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1ODv-0001is-10 for emacs-devel@gnu.org; Wed, 28 May 2008 12:09:59 -0400 Original-Received: from mail.quinscape.de ([212.29.44.217]:36743) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1ODu-0001KI-IP for emacs-devel@gnu.org; Wed, 28 May 2008 12:09:58 -0400 Original-Received: (qmail-ldap/ctrl 17203 invoked from network); 28 May 2008 16:09:56 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by quinx.quinscape.de (qmail-ldap-1.03) with SMTP for ; 28 May 2008 16:09:56 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id AA5F98F03E; Wed, 28 May 2008 18:09:56 +0200 (CEST) In-Reply-To: <483D80A9.2040508@gnu.org> (Jason Rumney's message of "Wed, 28 May 2008 16:56:25 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.8.0.19; VDF: 7.0.4.106; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:97908 Archived-At: Jason Rumney writes: > David Kastrup wrote: >> I have entered a bug report in the libgcc bug tracker asking to have the >> "noreturn" attribute removed from abort's definition > > I don't think this is the full solution, as there are similar problems > debugging any inline function with cross-jumping enabled - the inline > function gets inlined into one function that uses it, and other uses > often jump into the same inlined instance, so the instruction pointer > points inside a function that has nothing to do with the call stack. That's only a problem when the function (inline or not) is at the ultimate end of the function and all the register usage and stack frame cleanup is identical. That's not so very common. Note that for "noreturn" functions (inline or not), the stack frame cleanup is disregarded, and we are by definition at "the ultimate end". So what is a rare occurence in other circumstances becomes pretty much the default. I don't see that inlining functions would make cross-jumping more of a problem. Actually, it would seem to me that inlining would make crossjumping _less_ likely since the call arguments are not placed into a standardized stack frame, but are substituted into the inline function depending on where it is used. So there should be less chance of code recycling rather than more. -- David Kastrup