musl libc for PPC64

musl libc for PPC64

[David Edelsohn]

What work is necessary to enable basic musl libc support for PPC64
Linux Little Endian?

Thanks, David

Re: musl libc for PPC64

[Szabolcs Nagy]

* David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
> What work is necessary to enable basic musl libc support for PPC64
> Linux Little Endian?

once the abi is clear (is long double ieee128?) the arch specific
parts of musl need to be ported for ARCH=powerpc64.

arch specific parts of musl are

arch/$ARCH
crt/$ARCH
src/*/$ARCH

porting check list:
http://www.openwall.com/lists/musl/2012/07/08/1

things that changed since:

- crt needs a small bit of inline asm in arch/$ARCH/crt_arch.h
  (which is used in crt/crt1.c and ldso/dlstart.c to align the
   stack, set up the argument and jump to the c entry point)

- arch/$ARCH/bits/foo.h is only needed if arch/generic/bits/foo.h
  is not good for the target. (getting the bits headers right
  is still a bit fiddly work: they have to match linux uapi.)

- fewer primitives are enough in arch/$ARCH/atomic_arch.h for
  an initial port (src/internal/atomic.h can implement most
  primitives in terms of a_cas or a_ll/a_sc).

- arch/$ARCH/pthread_arch.h has MC_PC instead of CANCEL_REG_IP
  (should be an mcontext member that can access the pc).

thinks that didnt change but not on that list:

- src/fenv/$ARCH/fenv.s is needed for fenv support

- configure script needs to be updated
  (compiler abi checks go here)

testing can be done against
http://repo.or.cz/libc-test.git

there are not many docs about the internals but the git log
is often informative.

Re: Re: musl libc for PPC64

[Rich Felker]

On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
> > What work is necessary to enable basic musl libc support for PPC64
> > Linux Little Endian?
> 
> once the abi is clear (is long double ieee128?) the arch specific
> parts of musl need to be ported for ARCH=powerpc64.

IIRC one of the powerpc64 ABIs uses function descriptors rather than
normal function pointers. If so that may affect a few details in the
dynamic linker and may require some changes to non-arch-specific code,
but since we have SH/FDPIC all the basic framework for function
descriptors should be there already.

Also to clarify what you asked about long double ABI, if ieee128
(quad) is not used, the compiler needs to be built to use plain double
(ieee64 double) for long double instead of using ibm double-double.
musl does not support ibm double-double or other wacky ld formats that
don't obey ieee arithmetic semantics.

> arch specific parts of musl are
> 
> arch/$ARCH
> crt/$ARCH
> src/*/$ARCH
> 
> porting check list:
> http://www.openwall.com/lists/musl/2012/07/08/1
> 
> things that changed since:
> 
> - crt needs a small bit of inline asm in arch/$ARCH/crt_arch.h
>   (which is used in crt/crt1.c and ldso/dlstart.c to align the
>    stack, set up the argument and jump to the c entry point)

It also needs to provide the address of _DYNAMIC without having a GOT
pointer to start with.

> - arch/$ARCH/bits/foo.h is only needed if arch/generic/bits/foo.h
>   is not good for the target. (getting the bits headers right
>   is still a bit fiddly work: they have to match linux uapi.)
> 
> - fewer primitives are enough in arch/$ARCH/atomic_arch.h for
>   an initial port (src/internal/atomic.h can implement most
>   primitives in terms of a_cas or a_ll/a_sc).

Yes -- anyone doing a new port should look at git master rather than
1.1.12 to see how src/$(ARCH)/atomic_arch.h is supposed to work. And
64-bit archs need a little bit more than 32-bit ones in order to
provide atomic ops on pointers.

> - arch/$ARCH/pthread_arch.h has MC_PC instead of CANCEL_REG_IP
>   (should be an mcontext member that can access the pc).
> 
> thinks that didnt change but not on that list:
> 
> - src/fenv/$ARCH/fenv.s is needed for fenv support
> 
> - configure script needs to be updated
>   (compiler abi checks go here)
> 
> testing can be done against
> http://repo.or.cz/libc-test.git
> 
> there are not many docs about the internals but the git log
> is often informative.

Sounds good.

Rich

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
>> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
>> > What work is necessary to enable basic musl libc support for PPC64
>> > Linux Little Endian?
>>
>> once the abi is clear (is long double ieee128?) the arch specific
>> parts of musl need to be ported for ARCH=powerpc64.
>
> IIRC one of the powerpc64 ABIs uses function descriptors rather than
> normal function pointers. If so that may affect a few details in the
> dynamic linker and may require some changes to non-arch-specific code,
> but since we have SH/FDPIC all the basic framework for function
> descriptors should be there already.

