From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9902 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v2] add powerpc64 port Date: Thu, 14 Apr 2016 01:05:07 +0200 Message-ID: <20160413230506.GE22574@port70.net> References: <1459747571-9123-1-git-send-email-koorogi@koorogi.info> 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 1460588723 12098 80.91.229.3 (13 Apr 2016 23:05:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Apr 2016 23:05:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9915-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 14 01:05:22 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 1aqTqc-0001AE-3t for gllmg-musl@m.gmane.org; Thu, 14 Apr 2016 01:05:22 +0200 Original-Received: (qmail 27933 invoked by uid 550); 13 Apr 2016 23:05:19 -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 27909 invoked from network); 13 Apr 2016 23:05:19 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <1459747571-9123-1-git-send-email-koorogi@koorogi.info> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9902 Archived-At: * 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? > +#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 > +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.) > +++ 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. > +++ 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 > +#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. > +++ 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 otherwise the patch looked good.