From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6969 invoked by alias); 19 Dec 2014 13:13:48 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 6960 invoked by uid 89); 19 Dec 2014 13:13:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e32.co.us.ibm.com Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 19 Dec 2014 13:13:46 +0000 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Dec 2014 06:13:43 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 Dec 2014 06:13:41 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 1313019D801C for ; Fri, 19 Dec 2014 06:02:20 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sBJDEIGC47972600 for ; Fri, 19 Dec 2014 06:14:18 -0700 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sBJDDelr031763 for ; Fri, 19 Dec 2014 06:13:40 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id sBJDDb77031594; Fri, 19 Dec 2014 06:13:37 -0700 Message-Id: <201412191313.sBJDDb77031594@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 19 Dec 2014 14:13:36 +0100 Subject: Re: [PATCH] Go closures for s390[x] To: rth@redhat.com (Richard Henderson) Date: Fri, 19 Dec 2014 13:13:00 -0000 From: "Ulrich Weigand" Cc: libffi-discuss@sourceware.org, Ulrich.Weigand@de.ibm.com (Ulrich Weigand), krebbel@linux.vnet.ibm.com (Andreas Krebbel) In-Reply-To: <5493471D.4020506@redhat.com> from "Richard Henderson" at Dec 18, 2014 03:29:01 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14121913-0005-0000-0000-0000074E0A76 X-SW-Source: 2014/txt/msg00270.txt.bz2 Richard Henderson wrote: > On 12/16/2014 09:05 AM, Dominik Vogt wrote: > > lm %r6,%r15,48+24(%r11) > > + .cfi_remember_state > > + .cfi_restore 15 > > + .cfi_restore 14 > > + .cfi_restore 13 > > + .cfi_restore 12 > > + .cfi_restore 11 > > + .cfi_restore 10 > > + .cfi_restore 9 > > + .cfi_restore 8 > > + .cfi_restore 7 > > + .cfi_restore 6 > > + .cfi_def_cfa r15, 96 > > br %r4 > > + .cfi_restore_state > > + # This nopr is necessary so that the .cfi instructions between the br > > + # above and the label below get executed. See execute_cfa_program() in > > + # the Gcc source code, libgcc/unwind-dw2.c. > > + nopr > > I'm not really sure you need any of these restores, since the data is still on > the stack, unclobbered. I think you'd really only need to reset the cfa here. Ah, right. The GPRs are saved in the 96/160-byte bias area, which is not clobbered even by signal handlers. (I guess GCC could also do that same optimization when creating CFI for epilogues ...) It looks like we do need the restore of r15, though, otherwise the CFA compuation will be wrong. > The nopr seems like a red herring. I don't see why the < vs <= for > execute_cfa_program is relevant -- this is not following a call. Actually, it sort-of is; the code does: la %r14,0(%r13,%r9) # Set return address br %r7 # ... and call function i.e. sets the return address register to point to one of the return stubs and then jumps to the target function instead of calling it; so from the point of view of an unwinder, it looks like the target function was called from the instruction immediately preceding the return stub. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com