From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9963 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, 27 Apr 2016 22:07:51 -0400 Message-ID: <20160428020751.GX21636@brightrain.aerifal.cx> 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> <20160428013819.GA4337@dora.lan> 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 1461809288 8180 80.91.229.3 (28 Apr 2016 02:08:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Apr 2016 02:08:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9976-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 28 04:08:07 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 1avbN9-00030U-OY for gllmg-musl@m.gmane.org; Thu, 28 Apr 2016 04:08:07 +0200 Original-Received: (qmail 7807 invoked by uid 550); 28 Apr 2016 02:08:05 -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 7789 invoked from network); 28 Apr 2016 02:08:04 -0000 Content-Disposition: inline In-Reply-To: <20160428013819.GA4337@dora.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9963 Archived-At: On Wed, Apr 27, 2016 at 08:38:19PM -0500, Bobby Bingham wrote: > > > @@ -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 Wow, the glibc stuff is an utter mess and grossly non-conforming. It doesn't even have a uc_mcontext member of type mcontext_t. At least it looks like all modern kernels have the mcontext_t at the end where it's extensible and doesn't break access to uc_sigmask if it changes. We should probably check and make sure both the current 32-bit powerpc ucontext_t and your proposed powerpc64 one have the mcontext_t members (at least the program counter) accessible at the expected locations. We should probably also let the kernel people know that mcontext_t (and its location) are ABI whether they like it or not. This is imposed by POSIX and the glibc hack of making it a pointer is non-conforming. > > > @@ -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? I'm not entirely sure, but I think you can leave it alone for now. If it needs fixing here, then it already does on multiple existing archs, and they should be handled together. > > > @@ -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. Ah. As noted above, uc_mcontext is at the end so it shouldn't break anything. Rich