[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170801224533.GD1627@brightrain.aerifal.cx>
Date: Tue, 1 Aug 2017 18:45:33 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: possible bug in setjmp implementation for ppc64
On Tue, Aug 01, 2017 at 08:28:27AM +0300, Alexander Monakov wrote:
> On Tue, 1 Aug 2017, Bobby Bingham wrote:
> > I think this either requires having different versions of setjmp/longjmp
> > for static and dynamic libc,
>
> Do you mean for non-pic vs pic objects? As I understand, when libc.a is
> built with -fpic (so it's suitable for static-pie), setjmp-longjmp need
> to preserve saved TOC at (r1+24). So presumably source code would need
> to test #ifdef __PIC__?
>
> > or to increase the size of jmpbuf so we can always save/restore both
> > r2 and the value on the stack, but this would be an ABI change.
>
> Would that work for non-pic, i.e. is (r1+24) a reserved location even in
> non-pic mode? If not, you can't overwrite it from longjmp.
Pretty much certainly so; there is no separate "non-PIC ABI". PIC code
is just code that doesn't happen to do certain things not permissible
in PIC. It doesn't have additional permissions to do things that
otherwise wouldn't be permitted in "non-PIC code".
In any case just saving and restoring both is not an ABI change, since
there's plenty of free space (896 bits worth of non-existant signals)
in the jmp_buf due to the "Hurd sigset_t" mess.
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.
