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 31253 invoked from network); 11 Aug 2020 18:45:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 11 Aug 2020 18:45:43 -0000 Received: (qmail 17622 invoked by uid 550); 11 Aug 2020 18:45:41 -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 17604 invoked from network); 11 Aug 2020 18:45:40 -0000 Date: Tue, 11 Aug 2020 14:45:28 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200811184527.GM3265@brightrain.aerifal.cx> References: <20200811181116.8433-1-amonakov@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200811181116.8433-1-amonakov@ispras.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH 1/3] setjmp: fix x86-64 longjmp argument adjustment On Tue, Aug 11, 2020 at 09:11:14PM +0300, Alexander Monakov wrote: > longjmp 'val' argument is an int, but the assembly is referencing 64-bit > registers as if the argument was a long, or the caller was responsible > for extending the argument. Though the psABI is not clear on this, the > interpretation in GCC is that high bits may be arbitrary and the callee > is responsible for sign/zero-extending the value as needed (likewise for > return values: callers must anticipate that high bits may be garbage). > > Therefore testing %rax is a functional bug: setjmp would wrongly return > zero if longjmp was called with val==0, but high bits of %rsi happened > to be non-zero. > > Rewrite the prologue to refer to 32-bit registers. In passing, change > 'test' to use %rsi, as there's no advantage to using %rax and the new > form is cheaper on processors that do not perform move elimination. > --- > src/setjmp/x32/longjmp.s | 6 +++--- > src/setjmp/x86_64/longjmp.s | 6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/src/setjmp/x32/longjmp.s b/src/setjmp/x32/longjmp.s > index e175a4b9..e709acad 100644 > --- a/src/setjmp/x32/longjmp.s > +++ b/src/setjmp/x32/longjmp.s > @@ -5,10 +5,10 @@ > .type longjmp,@function > _longjmp: > longjmp: > - mov %rsi,%rax /* val will be longjmp return */ > - test %rax,%rax > + mov %esi,%eax /* val will be longjmp return */ > + test %esi,%esi > jnz 1f > - inc %rax /* if val==0, val=1 per longjmp semantics */ > + inc %eax /* if val==0, val=1 per longjmp semantics */ > 1: > mov (%rdi),%rbx /* rdi is the jmp_buf, restore regs from it */ > mov 8(%rdi),%rbp > diff --git a/src/setjmp/x86_64/longjmp.s b/src/setjmp/x86_64/longjmp.s > index e175a4b9..e709acad 100644 > --- a/src/setjmp/x86_64/longjmp.s > +++ b/src/setjmp/x86_64/longjmp.s > @@ -5,10 +5,10 @@ > .type longjmp,@function > _longjmp: > longjmp: > - mov %rsi,%rax /* val will be longjmp return */ > - test %rax,%rax > + mov %esi,%eax /* val will be longjmp return */ > + test %esi,%esi > jnz 1f > - inc %rax /* if val==0, val=1 per longjmp semantics */ > + inc %eax /* if val==0, val=1 per longjmp semantics */ > 1: > mov (%rdi),%rbx /* rdi is the jmp_buf, restore regs from it */ > mov 8(%rdi),%rbp > -- > 2.11.0 Thanks! This whole series looks good and I'm applying it now. Re: optimizing the tails, I wonder why they were ever written the way they were to begin with. At least the i386 one was written by me so there's nobody else to ask, but do you have any insight into what I might have been thinking? Rich