From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 69DBBDDFB6 for ; Tue, 29 May 2007 18:05:12 +1000 (EST) Subject: Re: Saving to 32 bits of GPRs in signal context From: Benjamin Herrenschmidt To: Dan Malek In-Reply-To: References: <1180423456.19517.124.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 29 May 2007 18:05:00 +1000 Message-Id: <1180425900.19517.136.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linuxppc-dev list , Ulrich Weigand , Paul Mackerras , Steve Munroe , Anton Blanchard List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2007-05-29 at 03:52 -0400, Dan Malek wrote: > > I've been looking at saving & restoring the top 32 bits of 64 bits > > registers when delivering signals to 32 bits processes on a 64 bits > > kernel. The principle is easy, but I wonder where to stick them. > > I'm wondering why you need to do this at all? > Why would a 32-bit application care about or > know what to do with these? There are regular demands for the ability to use the full 64 bits registers in 32 bits applications when running on a 64 bits processor. That ranges from, iirc, the java folks, to people wanting to optimize some libs to use 64 bits registers internally when called from 32 bits apps etc... You can use the full 64 bits easily on powerpc, ld/std just work, it's only the flags calculations and branches, mostly, that are truncated when running in 32 bits mode. Also, the kernel syscall & interrupt entry/exit path will save & restore the full 64 bits. The problem is when you use signals. The compat signal code for 32 bits apps will only save and restore the bottom 32 bits, thus an application using signals will potentially corrupt the top 32 bits, which can be a problem if, for example, it uses a library that has optimisations based on using the full 64 bits. We don't intend to update jmpbuf, getcontext/setcontext etc... for those... they are purely call clobbered etc..., but it would be nice if at least the signal frame save/restore could properly deal with them so they don't get randomly clobbered. Ben.