PPC64LE Linux is little endian and does not use function descriptors.

> Also to clarify what you asked about long double ABI, if ieee128
> (quad) is not used, the compiler needs to be built to use plain double
> (ieee64 double) for long double instead of using ibm double-double.

GCC can use IEEE64 or IEEE128 for long double.

Is there any internal interest from the musl libc community for PPC64
support that IBM could sponsor with a financial bounty on
bountysource.com?

Thanks, David

Re: Re: musl libc for PPC64

[Rich Felker]

On Mon, Feb 08, 2016 at 12:48:48PM -0500, David Edelsohn wrote:
> On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker <dalias@libc.org> wrote:
> > On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
> >> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
> >> > What work is necessary to enable basic musl libc support for PPC64
> >> > Linux Little Endian?
> >>
> >> once the abi is clear (is long double ieee128?) the arch specific
> >> parts of musl need to be ported for ARCH=powerpc64.
> >
> > IIRC one of the powerpc64 ABIs uses function descriptors rather than
> > normal function pointers. If so that may affect a few details in the
> > dynamic linker and may require some changes to non-arch-specific code,
> > but since we have SH/FDPIC all the basic framework for function
> > descriptors should be there already.
> 
> PPC64LE Linux is little endian and does not use function descriptors.

OK. I've been looking more and this is what's called the "ELFv2 ABI"
for ppc64, I believe. Is it possible to use ELFv2 ABI with big endian
targets? It looks like support is there on the toolchain side but I'm
not sure if we would run into problems. The reason I'm asking is that
there's probably also interest in older BE ppc64 systems and I think
it makes more sense to use the same musl port/ABI for both
endiannesses if at all possible rather than doing two separate ones.

> > Also to clarify what you asked about long double ABI, if ieee128
> > (quad) is not used, the compiler needs to be built to use plain double
> > (ieee64 double) for long double instead of using ibm double-double.
> 
> GCC can use IEEE64 or IEEE128 for long double.

OK. Then the choice of which to use depends mainly on whether there's
current or future hardware that would do IEEE128 natively. If so we
should probably choose an ABI that supports it even if in the
short-term (or for the baseline ISA) it requires soft-float code to be
linked; that's how AArch64 is doing it. But if native IEEE128 support
is not available and not planned for future hardware, doing it as
soft-float "just because" is probably not as good idea.

> Is there any internal interest from the musl libc community for PPC64
> support that IBM could sponsor with a financial bounty on
> bountysource.com?

I would suspect so.

Rich

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 3:18 PM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Feb 08, 2016 at 12:48:48PM -0500, David Edelsohn wrote:
>> On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker <dalias@libc.org> wrote:
>> > On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
>> >> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
>> >> > What work is necessary to enable basic musl libc support for PPC64
>> >> > Linux Little Endian?
>> >>
>> >> once the abi is clear (is long double ieee128?) the arch specific
>> >> parts of musl need to be ported for ARCH=powerpc64.
>> >
>> > IIRC one of the powerpc64 ABIs uses function descriptors rather than
>> > normal function pointers. If so that may affect a few details in the
>> > dynamic linker and may require some changes to non-arch-specific code,
>> > but since we have SH/FDPIC all the basic framework for function
>> > descriptors should be there already.
>>
>> PPC64LE Linux is little endian and does not use function descriptors.
>
> OK. I've been looking more and this is what's called the "ELFv2 ABI"
> for ppc64, I believe. Is it possible to use ELFv2 ABI with big endian
> targets? It looks like support is there on the toolchain side but I'm
> not sure if we would run into problems. The reason I'm asking is that
> there's probably also interest in older BE ppc64 systems and I think
> it makes more sense to use the same musl port/ABI for both
> endiannesses if at all possible rather than doing two separate ones.

The future direction for Linux on PPC64 is little endian.  I was
trying to simplify things because of your comments about multiple
ABIs.

The original PPC64 ABI could (and has) operated in little endian mode,
and the new PPC64 ELFv2 ABI could operate in big endian mode.  But the
entire PowerPC software ecosystem and all Linux distros are
distributed with PPC64 big endian ABI using function descriptors and
little endian ABI using ELFv2.

