mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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).