From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25256 invoked by alias); 9 May 2012 07:32:17 -0000 Received: (qmail 25239 invoked by uid 22791); 9 May 2012 07:32:14 -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 07:32:01 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SS1NP-0003VS-4p from Maciej_Rozycki@mentor.com ; Wed, 09 May 2012 00:31:59 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 00:31:57 -0700 Received: from [172.30.1.173] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 9 May 2012 08:31:55 +0100 Date: Wed, 09 May 2012 07:32:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: Mark Kettenis , Subject: Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method. In-Reply-To: <20120508220805.GD15555@adacore.com> 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> 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/msg00256.txt.bz2 On Tue, 8 May 2012, Joel Brobecker wrote: > Attached is the latest version. > > It's very very slightly different from the version you suggested, > in the fact that I didn't create a local variable for the breakpoint > address, and stored it in *bp_addr directly. I didn't see a real > purpose for having a local variable in this case. I did create > a local variable for the nop instruction address, however. I found > that it did make things a little clearer for that one. That variable was expected to save some memory accesses. Your version should be equally good, I think -- there's no function call between setting *bp_addr and reading it back, it's not volatile, so any sane compiler should keep it in a register and do not really make that read-back while optimising. While not optimising that probably does not matter. And given it's your code, you're of course free to write it your style as long as it's functionally correct and comprehensible for the average GDB developer. > As before, I'm attaching two patches, the first being the last > version of the patch, and the second being the changes introduced > by this iteration. I'm fine with this version. > 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? Maciej