>> > Also to clarify what you asked about long double ABI, if ieee128
>> > (quad) is not used, the compiler needs to be built to use plain double
>> > (ieee64 double) for long double instead of using ibm double-double.
>>
>> GCC can use IEEE64 or IEEE128 for long double.
>
> OK. Then the choice of which to use depends mainly on whether there's
> current or future hardware that would do IEEE128 natively. If so we
> should probably choose an ABI that supports it even if in the
> short-term (or for the baseline ISA) it requires soft-float code to be
> linked; that's how AArch64 is doing it. But if native IEEE128 support
> is not available and not planned for future hardware, doing it as
> soft-float "just because" is probably not as good idea.

IBM has announced that the next generation of the processor will
support native IEEE128 floating point in hardware.  There will be
software emulation for the current processors.  Support is included in
the forthcoming GCC 6.

>> Is there any internal interest from the musl libc community for PPC64
>> support that IBM could sponsor with a financial bounty on
>> bountysource.com?
>
> I would suspect so.

If anyone is interested, please contact me privately.

Thanks, David

Re: Re: musl libc for PPC64

[Rich Felker]

On Mon, Feb 08, 2016 at 03:30:51PM -0500, David Edelsohn wrote:
> On Mon, Feb 8, 2016 at 3:18 PM, Rich Felker <dalias@libc.org> wrote:
> > On Mon, Feb 08, 2016 at 12:48:48PM -0500, David Edelsohn wrote:
> >> On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker <dalias@libc.org> wrote:
> >> > On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
> >> >> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
> >> >> > What work is necessary to enable basic musl libc support for PPC64
> >> >> > Linux Little Endian?
> >> >>
> >> >> once the abi is clear (is long double ieee128?) the arch specific
> >> >> parts of musl need to be ported for ARCH=powerpc64.
> >> >
> >> > IIRC one of the powerpc64 ABIs uses function descriptors rather than
> >> > normal function pointers. If so that may affect a few details in the
> >> > dynamic linker and may require some changes to non-arch-specific code,
> >> > but since we have SH/FDPIC all the basic framework for function
> >> > descriptors should be there already.
> >>
> >> PPC64LE Linux is little endian and does not use function descriptors.
> >
> > OK. I've been looking more and this is what's called the "ELFv2 ABI"
> > for ppc64, I believe. Is it possible to use ELFv2 ABI with big endian
> > targets? It looks like support is there on the toolchain side but I'm
> > not sure if we would run into problems. The reason I'm asking is that
> > there's probably also interest in older BE ppc64 systems and I think
> > it makes more sense to use the same musl port/ABI for both
> > endiannesses if at all possible rather than doing two separate ones.
> 
> The future direction for Linux on PPC64 is little endian.  I was
> trying to simplify things because of your comments about multiple
> ABIs.
> 
> The original PPC64 ABI could (and has) operated in little endian mode,
> and the new PPC64 ELFv2 ABI could operate in big endian mode.  But the
> entire PowerPC software ecosystem and all Linux distros are
> distributed with PPC64 big endian ABI using function descriptors and
> little endian ABI using ELFv2.

Yes. For glibc and other systems with existing ecosystems, the old
ecosystem was based on the v1 ABI and was BE, and the new ecosystem is
based on the v2 ABI and is LE. But since musl doesn't have an existing
ppc64 ecosystem (and it's not ABI-compatible with glibc on ppc anyway
because of double-double and other issues) I think it makes sense to
use the v2 ABI for both LE and BE (if anyone even cares to do BE at
all). Does that make sense to you?

Of course either way, to begin with we can just start with the modern
LE ABI.

BTW one thing I'm not clear on -- is there separate LE/BE hardware, or
does the same hardware just have a switchable mode? In the latter case
BE seems rather uninteresting to support at all, but maybe people want
to use it for routers or something?

> >> > Also to clarify what you asked about long double ABI, if ieee128
> >> > (quad) is not used, the compiler needs to be built to use plain double
> >> > (ieee64 double) for long double instead of using ibm double-double.
> >>
> >> GCC can use IEEE64 or IEEE128 for long double.
> >
> > OK. Then the choice of which to use depends mainly on whether there's
> > current or future hardware that would do IEEE128 natively. If so we
> > should probably choose an ABI that supports it even if in the
> > short-term (or for the baseline ISA) it requires soft-float code to be
> > linked; that's how AArch64 is doing it. But if native IEEE128 support
> > is not available and not planned for future hardware, doing it as
> > soft-float "just because" is probably not as good idea.
> 
> IBM has announced that the next generation of the processor will
> support native IEEE128 floating point in hardware.  There will be
> software emulation for the current processors.  Support is included in
> the forthcoming GCC 6.

