* [musl] sigsetjmp @ 2020-06-08 1:45 sidneym 2020-06-08 17:10 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: sidneym @ 2020-06-08 1:45 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 990 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 4422 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sigsetjmp 2020-06-08 1:45 [musl] sigsetjmp sidneym @ 2020-06-08 17:10 ` Rich Felker 2020-06-09 1:01 ` sidneym 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2020-06-08 17:10 UTC (permalink / raw) To: sidneym; +Cc: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [musl] sigsetjmp 2020-06-08 17:10 ` Rich Felker @ 2020-06-09 1:01 ` sidneym 2020-06-09 1:12 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: sidneym @ 2020-06-09 1:01 UTC (permalink / raw) To: musl > -----Original Message----- > From: Rich Felker <dalias@libc.org> > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sigsetjmp 2020-06-09 1:01 ` sidneym @ 2020-06-09 1:12 ` Rich Felker 2020-06-10 17:44 ` sidneym 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2020-06-09 1:12 UTC (permalink / raw) To: sidneym; +Cc: musl On Mon, Jun 08, 2020 at 08:01:24PM -0500, sidneym@codeaurora.org wrote: > > > > -----Original Message----- > > From: Rich Felker <dalias@libc.org> > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [musl] sigsetjmp 2020-06-09 1:12 ` Rich Felker @ 2020-06-10 17:44 ` sidneym 0 siblings, 0 replies; 5+ messages in thread From: sidneym @ 2020-06-10 17:44 UTC (permalink / raw) To: musl > -----Original Message----- > From: Rich Felker <dalias@libc.org> > 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 <dalias@libc.org> > > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-06-10 17:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-08 1:45 [musl] sigsetjmp sidneym 2020-06-08 17:10 ` Rich Felker 2020-06-09 1:01 ` sidneym 2020-06-09 1:12 ` Rich Felker 2020-06-10 17:44 ` sidneym
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).