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

[Siarhei Siamashka]

On Wednesday 12 January 2011 11:26:53 Soeren Sandmann wrote:
> 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?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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110114/63faa14d/attachment.pgp>