From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22349 invoked from network); 8 Jun 2020 01:45:55 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 01:45:55 -0000 Received: (qmail 10186 invoked by uid 550); 8 Jun 2020 01:45:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10137 invoked from network); 8 Jun 2020 01:45:45 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1591580747; h=Content-Type: MIME-Version: Message-ID: Date: Subject: To: From: Sender; bh=Ye1Mot1SZv1srzxOg93pxHGleOewHFdYBB73a7jhbjE=; b=j70uvjbPCB72PQiqkMo1o9EyVO5IEq7vuIlae1oSKbYs3rtdyULzQ+IAAfyIlI22NPYJSsQ7 MxPuRnVxgJsbmcjZI/Q1WVWm/SBuiA/2cp3VLBzO+9aSVUsIZqMLvmQpTuGpmaIioT8Ua5mT 3n9md0Dzku1n6sUF85rRKFMz+Vg= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 42038C433CA Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: Date: Sun, 7 Jun 2020 20:45:11 -0500 Message-ID: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_036D_01D63D0C.8AEEB550" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdY9M72N+zNZID0eTOG5X3HNEw+law== Content-Language: en-us Subject: [musl] sigsetjmp This is a multipart message in MIME format. ------=_NextPart_000_036D_01D63D0C.8AEEB550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wanting to make sure I'm reading the requirements correctly. Looks like this routine only needs to save the link register and env, call setjmp then restore the link register and env followed by the tail call. Hexagon was out of date so I did this: .balign 4 .type sigsetjmp,@function sigsetjmp: // if savemask is 0 sigsetjmp behaves like setjmp { p0 = cmp.eq(r1, #0) if (p0.new) jump:t ##setjmp } { memw(r0+#64+4) = r16 // save r16 in __ss[0] memw(r0+#64) = r31 // save linkregister in __fl r16 = r0 } call ##setjmp { r0 = r16 // restore r0 r31 = memw(r16+#64) // restore linkregister r16 = memw(r16+#64+4) // restore r16 from __ss[0] } .hidden __sigsetjmp_tail jump ##__sigsetjmp_tail .size sigsetjmp, .-sigsetjmp ------=_NextPart_000_036D_01D63D0C.8AEEB550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wanting to make sure I’m reading the = requirements correctly.

Looks like = this routine only needs to save the link register and env, call setjmp = then restore the link register and env followed by the tail = call.

Hexagon was out of date so I did = this:

.balign 4

.type = sigsetjmp,@function

sigsetjmp:

// if = savemask is 0 sigsetjmp behaves like setjmp

