From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9962 Path: news.gmane.org!not-for-mail From: Bobby Bingham Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v2] add powerpc64 port Date: Wed, 27 Apr 2016 20:38:19 -0500 Message-ID: <20160428013819.GA4337@dora.lan> References: <1459747571-9123-1-git-send-email-koorogi@koorogi.info> <20160413230506.GE22574@port70.net> <20160414080138.GA23694@dora.lan> <20160414134213.GG22574@port70.net> <20160415203832.GH22574@port70.net> <20160416170934.GG21636@brightrain.aerifal.cx> 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 1461807523 17217 80.91.229.3 (28 Apr 2016 01:38:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2016 01:38:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9975-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 28 03:38:37 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 1avaua-0005ot-Sk for gllmg-musl@m.gmane.org; Thu, 28 Apr 2016 03:38:36 +0200 Original-Received: (qmail 26088 invoked by uid 550); 28 Apr 2016 01:38:34 -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 26070 invoked from network); 28 Apr 2016 01:38:33 -0000 Content-Disposition: inline In-Reply-To: <20160416170934.GG21636@brightrain.aerifal.cx> 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:9962 Archived-At: On Sat, Apr 16, 2016 at 01:09:34PM -0400, Rich Felker wrote: > On Fri, Apr 15, 2016 at 10:38:33PM +0200, Szabolcs Nagy wrote: > > * Szabolcs Nagy [2016-04-14 15:42:13 +0200]: > > > * Bobby Bingham [2016-04-14 03:01:38 -0500]: > > > > > > > > How important is it to match glibc here? > > > > > > > > > > i think we don't care about abi compat > > > (but it might be interesting to check how much abi > > > difference there is between glibc and musl, i can > > > do this if i can build a musl+glibc toolchain) > > > > > > > attached some c++ abi comparisions > > Thanks! > > > (the comparision was not entirely clean, it involved > > various manual hacks, but most types and functions > > should be compared correctly glibc vs musl) > > > > two interesting gcc warnings: > > > > powerpc64 elf_vrreg_t (both musl and glibc): > > note: the ABI of passing aggregates with 16-byte alignment has changed in GCC 5 > > This could be mildly problematic, but it's in a junk interface that's > unlikely to be used cross-library anyway. > > > x86_64 struct inotify_event (musl only): > > note: the ABI of passing struct with a flexible array member has changed in GCC 4.4 > > This looks irrelevant; passing the struct by value does not make sense. > > > --- abi_type.powerpc64le.glibc 2016-04-15 21:00:27.432246225 +0100 > > +++ abi_type.powerpc64le.musl 2016-04-15 20:57:39.000149371 +0100 > > @@ -97 +96 @@ > > -fexcept_t: unsigned int, unsigned int*, size (*) [4], align (*) [4] > > +fexcept_t: unsigned long, unsigned long*, size (*) [8], align (*) [8] > > Is this right? I've fixed this locally. I'll submit a new patch soon. > > > @@ -100,2 +99,2 @@ > > -fpos_t: _G_fpos_t, _G_fpos_t*, size (*) [16], align (*) [8] > > +fpos_t: _G_fpos64_t, _G_fpos64_t*, size (*) [16], align (*) [8] > > You should probably be testing with -D_FILE_OFFSET_BITS=64. musl > implements that ABI, and it matters in a few places even on 64-bit > archs, like here. > > > @@ -130 +130 @@ > > -jmp_buf: __jmp_buf_tag*, __jmp_buf_tag (*) [1], size (*) [656], align (*) [16] > > +jmp_buf: __jmp_buf_tag*, __jmp_buf_tag (*) [1], size (*) [664], align (*) [8] > > Let's fix at least alignment and hopefully size. Ok > > > @@ -141 +141 @@ > > -mcontext_t: mcontext_t, mcontext_t*, size (*) [1272], align (*) [8] > > +mcontext_t: sigcontext, sigcontext*, size (*) [1528], align (*) [8] > > IIRC on other archs we made an effort to make the tag here match ABI > (duplicating the struct def if needed). Not sure if it matters. I can duplicate the structure if you want. But it looks like glibc used to do 'typedef struct sigcontext mcontext_t' as well: https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/powerpc/sys/ucontext.h;h=a499a80ef9994e541b866202ee8440843b004fdd;hp=b75e25a3c84c852b22e1690ff530d3ddb8dff257;hb=5ef6ae4bdb;hpb=39b04aa39823faf1cc414e7f3eca4f43e01426e4 > > > @@ -183,2 +183,2 @@ > > -pthread_rwlockattr_t: pthread_rwlockattr_t, pthread_rwlockattr_t*, size (*) [8], align (*) [8] > > +pthread_rwlockattr_t: pthread_rwlockattr_t, pthread_rwlockattr_t*, size (*) [8], align (*) [4] > > Alignment difference was unintentional here but seems bad to try to > fix for existing archs and I don't want to make the pthread types > arch-specific; actually I want to move them to the shared > alltypes.h.in or new arch/generic* with just a dependency on 32/64 > bit. > > > -pthread_spinlock_t: int, int volatile*, size (*) [4], align (*) [4] > > +pthread_spinlock_t: int, int*, size (*) [4], align (*) [4] > > Did glibc add volatile here? IIRC it was not there to begin with. If > so they broke their own C++ ABI. I'd like to change this too, and if > glibc did change it without anyone noticing/caring, we probably could > too. > > > @@ -195 +195 @@ > > -sem_t: sem_t, sem_t*, size (*) [32], align (*) [8] > > +sem_t: sem_t, sem_t*, size (*) [32], align (*) [4] > > > @@ -229,2 +229,2 @@ > > -cmsghdr: cmsghdr, cmsghdr*, size (*) [16], align (*) [8] > > +cmsghdr: cmsghdr, cmsghdr*, size (*) [16], align (*) [4] > > This is likely going to hit the same issue we're trying to debug on > mips64. The mips64 issue ended up not being alignment related. Do you still want me to do something about this? And if so, do you have a suggestion? > > > @@ -416 +417 @@ > > -ucontext_t: ucontext, ucontext*, size (*) [1440], align (*) [8] > > +ucontext_t: ucontext, ucontext*, size (*) [1696], align (*) [8] > > This may be a real problem. ucontext_t is ABI between kernel and > userspace and if it's wrong cancellation won't work right. Kernel commit ce48b2100785 expanded the vmx_reserve member of mcontext_t by 256 bytes. The glibc headers haven't been updated for this expansion. > > Rich