OK. Does the existing software emulation properly update the hardware
floating point status (exception flags) and use the rounding mode?

Rich

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 5:59 PM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Feb 08, 2016 at 03:30:51PM -0500, David Edelsohn wrote:
>> On Mon, Feb 8, 2016 at 3:18 PM, Rich Felker <dalias@libc.org> wrote:
>> > On Mon, Feb 08, 2016 at 12:48:48PM -0500, David Edelsohn wrote:
>> >> On Mon, Feb 8, 2016 at 11:51 AM, Rich Felker <dalias@libc.org> wrote:
>> >> > On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
>> >> >> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 09:43:08 -0500]:
>> >> >> > What work is necessary to enable basic musl libc support for PPC64
>> >> >> > Linux Little Endian?
>> >> >>
>> >> >> once the abi is clear (is long double ieee128?) the arch specific
>> >> >> parts of musl need to be ported for ARCH=powerpc64.
>> >> >
>> >> > IIRC one of the powerpc64 ABIs uses function descriptors rather than
>> >> > normal function pointers. If so that may affect a few details in the
>> >> > dynamic linker and may require some changes to non-arch-specific code,
>> >> > but since we have SH/FDPIC all the basic framework for function
>> >> > descriptors should be there already.
>> >>
>> >> PPC64LE Linux is little endian and does not use function descriptors.
>> >
>> > OK. I've been looking more and this is what's called the "ELFv2 ABI"
>> > for ppc64, I believe. Is it possible to use ELFv2 ABI with big endian
>> > targets? It looks like support is there on the toolchain side but I'm
>> > not sure if we would run into problems. The reason I'm asking is that
>> > there's probably also interest in older BE ppc64 systems and I think
>> > it makes more sense to use the same musl port/ABI for both
>> > endiannesses if at all possible rather than doing two separate ones.
>>
>> The future direction for Linux on PPC64 is little endian.  I was
>> trying to simplify things because of your comments about multiple
>> ABIs.
>>
>> The original PPC64 ABI could (and has) operated in little endian mode,
>> and the new PPC64 ELFv2 ABI could operate in big endian mode.  But the
>> entire PowerPC software ecosystem and all Linux distros are
>> distributed with PPC64 big endian ABI using function descriptors and
>> little endian ABI using ELFv2.
>
> Yes. For glibc and other systems with existing ecosystems, the old
> ecosystem was based on the v1 ABI and was BE, and the new ecosystem is
> based on the v2 ABI and is LE. But since musl doesn't have an existing
> ppc64 ecosystem (and it's not ABI-compatible with glibc on ppc anyway
> because of double-double and other issues) I think it makes sense to
> use the v2 ABI for both LE and BE (if anyone even cares to do BE at
> all). Does that make sense to you?

You *can* use v2 ABI for BE, but there is no software to run.  There
is no software or ecosystem or operating system that runs v2 ABI BE.
It's not a hardware limitation, but there is no environment for the
alternate combination.

> Of course either way, to begin with we can just start with the modern
> LE ABI.
>
> BTW one thing I'm not clear on -- is there separate LE/BE hardware, or
> does the same hardware just have a switchable mode? In the latter case
> BE seems rather uninteresting to support at all, but maybe people want
> to use it for routers or something?

PowerPC processors support both little endian and big endian.  The
same systems can operate in either endian mode.

>
>> >> > Also to clarify what you asked about long double ABI, if ieee128
>> >> > (quad) is not used, the compiler needs to be built to use plain double
>> >> > (ieee64 double) for long double instead of using ibm double-double.
>> >>
>> >> GCC can use IEEE64 or IEEE128 for long double.
>> >
>> > OK. Then the choice of which to use depends mainly on whether there's
>> > current or future hardware that would do IEEE128 natively. If so we
>> > should probably choose an ABI that supports it even if in the
>> > short-term (or for the baseline ISA) it requires soft-float code to be
>> > linked; that's how AArch64 is doing it. But if native IEEE128 support
>> > is not available and not planned for future hardware, doing it as
>> > soft-float "just because" is probably not as good idea.
>>
>> IBM has announced that the next generation of the processor will
>> support native IEEE128 floating point in hardware.  There will be
>> software emulation for the current processors.  Support is included in
>> the forthcoming GCC 6.
>
> OK. Does the existing software emulation properly update the hardware
> floating point status (exception flags) and use the rounding mode?

