From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9912 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v2] add powerpc64 port Date: Thu, 14 Apr 2016 22:08:47 -0400 Message-ID: <20160415020847.GA21636@brightrain.aerifal.cx> References: <1459747571-9123-1-git-send-email-koorogi@koorogi.info> <20160413230506.GE22574@port70.net> <20160414080138.GA23694@dora.lan> <20160414191400.GZ21636@brightrain.aerifal.cx> <20160415005551.GA24404@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 1460686144 25513 80.91.229.3 (15 Apr 2016 02:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Apr 2016 02:09:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9925-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 15 04:09:04 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 1aqtBv-0001w2-GE for gllmg-musl@m.gmane.org; Fri, 15 Apr 2016 04:09:03 +0200 Original-Received: (qmail 20426 invoked by uid 550); 15 Apr 2016 02:09:00 -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 20408 invoked from network); 15 Apr 2016 02:09:00 -0000 Content-Disposition: inline In-Reply-To: <20160415005551.GA24404@dora.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9912 Archived-At: On Thu, Apr 14, 2016 at 07:55:51PM -0500, Bobby Bingham wrote: > On Thu, Apr 14, 2016 at 03:14:00PM -0400, Rich Felker wrote: > > On Thu, Apr 14, 2016 at 03:01:38AM -0500, Bobby Bingham wrote: > > > 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? > > > > I think you could avoid the need for alignment or increased buffer > > size by positioning the vector registers at > > jmp_buf_end-vector_save_size rounded _down_ to alignment, then > > positioning the grps around them (so, putting the last gpr at the end > > rather than before the vectors if the buffer as a whole is > > misaligned). > > Is it valid to do the following? > > jmp_buf a, b; > if (!setjmp(a)) { > memcpy(b, a, sizeof a); > longjmp(b, 1); > } > > If that's valid, and the two jmp_bufs might be aligned differently, then > this wouldn't work. No, jmp_buf's are not values. You have to pass the same object that was passed when calling setjmp when you call longjmp. The relevant text is 7.13.2.1, paragraph 2: "The longjmp function restores the environment saved by the most recent invocation of the setjmp macro in the same invocation of the program with the corresponding jmp_buf argument. If there has been no ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ such invocation, or ... the behavior is undefined." > > But it might be preferable to have the alignment match ABI too. Is > > there any way it can be achieved with just things guaranteed to exist > > by the psABI (is __int128 required by the psABI?) or does it require > > C11 and/or GNUC attributes to get 16-byte alignment? > > The ABI does specify __int128. I can switch jmp_buf to this. That's probably the right thing to do, then. Anyone else have an opinion on it? Rich