Re: Saving to 32 bits of GPRs in signal context

[Felix Domke <tmbinc@elitedvb.net>]

Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 15:04 +0200, 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.

Or can you guarantee that no CPU ever will implement a.) only a 64bit
subset or b.) other instructions using the same encoding as the 64bit
insn you will use for testing?

I still remember the pain of trying to tell that ffmpeg that my CPU
can't do real altivec, even when it implements some parts of it without
SIGILLing (which ffmpeg used for testing).

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.

Having a decent way (like aux/glibc) would also solve the problem with
"incompatible CPUs", which you mentioned.

And i'd still like to see some decent ILP32LL64 support. Maybe even with
a new "native 64bit" datatype (how ugly), in order to not break the ABI.
I just want to call my hand-optimized 64bit assembler code with 64bit
arguments.
How does OS X handle this? Don't they have the same problem there?

Felix