[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170812003223.GO1627@brightrain.aerifal.cx>
Date: Fri, 11 Aug 2017 20:32:23 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] ppc64: fix setjmp/longjmp handling of TOC pointer
On Sun, Aug 06, 2017 at 11:04:51PM -0500, Bobby Bingham wrote:
> On Sun, Aug 06, 2017 at 11:15:27PM -0400, Rich Felker wrote:
> > Am I correct that you're saving the TOC value alongside where
> > sigsetjmp was already saving the original r16 value, 8 bytes past the
> > start of the sigset_t? This looks ok; there's plenty of extra space
>
> Yes, that's exactly what the code is doing.
>
> > there. Alternatively I think you could just recompute it the same way
> > the nonlocal prologue does, but I don't see any reason to prefer that
> > unless we were running out of space in the jmp_buf.
>
> I did consider this, but didn't see a strong reason to prefer it.
>
> The canonical sequence of instructions for calculating the TOC pointer
> takes advantage of the fact that the ABI requires that the address of
> the non-local entry point be loaded into r12 before calling it. After
> the second return from setjmp, r12 may have been clobbered, so we'd need
> a different sequence to calculate the TOC pointer if we did this.
>
> My main reason to write it the way I did was to be able to use the
> standard TOC pointer calculation, which gives me more confidence in its
> correctness.
>
> >
> > Anyway, as long as my understanding is correct, I see no reason not to
> > commit this patch as-is. It's well-documented and seems to solve the
> > problem fully. Thanks.
OK, merging. Thanks!
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
