From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11773 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: possible bug in setjmp implementation for ppc64 Date: Tue, 1 Aug 2017 18:45:33 -0400 Message-ID: <20170801224533.GD1627@brightrain.aerifal.cx> References: <1501520360.0.593167188853569@go.bunnymail.go> <20170731203007.GB1627@brightrain.aerifal.cx> <20170801051042.GA14914@dora.lan> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1501627549 25103 195.159.176.226 (1 Aug 2017 22:45:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2017 22:45:49 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11786-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 02 00:45:45 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dcfv5-0006Fz-NU for gllmg-musl@m.gmane.org; Wed, 02 Aug 2017 00:45:44 +0200 Original-Received: (qmail 7738 invoked by uid 550); 1 Aug 2017 22:45:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7717 invoked from network); 1 Aug 2017 22:45:45 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11773 Archived-At: 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