Re: [musl] Support for PowerPC64 devices lacking AltiVec extentions

[Rich Felker <dalias@libc.org>]

On Fri, Aug 07, 2020 at 12:46:00PM +0200, Szabolcs Nagy wrote:
> * Gamble, Bradley <bradley.gamble@ncipher.com> [2020-08-07 10:15:38 +0000]:
> > I was initially encountering exceptions with longjmp()/setjmp()
> > due to the use of lvx/stvx instructions to store and restore
> > vector registers. These vector registers are AltiVec-specific and
> > are not required for devices that do not have the AltiVec
> > extentions, so simply removing them was enough to allow musl to
> > function properly on e5500 devices.
> > 
> > I initially considered whether a compile-time check in the
> > configure script was possible, however I believe this has to be a
> > run-time check to query whether the processor supports AltiVec
> > extentions and to conditionally store/restore the registers if it
> > does. I see that Arm targets use __hwcap for platform-specific
> > functionality, and in hwcap.h for PowerPC64 there is a
> > "PPC_FEATURE_HAS_ALTIVEC" definition.
> > 
> > Would this be the correct way to detect this platform-specific behavior?
> 
> __hwcap is the right check (e.g. used in the arm setjmp)
> 
> it works if the missing altivec does not affect the call abi
> of standard c functions (otherwise fixing setjmp/longjmp alone
> will not help: a separate build of libc is needed targetting
> your system's call abi).

I believe we determined that lack of altivec does not affect ABI, at
least not without use of 128-bit long double (which we don't do;
musl's long double on powerpc64 is 64-bit). So based on what I
remember of past discussions, I think it's fine to just add the branch
on __hwcap.

Rich