[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170807040450.GA12378@dora.lan>
Date: Sun, 6 Aug 2017 23:04:51 -0500
From: Bobby Bingham <koorogi@...rogi.info>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] ppc64: fix setjmp/longjmp handling of TOC pointer
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.
>
> 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.
