From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5176 invoked by alias); 9 May 2012 08:24:35 -0000 Received: (qmail 5155 invoked by uid 22791); 9 May 2012 08:24:30 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 May 2012 08:24:18 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q498NlOK023940; Wed, 9 May 2012 10:23:47 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q498Njc7019605; Wed, 9 May 2012 10:23:45 +0200 (CEST) Date: Wed, 09 May 2012 08:24:00 -0000 Message-Id: <201205090823.q498Njc7019605@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: macro@codesourcery.com CC: brobecker@adacore.com, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: (macro@codesourcery.com) Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. 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> 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/msg00260.txt.bz2 > Date: Wed, 9 May 2012 08:31:47 +0100 > From: "Maciej W. Rozycki" > > On Tue, 8 May 2012, Joel Brobecker wrote: > > > Testec on mips-irix with no regression. If we'd rather go with > > AT_ENTRY_POINT instead, at least the patch is available here for > > the record. > > 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.