From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9903 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v2] add powerpc64 port Date: Wed, 13 Apr 2016 19:13:59 -0400 Message-ID: <20160413231359.GX21636@brightrain.aerifal.cx> References: <1459747571-9123-1-git-send-email-koorogi@koorogi.info> <20160413230506.GE22574@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1460589255 19581 80.91.229.3 (13 Apr 2016 23:14:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Apr 2016 23:14:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9916-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 14 01:14:15 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aqTzC-0005GV-QM for gllmg-musl@m.gmane.org; Thu, 14 Apr 2016 01:14:14 +0200 Original-Received: (qmail 3739 invoked by uid 550); 13 Apr 2016 23:14:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3721 invoked from network); 13 Apr 2016 23:14:11 -0000 Content-Disposition: inline In-Reply-To: <20160413230506.GE22574@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9903 Archived-At: On Thu, Apr 14, 2016 at 01:05:07AM +0200, Szabolcs Nagy wrote: > * Bobby Bingham [2016-04-04 00:26:11 -0500]: > > +++ b/arch/powerpc64/bits/setjmp.h > > @@ -0,0 +1 @@ > > +typedef unsigned long long __jmp_buf[66]; > > hm glibc seems to use long[64] with 16byte alignment, > is the size diff because of alignment? Good catch. > > +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE) > > +#define MINSIGSTKSZ 2048 > > +#define SIGSTKSZ 8192 > > +#endif > > i think these should be bigger, e.g. follow ppc 4k, 10k Agreed. > > +typedef struct { > > + unsigned long vrregs[32][2]; > > + unsigned _pad[3]; > > + unsigned vrsave; > > + unsigned vscr; > > + unsigned _pad2[3]; > > +} vrregset_t; > > it seems this type should be 16 byte aligned like elf_vrreg_t > > (aarch64 has a similar issue i plan to fix: there we use > 128bit long double to get correct alignment, but kernel > and glibc uses __int128 which is visible in public headers. > in powerpc64 at least __vector128 is not exposed in glibc, > only 16byte aligned structs.) I don't know what the best solution here is. > > +++ b/arch/powerpc64/bits/syscall.h > > @@ -0,0 +1,718 @@ > > +#define __NR_restart_syscall 0 > > +#define __NR_exit 1 > > +#define __NR_fork 2 > .... > > +#define SYS_restart_syscall __NR_restart_syscall > > +#define SYS_exit __NR_exit > > +#define SYS_fork __NR_fork > > i prefer SYS_ to use numbers too (easier to update for me), > but it should be probably fixed together across archs. I want to replace arch/*/bits/syscall.h with .in files that get processed as something like: sed -e p -e s/__NR_/SYS_/ < $< > $@ This would reduce the source tree size a lot and eliminate the risk of inconsistency. > > +++ b/arch/powerpc64/reloc.h > > @@ -0,0 +1,32 @@ > > +#include > > + > > +#if __BYTE_ORDER == __LITTLE_ENDIAN > > +#define ENDIAN_SUFFIX "le" > > +#else > > +#define ENDIAN_SUFFIX "" > > +#endif > > + > > +#define LDSO_ARCH "powerpc64" ENDIAN_SUFFIX > > + > > gcc also has -sf, i'm not sure if we should care about > ppc64 soft-float Probably not, but perhaps we should test in configure and reject it if it's not supported correctly. > > +#define TPOFF_K (-0x7000) > > + > > +#define REL_SYMBOLIC R_PPC64_ADDR64 > > +#define REL_GOT R_PPC64_GLOB_DAT > > +#define REL_PLT R_PPC64_JMP_SLOT > > +#define REL_RELATIVE R_PPC64_RELATIVE > > +#define REL_COPY R_PPC64_COPY > > +#define REL_DTPMOD R_PPC64_DTPMOD64 > > +#define REL_DTPOFF R_PPC64_DTPREL64 > > +#define REL_TPOFF R_PPC64_TPREL64 > > this reminds me that ppc(64) now has a tls optimization > if the module is tagged with DT_PPC(64)_OPT, we don't > need to implement it yet, but eventually elf.h should > be updated. Details? > > +++ b/src/fenv/powerpc64/fenv.c > > @@ -0,0 +1,68 @@ > > +#define _GNU_SOURCE > > +#include > > + > > +static inline double get_fpscr_f(void) > > +{ > > + double d; > > + __asm__ __volatile__("mffs %0" : "=d"(d)); > > + return d; > > +} > > + > > +static inline long get_fpscr(void) > > +{ > > + return (union {double f; long i;}) {get_fpscr_f()}.i; > > +} > > + > > +static inline void set_fpscr_f(double fpscr) > > +{ > > + __asm__ __volatile__("mtfsf 255, %0" : : "d"(fpscr)); > > +} > > + > > +static void set_fpscr(long fpscr) > > +{ > > + set_fpscr_f((union {long i; double f;}) {fpscr}.f); > > +} > > + > > yes now that .c is allowed under arch/ dirs, it > makes sense to do fenv with such set/get_fpscr Yes. At some point it would be nice to make it so most archs can just define inline functions to load/store their fpu control/status registers, and a generic fenv.c can implement all the functions. A few weird archs (x86) would still need custom versions to be efficient but most could use the generic framework. But this change should not be a blocker for ppc64. I like the above approach fine for now. Rich