From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4879 invoked by alias); 26 Nov 2013 16:21:51 -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 4860 invoked by uid 89); 26 Nov 2013 16:21:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Nov 2013 16:21:49 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VlLOH-0006dg-Jo from joseph_myers@mentor.com ; Tue, 26 Nov 2013 08:21:33 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Nov 2013 08:21:33 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 26 Nov 2013 16:21:31 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VlLOE-0006p7-02; Tue, 26 Nov 2013 16:21:30 +0000 Date: Tue, 26 Nov 2013 16:25:00 -0000 From: "Joseph S. Myers" To: Matheus Almeida CC: "libc-ports@sourceware.org" , Doug Gilmore Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-11/txt/msg00062.txt.bz2 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. 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. Also as suggested in that message to the binutils list, I think *context functions need updating as well as setjmp/longjmp, and there should be an ABI supplement document explaining o32 function call and return for -mfp64. 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. -- Joseph S. Myers joseph@codesourcery.com