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 D6FC8DE0D1 for ; Wed, 30 May 2007 07:44:27 +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 07:44:15 +1000 Message-Id: <1180475055.19517.206.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linuxppc-dev list , Ulrich Weigand , Paul Mackerras , Anton Blanchard List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > But unless you take the time to write it up like a full ABI change you are > never sure that it IS compatible. And any change to the size/shape of > ucontext_t is an ABI change. > > Also if you want to debug this code (see long long variables correctly from > GDB or even see the upper 32-bits of GPRs) you will need an ABI change so > that GDB/DWARF knows what to do. I personally don't care about gdb seeing those or anything like that, those would be strictly local asm optimisations, at least that's my point of view on the matter. I intend not to extend or change the shape of ucontext neither. I'll add the highregs after the ucontext32 on the compat signal frame, the only change/addition is the use of a pad field to point to it and maybe setting a flag that was previously unused and always 0 to indicate that it's there. 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) ? Ben.