From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8556 invoked by alias); 4 Dec 2013 14:56:20 -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 8547 invoked by uid 89); 4 Dec 2013 14:56:19 -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: 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; Wed, 04 Dec 2013 14:56:18 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VoDrv-00044f-7O from joseph_myers@mentor.com ; Wed, 04 Dec 2013 06:56:03 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Dec 2013 06:56:03 -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; Wed, 4 Dec 2013 14:56:01 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VoDrs-0005po-A5; Wed, 04 Dec 2013 14:56:00 +0000 Date: Wed, 04 Dec 2013 14:56:00 -0000 From: "Joseph S. Myers" To: Doug Gilmore CC: Subject: Re: [Patch, mips]: Add support for FR=1/o32. Update implemention of setjmp/longjmp In-Reply-To: <529E9700.2090705@imgtec.com> Message-ID: References: <529E9700.2090705@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-12/txt/msg00002.txt.bz2 On Tue, 3 Dec 2013, Doug Gilmore wrote: > > 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 the functions don't work then it's better for them to be stubs setting errno to ENOSYS and with associated stub_warnings, rather than a broken function that may return a success status. Note that the general rule for all such functions - setjmp / longjmp and *context - is that you only need to deal with call-preserved registers, not call-clobbered ones. A corollary of this is that it's generally a bad idea for new registers in instruction set extensions to be call-preserved because that means running code with old libc and using new instruction set features can quietly break. You can choose register preservation rules in your ABI supplement (as long as you make GCC match, of course), but then any future registers not mentioned in the ABI should be call-clobbered. It is also the case that once a glibc release has been made with a particular size for a type such as ucontext_t, any change to that type requires symbol versioning unless you can demonstrate there are no issues with interoperation of applications built for one type size with libraries built for another. > 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? There should still be the arch_minimum_kernel setting, to 10.0.0 until the support is upstream and then to the actual version where the support goes upstream. -- Joseph S. Myers joseph@codesourcery.com