[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120713221842.GK544@brightrain.aerifal.cx>
Date: Fri, 13 Jul 2012 18:18:42 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: mips port working! & remaining issues
On Fri, Jul 13, 2012 at 04:58:39PM -0400, idunham@...abit.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
