[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170802045816.GH1627@brightrain.aerifal.cx>
Date: Wed, 2 Aug 2017 00:58:16 -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 11:31:55PM -0500, Bobby Bingham wrote:
> On Tue, Aug 01, 2017 at 11:55:56PM -0400, Rich Felker wrote:
> > On Tue, Aug 01, 2017 at 07:28:45PM -0500, Bobby Bingham wrote:
> > > On Tue, Aug 01, 2017 at 07:07:59PM -0400, Rich Felker wrote:
> > > > On Tue, Aug 01, 2017 at 06:45:33PM -0400, Rich Felker wrote:
> > > > > 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.
> > > >
> > > > It might also be possible to manually create both the entry points for
> > > > setjmp, rather than letting the assembler auto-generate them, in which
> > > > case I think the choice of which value to save just depends on which
> > > > entry point was used. Thoughts?
> > >
> > > I like this idea. It's slightly more complicated than that because of
> > > the call to setjmp from sigsetjmp, but should still be ok. I'll work on
> > > a patch.
> >
> > Hmm, can you elaborate on the situation with sigsetjmp?
> >
>
> sigsetjmp calls setjmp, but I believe this will always use the intra-dso
> entry point. Same for the call siglongjmp makes to longjmp. So calls
> via sigsetjmp/siglongjmp will always be detected as local calls, even
> when the originally caller of jig*jmp is in a different dso.
>
> My plan right now is create a __setjmp_toc function which is identical
> to the normal setjmp except that the TOC pointer to save is passed in as
> another parameter. setjmp will detect which entry point is used, pull
> the TOC pointer from the right place, and call __setjmp_toc. sigsetjmp
> will be updated similarly to detect which entry point is used and to
> call __setjmp_toc directly instead of going through setjmp.
I've been thinking about it and at first thought it sounded overly
fragile and hard to understand, but now I think it makes sense and
should work. It would just involve copying r2 to a call-clobbered
argument register before loading the new value, right?
I was considering whether you could just avoid loading the TOC pointer
at all (leaving the correct value in r2 for setjmp to save), and this
might work, but I think it would make calling __sigsetjmp_tail
difficult and error-prone.
> siglongjmp is current written in C by just calling longjmp. I'm tempted
> to just add a "siglongjmp:" label in the asm for longjmp and add an
> empty powerpc64/siglongjmp.c file to suppress the default
> implementation. I want to ask if there's any reason it wouldn't be
> valid for these two functions to have the same address.
I don't see any reason to make this change (it won't make any
functional difference -- call frames and such don't matter at this
point), and at least the siglongjmp symbol would have to be weak to
respect namespace if you did it that way.
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.
