From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29509 invoked by alias); 14 May 2012 16:48:23 -0000 Received: (qmail 29485 invoked by uid 22791); 14 May 2012 16:48:20 -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; Mon, 14 May 2012 16:48:07 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1STyRJ-0003gz-Kh from Maciej_Rozycki@mentor.com ; Mon, 14 May 2012 09:48:05 -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); Mon, 14 May 2012 09:48:05 -0700 Received: from [172.30.0.49] (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; Mon, 14 May 2012 17:48:02 +0100 Date: Mon, 14 May 2012 16:48: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: <20120514150034.GG10253@adacore.com> Message-ID: References: <201205051144.q45Bitv4006357@glazunov.sibelius.xs4all.nl> <20120508160542.GB15555@adacore.com> <20120508204257.GC15555@adacore.com> <20120508220805.GD15555@adacore.com> <201205090823.q498Njc7019605@glazunov.sibelius.xs4all.nl> <20120509143537.GH15555@adacore.com> <20120514150034.GG10253@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/msg00519.txt.bz2 On Mon, 14 May 2012, Joel Brobecker wrote: > > I gave it yet more thinking and came to the conclusion that at least > > for the MIPS target, where it is safe to use either way, but both > > have some drawbacks, we should really apply both, switching > > dynamically. The reason is the stack may be unwritable for whatever > > reason (e.g. not correctly set up), so we should try ON_STACK first > > and if that fails (e.g. SP is NULL or writing to the stack has > > faulted), then fall back to AT_ENTRY_POINT. This is another corner > > case however and I don't feel compelled to implement it right now. > > Let's leave it for another sunny day in Cambridgeshire. ;) > > Is that something we could detect at gdbarch init? (I don't think we > have a process at init time) That has to be done every time a request for a manual call is made -- according to current conditions. The stack may be in oblivion during early startup for example, but get into working state later on. Of course the callee may need to use the stack too, in which case it's not going to work anyway. So it is really leaf functions only that could be called and then not even all of them. Therefore I'll just reiterate the unimportance of this corner case. I guess nobody will really notice, it looks to me the manual call feature is not used by people that often in the first place. I've looked through our bugzilla and the long-lived breakage of MIPS16 manual calls I posted fixes for recently (both the FP ABI fix and the ISA bit fix) has never been reported by anyone. > > 2012-05-14 Maciej W. Rozycki > > > > gdb/ > > * mips-tdep.c (mips_push_dummy_code): Handle microMIPS code. > > FWIW, the change looks good to me. Thanks for checking and confirming. Maciej