From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24458 invoked by alias); 19 Dec 2014 14:10:12 -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 24440 invoked by uid 89); 19 Dec 2014 14:10:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 19 Dec 2014 14:10:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBJE9tQS019766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Dec 2014 09:09:55 -0500 Received: from pike.twiddle.home (vpn-48-156.rdu2.redhat.com [10.10.48.156]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBJE9sKk015096; Fri, 19 Dec 2014 09:09:54 -0500 Message-ID: <549431B0.10806@redhat.com> Date: Fri, 19 Dec 2014 14:10:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ulrich Weigand CC: libffi-discuss@sourceware.org, Ulrich Weigand , Andreas Krebbel Subject: Re: [PATCH] Go closures for s390[x] References: <201412191313.sBJDDb77031594@d03av02.boulder.ibm.com> In-Reply-To: <201412191313.sBJDDb77031594@d03av02.boulder.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00271.txt.bz2 On 12/19/2014 07:13 AM, Ulrich Weigand wrote: > 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. Ah, good point. That's the sort of verbage that should be in the comment then. Is that optimization really worth it? Is there no call/return prediction stack to get confused? I know I replicated it in the code that I wrote, but really only now do I start to question it. r~