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 E79A8DDFF9 for ; Wed, 30 May 2007 09:20:15 +1000 (EST) Subject: Re: Saving to 32 bits of GPRs in signal context From: Benjamin Herrenschmidt To: Steve Munroe In-Reply-To: References: Content-Type: text/plain Date: Wed, 30 May 2007 09:19:59 +1000 Message-Id: <1180480799.19517.214.camel@localhost.localdomain> Mime-Version: 1.0 Cc: Ulrich Weigand , linuxppc-dev list , Paul Mackerras , 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 18:16 -0500, Steve Munroe wrote: > > The pad field may be occupied with data if the code was compiled on a > older > distro and ucontext_t is misaligned (an odd Doubleword). So the pad > field > is free for reuse onless you version the code to handle unalligned VMX > registers. Actually... there are two pad areas ... also, I would only use that on contexts that I generated myself (signal contexts) so I suppose that should be allright. > > Do you see any possible compatibility problem there ? Do you know of > any > > piece of software that makes hard assumptions on the shape and size > of a > > complete signal frame (not just the ucontext part of it) ? > > > > The signal frame can change, as long as the relative offset and size > of the > ucontext_t is unchanged. Ok. Ben.