From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32617 invoked by alias); 12 Feb 2014 12:00:45 -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 32601 invoked by uid 89); 12 Feb 2014 12:00:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (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, 12 Feb 2014 12:00:39 +0000 From: Matthew Fortune To: "libc-ports@sourceware.org" CC: "Joseph Myers (joseph@codesourcery.com)" , "Paul Burton" Subject: [MIPS/all] FP and SIMD register handling around ld.so entry points Date: Wed, 12 Feb 2014 12:00:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235349E670@LEMAIL01.le.imgtec.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2014_02_12_12_00_35 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00022.txt.bz2 I'm currently looking into potential problems with ld.so and caller save ar= gument registers that may be live on entry to ld.so. Joseph pointed me towards the following thread which discusses this issue i= n depth: https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html I generally agree that there is currently risk for a number of ports, MIPS = included, that the current approach of ignoring all but integer argument re= gisters is increasingly unsafe with features such as ifunc becoming more wi= dely used. As soon as ld.so allows user code to be called as part of symbol= resolution then the hope that floating point argument registers and/or SIM= D argument registers will not be clobbered becomes increasingly unrealistic= . A similar effect occurs when introducing highly optimised code into ld.so= for such things as memcpy which may then clobber SIMD registers. While thi= ngs like memcpy could be crafted to avoid clobbering any caller save SIMD a= rgument registers this is an unintuitive restriction to require. To solve this we need to change the ld.so entry points to preserve any call= er save register that may be involved in argument passing around ld.so entr= y points. The thread above points out that since there can be ABI extension= s that are dependent on hardware features then the set of registers that ne= ed saving may depend on the current hw capabilities. This is ugly but the c= ost is likely to be minimal in comparison to the real work done inside ld.s= o. I do however have one problem with just changing to save all argument regis= ters. If ld.so preserves floating point argument registers then we will tri= gger the inclusion of floating point register state in a process's context.= The same applies to SIMD register state. It seems unwise to force all proc= esses to have this state context switched when they may well have only hit = it as part of dynamic linking! Lazy context save/restore reduces the cost o= f switching extended register state that is unused (except for ld.so) becau= se the state would only get switched when next entering ld.so. We cannot ju= st check to see if the FP unit/SIMD unit is enabled at the point of enterin= g ld.so as it may be inactive as part of a lazy context mechanism and there= could be live state waiting to be restored by the kernel. Ideally we need a way to avoid preserving extended registers (FP/SIMD) unle= ss the current process has already got it included in its context. Any idea= s for this? Matthew -- Matthew Fortune Leading Software Design Engineer, MIPS processor IP Imagination Technologies Limited t: +44 (0)113 242 9814 www.imgtec.com