I'm not sure what you mean.  The software emulation assumes the
hardware support is not present.  It doesn't mirror back the state to
the processor in 64 bit mode.  But the emulation is fully IEEE128
compliant.

>
> Rich

Re: Re: musl libc for PPC64

[Rich Felker]

On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> You *can* use v2 ABI for BE, but there is no software to run.  There
> is no software or ecosystem or operating system that runs v2 ABI BE.
> It's not a hardware limitation, but there is no environment for the
> alternate combination.

Indeed. At this point there's no musl ecosystem for ppc64 at all
though; whatever we add is a fresh start.

> >> IBM has announced that the next generation of the processor will
> >> support native IEEE128 floating point in hardware.  There will be
> >> software emulation for the current processors.  Support is included in
> >> the forthcoming GCC 6.
> >
> > OK. Does the existing software emulation properly update the hardware
> > floating point status (exception flags) and use the rounding mode?
> 
> I'm not sure what you mean.  The software emulation assumes the
> hardware support is not present.  It doesn't mirror back the state to
> the processor in 64 bit mode.  But the emulation is fully IEEE128
> compliant.

if fesetround(FE_DOWNWARD) succeeds but then long double math still
rounds to nearest, that's not IEEE compliant.

The big obstacle to having fenv with softfloat on fully-softfloat
archs is the lack of register state for the rounding mode and
exception flags, so it should be possible to do this right as long as
the cpu has status/mode registers for single/double, which the
soft-quad code can then access/set. If this isn't done right already
we could either try to get it fixed in libgcc or punt and go with
ld64.

Rich

Re: Re: musl libc for PPC64

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
> On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> > I'm not sure what you mean.  The software emulation assumes the
> > hardware support is not present.  It doesn't mirror back the state to
> > the processor in 64 bit mode.  But the emulation is fully IEEE128
> > compliant.
> 
> if fesetround(FE_DOWNWARD) succeeds but then long double math still
> rounds to nearest, that's not IEEE compliant.
> 
> The big obstacle to having fenv with softfloat on fully-softfloat
> archs is the lack of register state for the rounding mode and
> exception flags, so it should be possible to do this right as long as
> the cpu has status/mode registers for single/double, which the
> soft-quad code can then access/set. If this isn't done right already
> we could either try to get it fixed in libgcc or punt and go with
> ld64.
> 

it seems to be supported
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107

so we can implement iso c annex f with 128 bit long doubles.

Re: Re: musl libc for PPC64

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> > > I'm not sure what you mean.  The software emulation assumes the
> > > hardware support is not present.  It doesn't mirror back the state to
> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
> > > compliant.
> > 
> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
> > rounds to nearest, that's not IEEE compliant.
> > 
> > The big obstacle to having fenv with softfloat on fully-softfloat
> > archs is the lack of register state for the rounding mode and
> > exception flags, so it should be possible to do this right as long as
> > the cpu has status/mode registers for single/double, which the
> > soft-quad code can then access/set. If this isn't done right already
> > we could either try to get it fixed in libgcc or punt and go with
> > ld64.
> > 
> 
> it seems to be supported
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
> 
> so we can implement iso c annex f with 128 bit long doubles.

hm it seems, this is only for the __float128 type
which will be new in gcc-6.

i don't see how to configure gcc with ieee128 long double.
(other than using the debug option -mabi=ieeelongdouble)

so if musl goes with ieee128 long double abi then it will
only work with latest gcc.

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
>> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
>> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
>> > > I'm not sure what you mean.  The software emulation assumes the
>> > > hardware support is not present.  It doesn't mirror back the state to
>> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
>> > > compliant.
>> >
>> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
>> > rounds to nearest, that's not IEEE compliant.
>> >
>> > The big obstacle to having fenv with softfloat on fully-softfloat
>> > archs is the lack of register state for the rounding mode and
>> > exception flags, so it should be possible to do this right as long as
>> > the cpu has status/mode registers for single/double, which the
>> > soft-quad code can then access/set. If this isn't done right already
>> > we could either try to get it fixed in libgcc or punt and go with
>> > ld64.
>> >
>>
>> it seems to be supported
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
>>
>> so we can implement iso c annex f with 128 bit long doubles.
>
> hm it seems, this is only for the __float128 type
> which will be new in gcc-6.
>
> i don't see how to configure gcc with ieee128 long double.
> (other than using the debug option -mabi=ieeelongdouble)
>
> so if musl goes with ieee128 long double abi then it will
> only work with latest gcc.

The musl libc dynamic linking support only was added to the latest GCC.

