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?
> 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. An important advantage to the auxv parsing is that we wouldn't depend on what other signal handling the rest of the process might have set up. It doesn't even matter whether POSIX says it's possible in theory, because if we are relying on a close reading of some standard, then it's pretty likely that we or someone else read it wrong or implemented it wrong. For example, I still don't know exactly what was causing the SIGILL loop mentioned here: http://lists.freedesktop.org/archives/pixman/2010-December/000789.html The auxv parsing may be a hack, but it's also something that would only be used in the qemu case, so few people would be affected even if there were a bug in it. > I'm going through the documentation you linked in > http://lists.freedesktop.org/archives/pixman/2010-December/000786.html > and I think that the portability issue can be fixed. > > Would SIGILL be considered a viable alternative if it was done in a > thread-safe way? How much portability do we want to provide? > In particular, should we only assume C90 or can we assume that > sigsetjmp/siglongjmp are available (they are part of POSIX.1-1988). The answer to that question depends on how many platforms are lacking the support, how many users and developers those platforms have, and how much work it is to support an alternative, so it's difficult to give a general answer. Soren _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
