Re: Saving to 32 bits of GPRs in signal context

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Anyway, please don't. It is *not* portable.

What are you talking about ? Really, I mean, I'm not sure I understand
what you mean :-)

> 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?

Well, the idea is that we do expose via AT_HWCAP that the ppc64 insn set
is supported. I reckon we might just strip that bit for 32 bits
processes if they can't do 64 bits insn, no need to even get another
one.

> 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).

Yeah well, ffmpeg is crap, news at 11... there are ways to test wether
you have altivec or not (and more than one) but it looks like most
ffmpeg packages around don't care.

> 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.

What are you talking about ? (bis) :-)

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

Ugh ?

Ben.