= {

&= nbsp; p0 =3D cmp.eq(r1, = #0)

&= nbsp; if (p0.new) jump:t = ##setjmp

= }

= {

&= nbsp; memw(r0+#64+4) =3D r16 // = save r16 in __ss[0]

&= nbsp; memw(r0+#64) =3D = r31 // save linkregister in __fl

&= nbsp; r16 =3D r0

= }

&= nbsp; call ##setjmp

= {

&= nbsp; r0 =3D = r16 &nbs= p; // restore r0

&= nbsp; r31 =3D memw(r16+#64) // = restore linkregister

&= nbsp; r16 =3D memw(r16+#64+4) // restore = r16 from __ss[0]

= }

.hidden = __sigsetjmp_tail

jump = ##__sigsetjmp_tail

.size sigsetjmp, = .-sigsetjmp

------=_NextPart_000_036D_01D63D0C.8AEEB550-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16143 invoked from network); 8 Jun 2020 17:11:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 17:11:14 -0000 Received: (qmail 8122 invoked by uid 550); 8 Jun 2020 17:11:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 8101 invoked from network); 8 Jun 2020 17:11:10 -0000 Date: Mon, 8 Jun 2020 13:10:57 -0400 From: Rich Felker To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200608171057.GC1079@brightrain.aerifal.cx> References: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] sigsetjmp On Sun, Jun 07, 2020 at 08:45:11PM -0500, sidneym@codeaurora.org wrote: > Wanting to make sure I'm reading the requirements correctly. > > Looks like this routine only needs to save the link register and env, call > setjmp then restore the link register and env followed by the tail call. Yes, that's correct. This is an unconventional design but necessary so that the stack frame has already been restored when signals are unmasked by siglongjmp. See the message for commit 583e55122e767b1586286a0d9c35e2a4027998ab for a description of how this works. > Hexagon was out of date so I did this: > > > > ..balign 4 > > ..type sigsetjmp,@function > > sigsetjmp: > > // if savemask is 0 sigsetjmp behaves like setjmp > > { > > p0 = cmp.eq(r1, #0) > > if (p0.new) jump:t ##setjmp > > } > > { > > memw(r0+#64+4) = r16 // save r16 in __ss[0] > > memw(r0+#64) = r31 // save linkregister in __fl > > r16 = r0 > > } This is not correct. __ss[0] is occupied by the saved signal mask, and will be clobbered when it's saved in the tail call. Instead you need to use unused space in struct __jmp_buf_tag. The canonical place is (char*)__ss+8 (the "HURD ABI area" :) assuming _NSIG==65. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31174 invoked from network); 9 Jun 2020 01:02:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Jun 2020 01:02:11 -0000 Received: (qmail 3886 invoked by uid 550); 9 Jun 2020 01:02:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3857 invoked from network); 9 Jun 2020 01:02:03 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1591664523; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-ID: Date: Subject: In-Reply-To: References: To: From: Sender; bh=eEu6Tfyme/QbNZOiTDsogKX7UpCjRnMUYQL2w32dFEY=; b=qLF0eo3pL61SRZEqJl7JkpOam+t4ituZKL1N/BYQ9gpraIdhEacOxJj+9d+RnfaC8IfATQCO QHHFALiJMxJdJypFJ1r3ZW+bFkhsEuawPZ1+Sj7xqoDdqCJXomPlQAleQEp1yF8qZ4E9rIAm W4m4IEUOgwBTeOoHChgWqJfvnTU= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 63B4DC43391 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: References: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> <20200608171057.GC1079@brightrain.aerifal.cx> In-Reply-To: <20200608171057.GC1079@brightrain.aerifal.cx> Date: Mon, 8 Jun 2020 20:01:24 -0500 Message-ID: <0bbd01d63df9$7fd69a50$7f83cef0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHfikOQM2lGCwPrn1tVskxFRUd5xwI3AqQLqKsXq+A= Content-Language: en-us Subject: RE: [musl] sigsetjmp > -----Original Message----- > From: Rich Felker > Sent: Monday, June 8, 2020 12:11 PM > To: sidneym@codeaurora.org > Cc: musl@lists.openwall.com > Subject: Re: [musl] sigsetjmp > > On Sun, Jun 07, 2020 at 08:45:11PM -0500, sidneym@codeaurora.org wrote: > > Wanting to make sure I'm reading the requirements correctly. > > > > Looks like this routine only needs to save the link register and env, > > call setjmp then restore the link register and env followed by the tail call. > > Yes, that's correct. This is an unconventional design but necessary so that the > stack frame has already been restored when signals are unmasked by > siglongjmp. See the message for commit > 583e55122e767b1586286a0d9c35e2a4027998ab for a description of how this > works. > > > Hexagon was out of date so I did this: > > > > > > > > ..balign 4 > > > > ..type sigsetjmp,@function > > > > sigsetjmp: > > > > // if savemask is 0 sigsetjmp behaves like setjmp > > > > { > > > > p0 = cmp.eq(r1, #0) > > > > if (p0.new) jump:t ##setjmp > > > > } > > > > { > > > > memw(r0+#64+4) = r16 // save r16 in __ss[0] > > > > memw(r0+#64) = r31 // save linkregister in __fl > > > > r16 = r0 > > > > } > > This is not correct. __ss[0] is occupied by the saved signal mask, and will be > clobbered when it's saved in the tail call. Instead you need to use unused space > in struct __jmp_buf_tag. The canonical place is > (char*)__ss+8 (the "HURD ABI area" :) assuming _NSIG==65. I was not able to find a description of the HURD ABI area is it documented someplace? So upon entry to sigsetjmp __ss[0] is holding the saved mask and using __ss[0] to buffer r16 will clobber it, correct? As it is coded __ss[0] is just used over the call to setjmp to preserve the value of r16. If __ss is r0+#64+4, then you are suggesting that I use r0+#64+4+8 or __ss[2]. I need to look into this some more because with that I'm have some testcase issues. Thanks, > > Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32316 invoked from network); 9 Jun 2020 01:13:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Jun 2020 01:13:07 -0000 Received: (qmail 32287 invoked by uid 550); 9 Jun 2020 01:13:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32269 invoked from network); 9 Jun 2020 01:13:03 -0000 Date: Mon, 8 Jun 2020 21:12:51 -0400 From: Rich Felker To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200609011251.GD1079@brightrain.aerifal.cx> References: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> <20200608171057.GC1079@brightrain.aerifal.cx> <0bbd01d63df9$7fd69a50$7f83cef0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0bbd01d63df9$7fd69a50$7f83cef0$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] sigsetjmp On Mon, Jun 08, 2020 at 08:01:24PM -0500, sidneym@codeaurora.org wrote: > > > > -----Original Message----- > > From: Rich Felker > > Sent: Monday, June 8, 2020 12:11 PM > > To: sidneym@codeaurora.org > > Cc: musl@lists.openwall.com > > Subject: Re: [musl] sigsetjmp > > > > On Sun, Jun 07, 2020 at 08:45:11PM -0500, sidneym@codeaurora.org wrote: > > > Wanting to make sure I'm reading the requirements correctly. > > > > > > Looks like this routine only needs to save the link register and env, > > > call setjmp then restore the link register and env followed by the tail > call. > > > > Yes, that's correct. This is an unconventional design but necessary so > that the > > stack frame has already been restored when signals are unmasked by > > siglongjmp. See the message for commit > > 583e55122e767b1586286a0d9c35e2a4027998ab for a description of how this > > works. > > > > > Hexagon was out of date so I did this: > > > > > > > > > > > > ..balign 4 > > > > > > ..type sigsetjmp,@function > > > > > > sigsetjmp: > > > > > > // if savemask is 0 sigsetjmp behaves like setjmp > > > > > > { > > > > > > p0 = cmp.eq(r1, #0) > > > > > > if (p0.new) jump:t ##setjmp > > > > > > } > > > > > > { > > > > > > memw(r0+#64+4) = r16 // save r16 in __ss[0] > > > > > > memw(r0+#64) = r31 // save linkregister in __fl > > > > > > r16 = r0 > > > > > > } > > > > This is not correct. __ss[0] is occupied by the saved signal mask, and > will be > > clobbered when it's saved in the tail call. Instead you need to use unused > space > > in struct __jmp_buf_tag. The canonical place is > > (char*)__ss+8 (the "HURD ABI area" :) assuming _NSIG==65. > > I was not able to find a description of the HURD ABI area is it documented > someplace? By "HURD ABI" I just mean the fact that sigset_t is gratuitously 128 bytes rather than 8 bytes, because early glibc imagined uselessly having 1024 signals like GNU HURD will someday do. The point is that only the first 8 (or 16, on MIPS*) bytes of the signal mask save area (__ss[]) are actually used for saving a signal mask, and the rest is free for sigsetjmp to use for other purposes. > So upon entry to sigsetjmp __ss[0] is holding the saved mask and using > __ss[0] to buffer r16 will clobber it, correct? As it is coded __ss[0] is > just used over the call to setjmp to preserve the value of r16. No, upon entry __ss[0] is uninitialized. __sigsetjmp_tail will store the signal mask into it (and __ss[1], on 32-bit archs) before returning to the caller, and on the second return (via siglongjmp) will restore the signal mask from there. > If __ss is r0+#64+4, then you are suggesting that I use r0+#64+4+8 or > __ss[2]. I need to look into this some more because with that I'm have some > testcase issues. Yes, that sounds right. Look what other archs do. The arm version is very easy to read. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27864 invoked from network); 10 Jun 2020 17:44:34 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Jun 2020 17:44:34 -0000 Received: (qmail 7951 invoked by uid 550); 10 Jun 2020 17:44:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7933 invoked from network); 10 Jun 2020 17:44:29 -0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1591811069; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-ID: Date: Subject: In-Reply-To: References: To: From: Sender; bh=dC20mOP/R5je7XUxangcNqwnooX1cgU7Ec9w0zJOypQ=; b=rqjMRgE9PtXiXyehNnaBw2n/0rFhqftt+eKJzdX15bWJ++E2Q+uHWq0bOKblSx5+2uZEQUV4 Cx92qa5Zn+tWcEZUMV2/h1iUYnVitUzOTEzi0ML8YQEvAKKKyqqLeEgNSx/gjCw5Fz2aU64P pSmGcWg4KNtuncXkrnEllnUS7Qk= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI1MGQzMyIsICJtdXNsQGxpc3RzLm9wZW53YWxsLmNvbSIsICJiZTllNGEiXQ== Sender: sidneym=codeaurora.org@mg.codeaurora.org DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org CC566C433CA Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=sidneym@codeaurora.org From: To: References: <036c01d63d36$73c42110$5b4c6330$@codeaurora.org> <20200608171057.GC1079@brightrain.aerifal.cx> <0bbd01d63df9$7fd69a50$7f83cef0$@codeaurora.org> <20200609011251.GD1079@brightrain.aerifal.cx> In-Reply-To: <20200609011251.GD1079@brightrain.aerifal.cx> Date: Wed, 10 Jun 2020 12:44:14 -0500 Message-ID: <194701d63f4e$c2a74770$47f5d650$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHfikOQM2lGCwPrn1tVskxFRUd5xwI3AqQLAgKDeAABiSOaD6iRb+/Q Content-Language: en-us Subject: RE: [musl] sigsetjmp > -----Original Message----- > From: Rich Felker > Sent: Monday, June 8, 2020 8:13 PM > To: sidneym@codeaurora.org > Cc: musl@lists.openwall.com > Subject: Re: [musl] sigsetjmp > > On Mon, Jun 08, 2020 at 08:01:24PM -0500, sidneym@codeaurora.org wrote: > > > > > > > -----Original Message----- > > > From: Rich Felker > > > Sent: Monday, June 8, 2020 12:11 PM > > > To: sidneym@codeaurora.org > > > Cc: musl@lists.openwall.com > > > Subject: Re: [musl] sigsetjmp > > > > > > On Sun, Jun 07, 2020 at 08:45:11PM -0500, sidneym@codeaurora.org > wrote: > > > > Wanting to make sure I'm reading the requirements correctly. > > > > > > > > Looks like this routine only needs to save the link register and > > > > env, call setjmp then restore the link register and env followed > > > > by the tail > > call. > > > > > > Yes, that's correct. This is an unconventional design but necessary > > > so > > that the > > > stack frame has already been restored when signals are unmasked by > > > siglongjmp. See the message for commit > > > 583e55122e767b1586286a0d9c35e2a4027998ab for a description of how > > > this works. > > > > > > > Hexagon was out of date so I did this: > > > > > > > > > > > > > > > > ..balign 4 > > > > > > > > ..type sigsetjmp,@function > > > > > > > > sigsetjmp: > > > > > > > > // if savemask is 0 sigsetjmp behaves like setjmp > > > > > > > > { > > > > > > > > p0 = cmp.eq(r1, #0) > > > > > > > > if (p0.new) jump:t ##setjmp > > > > > > > > } > > > > > > > > { > > > > > > > > memw(r0+#64+4) = r16 // save r16 in __ss[0] > > > > > > > > memw(r0+#64) = r31 // save linkregister in __fl > > > > > > > > r16 = r0 > > > > > > > > } > > > > > > This is not correct. __ss[0] is occupied by the saved signal mask, > > > and > > will be > > > clobbered when it's saved in the tail call. Instead you need to use > > > unused > > space > > > in struct __jmp_buf_tag. The canonical place is > > > (char*)__ss+8 (the "HURD ABI area" :) assuming _NSIG==65. > > > > I was not able to find a description of the HURD ABI area is it > > documented someplace? > > By "HURD ABI" I just mean the fact that sigset_t is gratuitously 128 bytes rather > than 8 bytes, because early glibc imagined uselessly having 1024 signals like > GNU HURD will someday do. > > The point is that only the first 8 (or 16, on MIPS*) bytes of the signal mask save > area (__ss[]) are actually used for saving a signal mask, and the rest is free for > sigsetjmp to use for other purposes. > > > So upon entry to sigsetjmp __ss[0] is holding the saved mask and using > > __ss[0] to buffer r16 will clobber it, correct? As it is coded > > __ss[0] is just used over the call to setjmp to preserve the value of r16. > > No, upon entry __ss[0] is uninitialized. __sigsetjmp_tail will store the signal > mask into it (and __ss[1], on 32-bit archs) before returning to the caller, and on > the second return (via siglongjmp) will restore the signal mask from there. > > > If __ss is r0+#64+4, then you are suggesting that I use r0+#64+4+8 or > > __ss[2]. I need to look into this some more because with that I'm have > > some testcase issues. > > Yes, that sounds right. Look what other archs do. The arm version is very easy > to read. Thanks, I updated the source to match aarch64 and at the moment all of the associated tests are passing. > > Rich