From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1293 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: mips port working! & remaining issues Date: Fri, 13 Jul 2012 18:18:42 -0400 Message-ID: <20120713221842.GK544@brightrain.aerifal.cx> References: <20120713052313.GA20369@brightrain.aerifal.cx> <20120713081525.GA14463@port70.net> <20120713130830.GH544@brightrain.aerifal.cx> <50002443.6050003@gentoo.org> <20120713142521.GI544@brightrain.aerifal.cx> <11846.50.0.229.11.1342213119.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1342217984 10459 80.91.229.3 (13 Jul 2012 22:19:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2012 22:19:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1294-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 14 00:19:44 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SpoD9-0002YR-4F for gllmg-musl@plane.gmane.org; Sat, 14 Jul 2012 00:19:43 +0200 Original-Received: (qmail 1379 invoked by uid 550); 13 Jul 2012 22:19:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1371 invoked from network); 13 Jul 2012 22:19:42 -0000 Content-Disposition: inline In-Reply-To: <11846.50.0.229.11.1342213119.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1293 Archived-At: On Fri, Jul 13, 2012 at 04:58:39PM -0400, idunham@lavabit.com wrote: > Seems to me that the hardfloat flag (while slightly more bloated, > because you have code for both options) has room for adding runtime > checks: eventually, it might be possible to have that as a static > variable (I'm thinking char or something; at least 2 bits would be > needed for this method...), and if it is uninitialized (0x00?), try > saving the registers or something that will raise a SIGILL on pure > softfloat systems; the handler would set it to indicate softfloat > (0xFF?), while otherwise it sets it to indicate hardfloat (any > intermediate value?). > That particular approach might not work (can you install handlers in > *jmp safely?), but a runtime check would require using the hardfloat > flag. Test-and-trap is not a valid approach for runtime detection in userspace, at least not at the library level. In principle it could be if the libc did heavy control of signal handling, installed its own SIGILL handler, and faked sigaction to redirect the application's signal handler (if any) through the libc one rather than setting it directly in kernelspace. But this is a lot more invasive than most people would like, I think. Proper runtime detection is performed via cpu self-identification (e.g. the cpuid instruction on x86) or via the AT_HWCAP auxv entry passed to the program by the kernel at startup. Rich