From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18946 invoked by alias); 13 Apr 2012 20:27:01 -0000 Received: (qmail 18916 invoked by uid 22791); 13 Apr 2012 20:26:58 -0000 X-SWARE-Spam-Status: No, hits=-4.1 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; Fri, 13 Apr 2012 20:26:45 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SIn4t-00008D-MG from Maciej_Rozycki@mentor.com ; Fri, 13 Apr 2012 13:26:43 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 13:26:18 -0700 Received: from [172.30.0.21] (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; Fri, 13 Apr 2012 21:26:41 +0100 Date: Fri, 13 Apr 2012 20:46:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford CC: Subject: Re: [RFA] MIPS/GDB: Fix the handling of MIPS16 thunks In-Reply-To: <87lim0vjr9.fsf@talisman.home> Message-ID: References: <8762d6ccmk.fsf@talisman.home> <87lim0vjr9.fsf@talisman.home> 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-04/txt/msg00386.txt.bz2 On Thu, 12 Apr 2012, Richard Sandiford wrote: > > Did you actually add this unwind information for both the mips16.S pieces > > and the compiler generated bits > > Yes. But like I say, the fix was only (suppoed to be) for what you > called call/return stubs, i.e. those in which the stub JALs to the target, > fiddles with the return value afterwards, then JRs back to the caller. OK, just wanted to be sure. BTW, do you also find the choice of "__call_stub_" and "__call_stub_fp_" for function prefixes unfortunate? You can't really tell them apart in all cases except by interpreting code as you can have a valid user function starting with "fp_" -- this is not a reserved namespace, unlike anything starting with "_". These should really be "__call_stub_" and "__call_fp_stub_" or whatever, one just shouldn't be a substring of the other, sigh... > It wasn't intended to touch pure "run this code first" stubs like... > > > (how about the PIC stubs produced by LD?)? > > ...these. Ack. They're mostly handled by GDB already anyway. > > Does that happen to address the problem I reported here: > > > > http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01067.html > > 'Fraid not. It was a separate problem. Any chance you'll be able to look into it anytime soon? I can cope with the patch I proposed there, but people may prefer an in-tree solution and it doesn't look like I'll have time in the near future to work on anything like what you've outlined instead of my simple solution. Maciej