From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9905 Path: news.gmane.org!not-for-mail From: Bobby Bingham Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v2] add powerpc64 port Date: Thu, 14 Apr 2016 03:01:38 -0500 Message-ID: <20160414080138.GA23694@dora.lan> 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=utf-8 X-Trace: ger.gmane.org 1460620916 16543 80.91.229.3 (14 Apr 2016 08:01:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 08:01:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9918-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 14 10:01:56 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 1aqcDr-00065r-JQ for gllmg-musl@m.gmane.org; Thu, 14 Apr 2016 10:01:55 +0200 Original-Received: (qmail 17703 invoked by uid 550); 14 Apr 2016 08:01:53 -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 17685 invoked from network); 14 Apr 2016 08:01:52 -0000 Content-Disposition: inline In-Reply-To: <20160413230506.GE22574@port70.net> X-Operating-System: Linux dora 4.3.3 User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9905 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? Yes. Though apparently the glibc setjmp asm has code to detect a misaligned jmp_buf, but its handling of that case ends up overflowing the jmp_buf. I can make some changes to get our jmp_buf down to 65, but the only ways to get it down to 64 are either with 16 byte alignment, or to have setjmp spill vector registers to the stack first so it can copy them from there to the jmp_buf through a gpr. How important is it to match glibc here? > > > +#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 > Ok. > > +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. I can do this for now, but I like Rich's suggestion to remove this duplication. > > > +++ 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 I'll see if we can at least detect it in configure and error out. > > > +#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.