- David

Re: Re: musl libc for PPC64

[Szabolcs Nagy]

* David Edelsohn <dje.gcc@gmail.com> [2016-02-08 20:16:25 -0500]:
> On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> > * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
> >> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
> >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> >> > > I'm not sure what you mean.  The software emulation assumes the
> >> > > hardware support is not present.  It doesn't mirror back the state to
> >> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
> >> > > compliant.
> >> >
> >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
> >> > rounds to nearest, that's not IEEE compliant.
> >> >
> >> > The big obstacle to having fenv with softfloat on fully-softfloat
> >> > archs is the lack of register state for the rounding mode and
> >> > exception flags, so it should be possible to do this right as long as
> >> > the cpu has status/mode registers for single/double, which the
> >> > soft-quad code can then access/set. If this isn't done right already
> >> > we could either try to get it fixed in libgcc or punt and go with
> >> > ld64.
> >> >
> >>
> >> it seems to be supported
> >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
> >>
> >> so we can implement iso c annex f with 128 bit long doubles.
> >
> > hm it seems, this is only for the __float128 type
> > which will be new in gcc-6.
> >
> > i don't see how to configure gcc with ieee128 long double.
> > (other than using the debug option -mabi=ieeelongdouble)
> >
> > so if musl goes with ieee128 long double abi then it will
> > only work with latest gcc.
> 
> The musl libc dynamic linking support only was added to the latest GCC.
> 

musl has a gcc wrapper that changes the specs file and then
it works even with gcc-3 (on x86 and glibc host without c++).

we also have patches for gcc releases going back to gcc-4.7

so powerpc64 would be the only arch that depends on features
from the latest gcc and that is new situation for musl.
(this is mostly interesting because there are historical
powerpc64 machines with older toolchains wich might work
with musl with minor tweaks if we choose 64bit long double)

but if new hw adds ieee128 instructions then i guess that's
the right choice.

Re: Re: musl libc for PPC64

[Szabolcs Nagy]

* David Edelsohn <dje.gcc@gmail.com> [2016-02-08 20:16:25 -0500]:
> On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> > * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
> >> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
> >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> >> > > I'm not sure what you mean.  The software emulation assumes the
> >> > > hardware support is not present.  It doesn't mirror back the state to
> >> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
> >> > > compliant.
> >> >
> >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
> >> > rounds to nearest, that's not IEEE compliant.
> >> >
> >> > The big obstacle to having fenv with softfloat on fully-softfloat
> >> > archs is the lack of register state for the rounding mode and
> >> > exception flags, so it should be possible to do this right as long as
> >> > the cpu has status/mode registers for single/double, which the
> >> > soft-quad code can then access/set. If this isn't done right already
> >> > we could either try to get it fixed in libgcc or punt and go with
> >> > ld64.
> >> >
> >>
> >> it seems to be supported
> >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
> >>
> >> so we can implement iso c annex f with 128 bit long doubles.
> >
> > hm it seems, this is only for the __float128 type
> > which will be new in gcc-6.
> >
> > i don't see how to configure gcc with ieee128 long double.
> > (other than using the debug option -mabi=ieeelongdouble)
> >
> > so if musl goes with ieee128 long double abi then it will
> > only work with latest gcc.
> 
> The musl libc dynamic linking support only was added to the latest GCC.
> 

(resend with correct to:)

musl has a gcc wrapper that changes the specs file and then
it works even with gcc-3 (on x86 and glibc host without c++).

we also have patches for gcc releases going back to gcc-4.7

so powerpc64 would be the only arch that depends on features
from the latest gcc and that is new situation for musl.
(this is mostly interesting because there are historical
powerpc64 machines with older toolchains wich might work
with musl with minor tweaks if we choose 64bit long double)

but if new hw adds ieee128 instructions then i guess that's
the right choice.

Re: Re: musl libc for PPC64

[Rich Felker]

