From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fv0Le-0000Gg-1c for qemu-devel@nongnu.org; Mon, 26 Jun 2006 19:18:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fv0La-0000GQ-A4 for qemu-devel@nongnu.org; Mon, 26 Jun 2006 19:18:29 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fv0La-0000GN-7P for qemu-devel@nongnu.org; Mon, 26 Jun 2006 19:18:26 -0400 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fv0XY-0003uw-Hb for qemu-devel@nongnu.org; Mon, 26 Jun 2006 19:30:48 -0400 Message-ID: <44A018E4.50708@twilight-hall.net> Date: Mon, 26 Jun 2006 19:27:00 +0200 From: =?ISO-8859-1?Q?Rapha=EBl_Rigo?= MIME-Version: 1.0 Subject: Re: [Qemu-devel] Pending MIPS patches References: <449EB5FA.6070405@gmail.com> <449EBC39.3050701@bellard.org> <44A001C7.8040303@gmail.com> In-Reply-To: <44A001C7.8040303@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dirk Behme , Fabrice Bellard Cc: qemu-devel@nongnu.org Dirk Behme wrote: > Hi Raphaël, > > maybe you find some time and like to answer to Fabrice's remark > regarding patch 8 > below? > > http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00419.html > > Would be nice to get as many of the pending MIPS patches applied as > possible. > > Many thanks > > Dirk > > Fabrice Bellard wrote: >>> Pending MIPS patches (bugs & improvements): >>> =========================================== > >>> 8. [PATCH] Add mips-user signal handling >>> http://lists.gnu.org/archive/html/qemu-devel/2006-06/msg00319.html >> >> >> OK. Need to check the handling of "env->PC += 4" in >> linux-user/main.c. I want to be sure there is not a better solution. >> Adding setup_rt_frame would be good too. Hello, there are 2 possibilities to handle this env->PC += 4: - do a special case wrapper here to avoid increasing PC when it's a sigreturn. - in do_sigreturn set PC with a -4 offset. I chose the first way because I thought it would be cleaner, if anyone was to change this part of the code, then it would be clear that sigreturn directly sets PC. Using the 2nd possibility, one could change this += 4 without knowing do_sigreturn would be affected. I also checked if we could get rid of this weird piece of code, but could not find a clear way to do so. So i preferred maintainability over efficiency, but if you think setting PC with an offset of -4 in signal.c is better, tell me and i will update the patch. Thanks for reviewing, Raphaël