[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200807104600.GB879655@port70.net>
Date: Fri, 7 Aug 2020 12:46:00 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: "Gamble, Bradley" <bradley.gamble@...pher.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Support for PowerPC64 devices lacking AltiVec extentions
* 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).
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.
