From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26830 invoked by alias); 9 May 2012 09:14:41 -0000 Received: (qmail 26816 invoked by uid 22791); 9 May 2012 09:14:39 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 09:14:26 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SS2yW-0004Xq-R9 from Maciej_Rozycki@mentor.com ; Wed, 09 May 2012 02:14:24 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 02:14:14 -0700 Received: from [172.30.1.173] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.1.289.1; Wed, 9 May 2012 10:14:22 +0100 Date: Wed, 09 May 2012 09:14:00 -0000 From: "Maciej W. Rozycki" To: Mark Kettenis CC: Joel Brobecker , Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. In-Reply-To: <201205090823.q498Njc7019605@glazunov.sibelius.xs4all.nl> Message-ID: References: <20120503214933.GJ15555@adacore.com> <20120504205818.GT15555@adacore.com> <201205042118.q44LIh3p018153@glazunov.sibelius.xs4all.nl> <201205051144.q45Bitv4006357@glazunov.sibelius.xs4all.nl> <20120508160542.GB15555@adacore.com> <20120508204257.GC15555@adacore.com> <20120508220805.GD15555@adacore.com> <201205090823.q498Njc7019605@glazunov.sibelius.xs4all.nl> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00262.txt.bz2 On Wed, 9 May 2012, Mark Kettenis wrote: > > I have no strong opinion either way -- as we discussed both choices work > > equally well for the common cases and both have their corner-case > > advantages and disadvantages, none of which seem to directly hit any one > > of us. What are the reasons for other targets we support to have chosen > > their particular way? > > Not too long ago, Jan Kratochvil pointed out a problem with > AT_ENTRY_POINT. The entry point address might be covered by DWARF CFI > embedded in the binary. Now if the called function throws an > exception, it will use this CFI to unwind the stack with potential > disastrous consequences. Now I'm not sure how serious that problem > actually is; calling functions that throw exceptions from within GDB > seems like a really bad idea in the first place (did I ever mention > that C++ code is basically undebuggable? ;)). But ON_STACK doesn't > have this limitation. OK, that looks like an advantage that actually matters in practice. So unless someone comes with a counterargument I think that we should go for this change. FWIW I don't find it unreasonable to manually call functions that can throw exceptions -- that's just a centralised error recovery mechanism that's alternative to the standard procedural language's series of IFs checking the error status after each relevant subprocedure call (or other action that could score as a failure) and bailing out if unsuccessful before proceeding with any further actions. It would make sense IMHO though if GDB was capable to catch that exception and report that the function returned with such rather than normally (if it already does not, that is -- I don't deal with C++ or other code using exceptions much, so I don't know). Maciej