On Tue, Feb 09, 2016 at 02:45:50AM +0100, Szabolcs Nagy wrote:
> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 20:16:25 -0500]:
> > On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> > > * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
> > >> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
> > >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> > >> > > I'm not sure what you mean.  The software emulation assumes the
> > >> > > hardware support is not present.  It doesn't mirror back the state to
> > >> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
> > >> > > compliant.
> > >> >
> > >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
> > >> > rounds to nearest, that's not IEEE compliant.
> > >> >
> > >> > The big obstacle to having fenv with softfloat on fully-softfloat
> > >> > archs is the lack of register state for the rounding mode and
> > >> > exception flags, so it should be possible to do this right as long as
> > >> > the cpu has status/mode registers for single/double, which the
> > >> > soft-quad code can then access/set. If this isn't done right already
> > >> > we could either try to get it fixed in libgcc or punt and go with
> > >> > ld64.
> > >> >
> > >>
> > >> it seems to be supported
> > >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
> > >>
> > >> so we can implement iso c annex f with 128 bit long doubles.
> > >
> > > hm it seems, this is only for the __float128 type
> > > which will be new in gcc-6.
> > >
> > > i don't see how to configure gcc with ieee128 long double.
> > > (other than using the debug option -mabi=ieeelongdouble)
> > >
> > > so if musl goes with ieee128 long double abi then it will
> > > only work with latest gcc.
> > 
> > The musl libc dynamic linking support only was added to the latest GCC.
> > 
> 
> (resend with correct to:)
> 
> musl has a gcc wrapper that changes the specs file and then
> it works even with gcc-3 (on x86 and glibc host without c++).
> 
> we also have patches for gcc releases going back to gcc-4.7

Indeed. Just patching in the dynamic linker name and a few other
details to make gcc target musl properly is small and can be done for
any gcc version. Patching in ieee quad or ABI changes is non-trivial
though.

> so powerpc64 would be the only arch that depends on features
> from the latest gcc and that is new situation for musl.
> (this is mostly interesting because there are historical
> powerpc64 machines with older toolchains wich might work
> with musl with minor tweaks if we choose 64bit long double)
> 
> but if new hw adds ieee128 instructions then i guess that's
> the right choice.

Obviously the powerpc64 musl target is not going to work with any
compiler too old to have the "ELFv2 ABI" so that limits how far back
it's interesting to be compatible with old compilers. What gcc version
added the v2 ABI? Does clang/llvm support it yet? (Compat with clang
is also valuable.)

Rich

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 8:52 PM, Rich Felker <dalias@libc.org> wrote:
> On Tue, Feb 09, 2016 at 02:45:50AM +0100, Szabolcs Nagy wrote:
>> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 20:16:25 -0500]:
>> > On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>> > > * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
>> > >> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
>> > >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
>> > >> > > I'm not sure what you mean.  The software emulation assumes the
>> > >> > > hardware support is not present.  It doesn't mirror back the state to
>> > >> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
>> > >> > > compliant.
>> > >> >
>> > >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
>> > >> > rounds to nearest, that's not IEEE compliant.
>> > >> >
>> > >> > The big obstacle to having fenv with softfloat on fully-softfloat
>> > >> > archs is the lack of register state for the rounding mode and
>> > >> > exception flags, so it should be possible to do this right as long as
>> > >> > the cpu has status/mode registers for single/double, which the
>> > >> > soft-quad code can then access/set. If this isn't done right already
>> > >> > we could either try to get it fixed in libgcc or punt and go with
>> > >> > ld64.
>> > >> >
>> > >>
>> > >> it seems to be supported
>> > >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
>> > >>
>> > >> so we can implement iso c annex f with 128 bit long doubles.
>> > >
>> > > hm it seems, this is only for the __float128 type
>> > > which will be new in gcc-6.
>> > >
>> > > i don't see how to configure gcc with ieee128 long double.
>> > > (other than using the debug option -mabi=ieeelongdouble)
>> > >
>> > > so if musl goes with ieee128 long double abi then it will
>> > > only work with latest gcc.
>> >
>> > The musl libc dynamic linking support only was added to the latest GCC.
>> >
>>
>> (resend with correct to:)
>>
>> musl has a gcc wrapper that changes the specs file and then
>> it works even with gcc-3 (on x86 and glibc host without c++).
>>
>> we also have patches for gcc releases going back to gcc-4.7
>
> Indeed. Just patching in the dynamic linker name and a few other
> details to make gcc target musl properly is small and can be done for
> any gcc version. Patching in ieee quad or ABI changes is non-trivial
> though.
>
>> so powerpc64 would be the only arch that depends on features
>> from the latest gcc and that is new situation for musl.
>> (this is mostly interesting because there are historical
>> powerpc64 machines with older toolchains wich might work
>> with musl with minor tweaks if we choose 64bit long double)
>>
>> but if new hw adds ieee128 instructions then i guess that's
>> the right choice.
>
> Obviously the powerpc64 musl target is not going to work with any
> compiler too old to have the "ELFv2 ABI" so that limits how far back
> it's interesting to be compatible with old compilers. What gcc version
> added the v2 ABI? Does clang/llvm support it yet? (Compat with clang
> is also valuable.)

