[Pixman] [PATCH 0/3] ARM: fixes and workarounds for using pixman with QEMU

Soeren Sandmann sandmann at cs.au.dk
Wed Jan 12 01:26:53 PST 2011


Andrea Canciani <ranma42 at gmail.com> 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


More information about the Pixman mailing list