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.