Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Aug 2017 23:04:51 -0500
From: Bobby Bingham <>
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

> 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.