From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9832 Path: news.gmane.org!not-for-mail From: Bobby Bingham Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 2/2] add powerpc64 port Date: Sun, 3 Apr 2016 12:50:28 -0500 Message-ID: <20160403175028.GB3178@dora.lan> References: <1459113619-24090-1-git-send-email-koorogi@koorogi.info> <1459113619-24090-3-git-send-email-koorogi@koorogi.info> <20160327233709.GE21636@brightrain.aerifal.cx> <20160328003220.GA24176@dora.lan> <20160328021856.GG21636@brightrain.aerifal.cx> <20160402170228.GA3178@dora.lan> <20160403020946.GE21636@brightrain.aerifal.cx> <20160403171044.GA11491@gordon.members.linode.com> <20160403172631.GF21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1459705847 30733 80.91.229.3 (3 Apr 2016 17:50:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 17:50:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9845-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 03 19:50:47 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ammAe-0001Bm-8o for gllmg-musl@m.gmane.org; Sun, 03 Apr 2016 19:50:44 +0200 Original-Received: (qmail 13477 invoked by uid 550); 3 Apr 2016 17:50:42 -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 13459 invoked from network); 3 Apr 2016 17:50:41 -0000 Content-Disposition: inline In-Reply-To: <20160403172631.GF21636@brightrain.aerifal.cx> X-Operating-System: Linux dora 4.3.3 User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9832 Archived-At: On Sun, Apr 03, 2016 at 01:26:31PM -0400, Rich Felker wrote: > On Sun, Apr 03, 2016 at 12:10:44PM -0500, Bobby Bingham wrote: > > > > r2 is call-saved when calling to the local entry point, so setjmp needs > > > > to save it. > > > > > > OK, I see how this works for local calls to setjmp. But how does the > > > linker PLT magic work for setjmp? > > > > > > After the first return, the caller's stack slot where r2 was saved > > > belongs to the caller, and the compiler can clobber it. Upon the > > > > The ABI is very prescriptive about the layout of a stack frame. Each > > stack frame has several slots where callees are allowed to use part of > > their caller's frame. For example, the link register is saved to the > > caller's frame, not the callee's. > > > > For several of these slots, the ABI explicitly documents that they may > > be used as temporary storage which should be considered call-clobbered. > > For the slot used for saving the toc pointer (r2), the ABI makes no > > mention of it being available for temporary storage. It would be nice > > if it were more explicit here, but I believe the intent is that the > > compiler may not use this slot for any other purpose. > > My concern was not that the function itself could clobber it (although > I think it would be entitled to if it's no longer live, i.e. if no > code paths remain that reference its value) but that future function > calls might clobber it. However I think they all necessarily either > don't write to this slot at all, or write the same value that was > already there, so it's probably safe without longjmp having to restore > it. Yes, that's right. All function calls from a single caller will either not clobber that stack slot, or will write the same value to it. > > Rich