Re: Saving to 32 bits of GPRs in signal context

[Felix Domke <tmbinc@elitedvb.net>]

Segher Boessenkool wrote:
>>>> Just call them and trap the SEGV ;-)  You can check the
>>>> aux vector of course, or ask glibc -- but the SEGV way
>>>> is the only really portable way.  Strange world :-)
>>> SIGILL you mean ? :-)
>> Anyway, please don't. It is *not* portable.
> It is simple and *quite* portable.  [...]
>> [ffmpeg]
> To be fair, ffmpeg has had this test since before there
> were proper ways to detect AltiVec on Linux/glibc.
That's *exactly* my point:

If you don't provide a real, portable, useful way *now* for detecting
compatibility with 64bit insn, people (=ffmpeg, mplayer first) *will*
invent their own way of detecting it, possibly using SIGILL, faster than
you could imagine.

Please avoid that this time. And please declare the use of SIGILL for
detecting extensions as plainly wrong, not as a "bad workaround, but
still better than what's available". If you can't be sure that an
extension will work as expected (for example because there is just no
interface to query the OS for it), then simply don't use it. If this is
going to be a performance problem, bug the kernel people to fix it.

(Sorry, this is the point of view of myself a pure *user*. I don't want
to debug crashing programs with incorrect memcpy results because some
program decided on its own that it's safe to use this extension when it
wasn't.)

>> And: What will happen if you manage to run your code under an operating
>> system which doesn't even save the upper bits at all on interrupts? You
>> can't check for that with SIGILL.
> Sure you can, do some loop with a data-dependent branch
> in there that detects corruption of that high half reg.
> If you really want a SIGILL you can just generate one ;-)
> A test like this is never 100% of course.
Tell that those people who have a SIGILL check in their "production" code.

Felix