From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26871 invoked by alias); 12 Apr 2012 10:57:06 -0000 Received: (qmail 26863 invoked by uid 22791); 12 Apr 2012 10:57:05 -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; Thu, 12 Apr 2012 10:56:52 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SIHhp-00050f-RV from Maciej_Rozycki@mentor.com ; Thu, 12 Apr 2012 03:56:49 -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); Thu, 12 Apr 2012 03:56:49 -0700 Received: from [172.30.13.39] (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; Thu, 12 Apr 2012 11:56:47 +0100 Date: Thu, 12 Apr 2012 13:09:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford CC: Subject: Re: [RFA] MIPS/GDB: Fix the handling of MIPS16 thunks In-Reply-To: <8762d6ccmk.fsf@talisman.home> Message-ID: References: <8762d6ccmk.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/msg00298.txt.bz2 On Wed, 11 Apr 2012, Richard Sandiford wrote: > > [Richard, I've cc-ed you as the MIPS port maintainer of GCC and binutils, > > the producers of MIPS16 and some other thunks covered here, in case you > > had anything to add, and just so that you know this issue is being > > addressed now.] > > Sounds like great work, thanks. Hope it goes in. Well, there's only this small issue of gdbarch_in_solib_return_trampoline -- it shouldn't be too hard to overcome. :) > I don't really have anything constructive to say, but just out of > curiosity: we "fixed" call/return stubs to have unwind information for > GCC 4.7. Do you happen to know whether the test passes with that change? I am not completely sure as I haven't tried it/got to 4.7 yet (you may remember I had troubles building the head of the tree; I saw you fixed that at some point, thanks), but it looks to me the generic trampoline stuff I rely on here is tangential to any particular frame unwinders (as long as they get their details right, of course, which may not necessarily be true in all cases, as it is with the heuristic unwinders), so it should keep working. I'll see if I can get to verifying this soon. Did you actually add this unwind information for both the mips16.S pieces and the compiler generated bits (how about the PIC stubs produced by LD?)? Does that happen to address the problem I reported here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01067.html ? Note that it's not a coincidence the function name there is the same as one of those I used in the test case posted here -- this GDB test case will fail without a fix for that GCC problem just like the test case I posted there did. Maciej