Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 7 Aug 2020 11:22:33 -0400
From: Rich Felker <>
To: "Gamble, Bradley" <>,
	"" <>
Subject: Re: Support for PowerPC64 devices lacking AltiVec extentions

On Fri, Aug 07, 2020 at 12:46:00PM +0200, Szabolcs Nagy wrote:
> * Gamble, Bradley <> [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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.