On Wednesday 12 January 2011 11:26:53 Soeren Sandmann wrote: > Andrea Canciani <[email protected]> writes: > > Patch 3/3 looks like an hack... is it possible to avoid parsing auxv > > if its content is not correct/meaningful?un correctly? > > > > Otherwise I'd rather attempt a clean and correct implementation of > > cpu features detection using SIGILL. > > In the end, how to do CPU detection on ARM is Siarhei's call, but IMO, > the auxv parsing hack seems much more likely to be robust than trying > to guard against all possible signal issues.
Actually auxv parsing is not a hack. As bad as it is, this is apparently the intended method of getting cpu features in linux for ARM (I also tried to ask ARM representatives about it some time ago). Auxiliary vector is also available somewhere in the process memory (and probably qemu actually emulates it correctly), but it is a bit difficult to find a pointer to it outside of main function: http://sourceware.org/ml/libc-help/2009-04/msg00045.html So appears that reading '/proc/self/auxv' is something that is generally suggested. Now qemu-user spoils all the fun. Because it does not emulate /proc/self/auxv, this results in getting bogus data, and what is worse, even crashing in some cases. The right solution would be to either improve qemu, or specifically test for this particular case if there was a reliable and documented way to identify whether we are running in qemu. The third patch from my patchset is indeed a hack, which tries to check whether the data from /proc/self/auxv is sane, and tries to make a guess for the cpu features in some other way. Actually this guess is the worst part of the patch, and now I think that we should not assume VFP or NEON support automatically (ARMv6 support still can be checked using uname call). Anyway, everything depends on what is the final goal. Is it just to run pixman code correctly in qemu? In this case just disabling all the CPU specific optimizations is a reasonable and safe choice. Or is it to stress both pixman and qemu for testing purposes in order to discover possible bugs? The problem was reported by Mike McCormack, but it is still not quite clear to me what exactly they want. But I still think that SIGILL is a bad idea. And that's not because of NIH reasons. It just has so many unlikely-in-practice-but-still-possible ways of causing problems that it scares me a bit. In addition to all the drawbacks already mentioned, it also has a theoretical potential of interfering with debugging (yes, I understand that this link is very old and might be totally irrelevant nowadays): http://lists.apple.com/archives/darwin-development/2002/jan/msg00202.html -- Best regards, Siarhei Siamashka
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
