From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9830 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:10:44 -0500 Message-ID: <20160403171044.GA11491@gordon.members.linode.com> 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> 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 1459703462 28533 80.91.229.3 (3 Apr 2016 17:11:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Apr 2016 17:11:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9843-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 03 19:11:01 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 1amlYC-0000vJ-G6 for gllmg-musl@m.gmane.org; Sun, 03 Apr 2016 19:11:00 +0200 Original-Received: (qmail 24233 invoked by uid 550); 3 Apr 2016 17:10:56 -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 24215 invoked from network); 3 Apr 2016 17:10:56 -0000 Content-Disposition: inline In-Reply-To: <20160403020946.GE21636@brightrain.aerifal.cx> X-Operating-System: Linux gordon 3.18.1-gentoo User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9830 Archived-At: On Sat, Apr 02, 2016 at 10:09:47PM -0400, Rich Felker wrote: > > > > > > diff --git a/src/signal/powerpc64/sigsetjmp.s b/src/signal/powerpc64/sigsetjmp.s > > > > > > new file mode 100644 > > > > > > index 0000000..ce59b60 > > > > > > --- /dev/null > > > > > > +++ b/src/signal/powerpc64/sigsetjmp.s > > > > > > @@ -0,0 +1,30 @@ > > > > > > + .global sigsetjmp > > > > > > + .global __sigsetjmp > > > > > > + .type sigsetjmp,%function > > > > > > + .type __sigsetjmp,%function > > > > > > + .hidden ___setjmp > > > > > > +sigsetjmp: > > > > > > +__sigsetjmp: > > > > > > + addis 2, 12, .TOC.-__sigsetjmp@ha > > > > > > + addi 2, 2, .TOC.-__sigsetjmp@l > > > > > > + .localentry sigsetjmp,.-sigsetjmp > > > > > > + .localentry __sigsetjmp,.-__sigsetjmp > > > > > > > > > > Again I don't see what the purpose of these insns is; if the resulting > > > > > value is needed, are you aware of how that interacts with ___setjmp > > > > > returning twice? > > > > > > > > This sets up r2 with the TOC pointer, as is required by the ABI in order > > > > to call setjmp's local entry point. Since setjmp is also written in asm, > > > > we could do away with this here. > > > > > > > > I don't think the fact that setjmp returns twice matters for this. > > > > > > When setjmp returns the second time, all registers it did not save > > > have been clobbered (by arbitrary code that ran after the first return > > > from setjmp). However despite not being a call-saved register > > > (AFAICT), r2 is saved by setjmp, so it's probably okay. > > > > 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. > second return, it would load junk into r2. Does longjmp have to do > something special (its own store to this stack slot, matching what a > PLT thunk would do) so that the caller loads the correct value? > > Rich