mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: David Edelsohn <dje.gcc@gmail.com>
Subject: Re: Re: musl libc for PPC64
Date: Mon, 8 Feb 2016 11:51:44 -0500	[thread overview]
Message-ID: <20160208165143.GA9349@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160208161758.GG9915@port70.net>

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


  reply	other threads:[~2016-02-08 16:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 14:43 David Edelsohn
2016-02-08 16:17 ` Szabolcs Nagy
2016-02-08 16:51   ` Rich Felker [this message]
2016-02-08 17:48     ` David Edelsohn
2016-02-08 20:18       ` Rich Felker
2016-02-08 20:30         ` David Edelsohn
2016-02-08 22:59           ` Rich Felker
2016-02-08 23:24             ` David Edelsohn
2016-02-08 23:29               ` Rich Felker
2016-02-08 23:48                 ` Szabolcs Nagy
2016-02-09  1:03                   ` Szabolcs Nagy
2016-02-09  1:16                     ` David Edelsohn
2016-02-09  1:42                       ` Szabolcs Nagy
2016-02-09  1:45                       ` Szabolcs Nagy
2016-02-09  1:52                         ` Rich Felker
2016-02-09  2:06                           ` David Edelsohn
2016-02-10 22:17                           ` David Edelsohn
2016-02-08 23:52                 ` David Edelsohn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160208165143.GA9349@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=dje.gcc@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).