mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Support for PowerPC64 devices lacking AltiVec extentions
@ 2020-08-07 10:15 Gamble, Bradley
  2020-08-07 10:46 ` Szabolcs Nagy
  0 siblings, 1 reply; 3+ messages in thread
From: Gamble, Bradley @ 2020-08-07 10:15 UTC (permalink / raw)
  To: musl


[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

Hello,


musl currently lists "powerpc64" on it's supported target architectures page. I have been trying to use musl on a device that uses Freescale's T1022/T1042 processors based on the e5500 core - These devices lacks the AltiVec extentions that most other PowerPC64 processors support.

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?


Kind regards,

bdg

[-- Attachment #1.2: Type: text/html, Size: 1755 bytes --]

[-- Attachment #2: 0001-Remove-AltiVec-specific-instructions-on-PowerPC64-pl.patch --]
[-- Type: application/octet-stream, Size: 2264 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Support for PowerPC64 devices lacking AltiVec extentions
  2020-08-07 10:15 [musl] Support for PowerPC64 devices lacking AltiVec extentions Gamble, Bradley
@ 2020-08-07 10:46 ` Szabolcs Nagy
  2020-08-07 15:22   ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Szabolcs Nagy @ 2020-08-07 10:46 UTC (permalink / raw)
  To: Gamble, Bradley; +Cc: musl

* 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).


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] Support for PowerPC64 devices lacking AltiVec extentions
  2020-08-07 10:46 ` Szabolcs Nagy
@ 2020-08-07 15:22   ` Rich Felker
  0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2020-08-07 15:22 UTC (permalink / raw)
  To: Gamble, Bradley, musl

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-08-07 15:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-07 10:15 [musl] Support for PowerPC64 devices lacking AltiVec extentions Gamble, Bradley
2020-08-07 10:46 ` Szabolcs Nagy
2020-08-07 15:22   ` Rich Felker

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git