ELFv2 support was backported to GCC 4.8 for use in the Linux distros.

Clang/LLVM support was added in 3.6, I believe.

- David

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 5:52 PM, Rich Felker <dalias@libc.org> wrote:
> On Tue, Feb 09, 2016 at 02:45:50AM +0100, Szabolcs Nagy wrote:
>> * David Edelsohn <dje.gcc@gmail.com> [2016-02-08 20:16:25 -0500]:
>> > On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@port70.net> wrote:
>> > > * Szabolcs Nagy <nsz@port70.net> [2016-02-09 00:48:31 +0100]:
>> > >> * Rich Felker <dalias@libc.org> [2016-02-08 18:29:45 -0500]:
>> > >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
>> > >> > > I'm not sure what you mean.  The software emulation assumes the
>> > >> > > hardware support is not present.  It doesn't mirror back the state to
>> > >> > > the processor in 64 bit mode.  But the emulation is fully IEEE128
>> > >> > > compliant.
>> > >> >
>> > >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
>> > >> > rounds to nearest, that's not IEEE compliant.
>> > >> >
>> > >> > The big obstacle to having fenv with softfloat on fully-softfloat
>> > >> > archs is the lack of register state for the rounding mode and
>> > >> > exception flags, so it should be possible to do this right as long as
>> > >> > the cpu has status/mode registers for single/double, which the
>> > >> > soft-quad code can then access/set. If this isn't done right already
>> > >> > we could either try to get it fixed in libgcc or punt and go with
>> > >> > ld64.
>> > >> >
>> > >>
>> > >> it seems to be supported
>> > >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
>> > >>
>> > >> so we can implement iso c annex f with 128 bit long doubles.
>> > >
>> > > hm it seems, this is only for the __float128 type
>> > > which will be new in gcc-6.
>> > >
>> > > i don't see how to configure gcc with ieee128 long double.
>> > > (other than using the debug option -mabi=ieeelongdouble)
>> > >
>> > > so if musl goes with ieee128 long double abi then it will
>> > > only work with latest gcc.
>> >
>> > The musl libc dynamic linking support only was added to the latest GCC.
>> >
>>
>> (resend with correct to:)
>>
>> musl has a gcc wrapper that changes the specs file and then
>> it works even with gcc-3 (on x86 and glibc host without c++).
>>
>> we also have patches for gcc releases going back to gcc-4.7
>
> Indeed. Just patching in the dynamic linker name and a few other
> details to make gcc target musl properly is small and can be done for
> any gcc version. Patching in ieee quad or ABI changes is non-trivial
> though.

How much would it be for a knowledgeable member of the musl libc
community to provide basic enablement for powerpc64 ELFv2 -- either
initially disable long double or use IEEE 128?  We can think about
optimizations later.

Thanks, David

Re: Re: musl libc for PPC64

[David Edelsohn]

On Mon, Feb 8, 2016 at 6:29 PM, Rich Felker <dalias@libc.org> wrote:
> On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
>> You *can* use v2 ABI for BE, but there is no software to run.  There
>> is no software or ecosystem or operating system that runs v2 ABI BE.
>> It's not a hardware limitation, but there is no environment for the
>> alternate combination.
>
> Indeed. At this point there's no musl ecosystem for ppc64 at all
> though; whatever we add is a fresh start.
>
>> >> IBM has announced that the next generation of the processor will
>> >> support native IEEE128 floating point in hardware.  There will be
>> >> software emulation for the current processors.  Support is included in
>> >> the forthcoming GCC 6.
>> >
>> > OK. Does the existing software emulation properly update the hardware
>> > floating point status (exception flags) and use the rounding mode?
>>
>> I'm not sure what you mean.  The software emulation assumes the
>> hardware support is not present.  It doesn't mirror back the state to
>> the processor in 64 bit mode.  But the emulation is fully IEEE128
>> compliant.
>
> if fesetround(FE_DOWNWARD) succeeds but then long double math still
> rounds to nearest, that's not IEEE compliant.
>
> The big obstacle to having fenv with softfloat on fully-softfloat
> archs is the lack of register state for the rounding mode and
> exception flags, so it should be possible to do this right as long as
> the cpu has status/mode registers for single/double, which the
> soft-quad code can then access/set. If this isn't done right already
> we could either try to get it fixed in libgcc or punt and go with
> ld64.

Who would be interested in working on this?

Thanks, David