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.