Date: Fri, 7 Aug 2020 11:22:33 -0400 From: Rich Felker <dalias@...c.org> To: "Gamble, Bradley" <bradley.gamble@...pher.com>, "musl@...ts.openwall.com" <musl@...ts.openwall.com> Subject: Re: Support for PowerPC64 devices lacking AltiVec extentions On Fri, Aug 07, 2020 at 12:46:00PM +0200, Szabolcs Nagy wrote: > * Gamble, Bradley <bradley.gamble@...pher.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
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.