From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16981 invoked by alias); 4 Dec 2013 02:45:52 -0000 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 Received: (qmail 16969 invoked by uid 89); 4 Dec 2013 02:45:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: multi.imgtec.com Received: from Unknown (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 04 Dec 2013 02:45:49 +0000 Message-ID: <529E9700.2090705@imgtec.com> Date: Wed, 04 Dec 2013 02:45:00 -0000 From: Doug Gilmore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Joseph S.Myers , Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-SEF-Processed: 7_3_0_01192__2013_12_04_02_45_40 X-SW-Source: 2013-12/txt/msg00001.txt.bz2 On 11/26/2013 08:21 AM, Joseph S.Myers wrote: Hi Joseph, Sorry for the delay in responding, there were issues with the *context routines I wanted to understand more fully, thus the delay. > On Tue, 26 Nov 2013, Matheus Almeida wrote: > >> This patch updates the definition of setjmp, longjmp and jmp_buf so that >> on a call to setjmp/longjmp, all the required floating-point >> callee-saved registers are properly saved/restored. >> >> We are aware that updating the size of jmp_buf can potentially break >> existing applications but we expect the number of applications built >> with FR=1 mode to be very small, possibly zero. Nevertheless this should >> be clearly stated in the release notes that existing applications built >> with FR=1 (-mfp64) need to be recompiled in order to use new versions of >> the library. Good point, we will attend to that. > > I don't recall a response to > , and don't see > one in the binutils list archives. I believe that just like the NaN > changes, this needs to be considered as an incompatible ABI variant, with > ELF header checks in the dynamic linker to ensure that all loaded objects > are compatible (whether or not you also define new dynamic linker names > for one or both of o32/-mfp64/legacy-NaN and o32/-mfp64/NaN-2008) - > incompatibilities should be detected by the dynamic linker, not "need to > be recompiled". I suggest looking at Maciej's NaN changes as a model. Yes, this is definitely something we need to attend to. > Also as suggested in that message to the binutils list, I think *context > functions need updating An important motivation for adding -mfp64 support is to efficiently support the new MSA ISA, which requires the register file to operate in -mfp64 mode when MSA instructions are executed. Since the definition of ucontext_t is basically the kernel's struct sigcontext, with possibly with some massaging some of the types used in the definition, our preference is to wait in adding this functionality once MSA context switching support is added to the Linux kernel. If worse comes to worse we may have to live with the *context routines not being supported properly, just as they are on X86_64 in AVX mode. > as well as setjmp/longjmp, and there should be an > ABI supplement document explaining o32 function call and return for > -mfp64. Will do. > > What's the kernel.org kernel version with support for this feature (that > is, the kernel that checks the ELF header flag and ensures the FPU is > correctly set up for the process)? As with NaN-2008, arch_minimum_kernel > should be set to the appropriate kernel version, or 10.0.0 until the > relevant support is in the kernel.org tree. In your follow-up message you wrote: > Sorry, I see your "need to be recompiled" was about old -mfp64 binaries, > which indeed we don't need to care about. Is the kernel version check still a concern given that currently there is no ToT kernel support for -mfp64? We just need to add the checks to ensure the dynamic linker will only map compatible shared objects. Right? Thanks, Doug