Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160208165143.GA9349@brightrain.aerifal.cx>
Date: Mon, 8 Feb 2016 11:51:44 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: David Edelsohn <dje.gcc@...il.com>
Subject: Re: Re: musl libc for PPC64

On Mon, Feb 08, 2016 at 05:17:58PM +0100, Szabolcs Nagy wrote:
> * David Edelsohn <dje.gcc@...il.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

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.