From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6478 invoked by alias); 23 Jan 2013 05:40:45 -0000 Received: (qmail 6278 invoked by uid 22791); 23 Jan 2013 05:40:44 -0000 X-SWARE-Spam-Status: No, hits=-4.5 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, 23 Jan 2013 05:40:38 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Txt4e-0001Xx-I7 from Maciej_Rozycki@mentor.com ; Tue, 22 Jan 2013 21:40:36 -0800 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); Tue, 22 Jan 2013 21:40:35 -0800 Received: from [172.30.4.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; Wed, 23 Jan 2013 05:40:33 +0000 Date: Wed, 23 Jan 2013 05:40:00 -0000 From: "Maciej W. Rozycki" To: Mike Frysinger CC: Ralf Baechle , Subject: Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support In-Reply-To: <201301230009.23864.vapier@gentoo.org> Message-ID: References: <201301230009.23864.vapier@gentoo.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00040.txt.bz2 On Wed, 23 Jan 2013, Mike Frysinger wrote: > > We have an issue with the INTERNAL_SYSCALL_NCS wrapper in that it does > > not respect the kernel's syscall restart convention. > > > > That convention requires the instruction immediately preceding SYSCALL to > > initialize $v0 with the syscall number. Then if a restart triggers, $v0 > > will have been clobbered by the syscall interrupted, and needs to be > > reinititalized. The kernel will decrement the PC by 4 before switching > > back to the user mode so that $v0 has been reloaded before SYSCALL is > > executed again. This implies the place $v0 is loaded from must be > > preserved across a syscall, e.g. an immediate, static register, stack > > slot, etc. > > naïvely, but why can't the mips kernel paths take care of the reload itself ? > other arches have scratch space in their pt_regs for doing just this (a bunch > of arches use the orig_ convention). I agree it would be the most reasonable approach if designing from scratch; unfortunately what we have is how the ABI has been set back in 1994. You won't be able to patch up all the kernel binaries out there, sigh... OTOH, the cost of hardcoding the extra instruction to precede SYSCALL is not something I would bend backwards to get rid of, especially given how rarely we make syscalls whose number is not a compilation-time constant. As a matter of curiosity I've run `objdump' across the set of shared libraries we build and found just two such places, in libpthread: sighandler_setxid and __nptl_setxid, out of 243 SYSCALL instances total. I don't suppose the number is going to rise dramatically anytime soon either. Maciej