Re: Saving to 32 bits of GPRs in signal context

[Segher Boessenkool <segher@kernel.crashing.org>]

>>>> - how can an application know that it can use 64 bit registers and
>>>> call
>>>>   the optimized routines?
>>>
>>> I'd say use the 32 bits ABI, AT_HWCAP will tell you if you are 
>>> running
>>> on a 64 bits capable machine. You can then either use hand tuned code
>>> at
>>> runtime, or I think ld.so can load alternate libs based on the bits 
>>> in
>>> there.
>>
>> Or you can simply only install 64-bit binaries on 64-bit
>> machines.
>>
> Yes exactly why make an incompatible ABI change to the powerp32 ABI, 
> when
> you can just use the existing 64-bit ABI.

I meant programs using 64-bit insns while running in the
32-bit personality when I said "64-bit binaries".  No ABI
change is necessary, except very few applications might
want to look at saved registers.

Plain 64-bit programs using 32 bits of address space only
is a much nicer idea indeed.  And it doesn't even need
an ABI change!  Just a new kernel personality (or an ELF
header flag or whatever).

> Especially as you can only run what is proposed on 64-bit hardware!
>
> We don't need another ABI change to powerpc32 (still recovering from 
> the
> -msecure-plt ABI change) and WE DONT NEED a 3rd ABI.
>
> ABI changes ripple everywhere (not just GCC/GLIBC) including all 
> debuggers
> and performance tools. Believe me you really don't want this.

I've had to deal with exactly this on Darwin before, and
although that was as a simple user only, I can confirm:
I really do not want it.  Unless it magically would be
100% stable at once of course :-)


Segher