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 C2ED5DDFCB for ; Wed, 30 May 2007 22:10:08 +1000 (EST) Subject: Re: Saving to 32 bits of GPRs in signal context From: Benjamin Herrenschmidt To: Segher Boessenkool In-Reply-To: References: <18012.61822.197988.279764@cargo.ozlabs.ibm.com> <1180526470.19517.274.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 30 May 2007 22:09:51 +1000 Message-Id: <1180526992.19517.277.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linuxppc-dev list , Steve Munroe , Ulrich Weigand , Paul Mackerras , Anton Blanchard List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2007-05-30 at 14:07 +0200, Segher Boessenkool wrote: > > Actually, it's the opposite... the prctl becomes a problem if you > have > > libs wanting to use 64 bits for optims > > The host application, or the dynamic loader, can call > the prctl() when it loads the DSO that needs it. Provided you know it does... and with static binaries it gets harder... > In almost all cases this should all be transparent > for the user IMHO, based on some ELF flag. You reckon ? I was wondering about that ... maybe we should define some ELF personality for that ... But that means that existing programs wouldn't get it even while some libs they depend on might have such optims without the program knowing about it ... Also, if I can avoid changing glibc ... (you know how hard it is !) Ben.