From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31769 invoked by alias); 19 Dec 2014 15:07:02 -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 31755 invoked by uid 89); 19 Dec 2014 15:07:01 -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: e39.co.us.ibm.com Received: from e39.co.us.ibm.com (HELO e39.co.us.ibm.com) (32.97.110.160) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 19 Dec 2014 15:07:00 +0000 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Dec 2014 08:06:58 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 Dec 2014 08:06:56 -0700 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 3B63D19D8040 for ; Fri, 19 Dec 2014 07:55:35 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sBJF5r0A23462038 for ; Fri, 19 Dec 2014 08:05:53 -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 sBJF6sGI005430 for ; Fri, 19 Dec 2014 08:06:56 -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 sBJF6pil005079; Fri, 19 Dec 2014 08:06:52 -0700 Message-Id: <201412191506.sBJF6pil005079@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 19 Dec 2014 16:06:48 +0100 Subject: Re: [PATCH 0/4] s390 improvements To: rth@twiddle.net (Richard Henderson) Date: Fri, 19 Dec 2014 15:07:00 -0000 From: "Ulrich Weigand" Cc: libffi-discuss@sourceware.org, Ulrich.Weigand@de.ibm.com, vogt@linux.vnet.ibm.com, krebbel@linux.vnet.ibm.com In-Reply-To: <1418938403-15836-1-git-send-email-rth@twiddle.net> from "Richard Henderson" at Dec 18, 2014 03:33:19 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: 14121915-0033-0000-0000-000003137A55 X-SW-Source: 2014/txt/msg00273.txt.bz2 Richard Henderson wrote: > This is relative to Dominik's patch from the 16th. The complete > tree can be found at > > git://github.com/rth7680/libffi.git s390 > > Mostly relevant is patch 3, which converts the s390 port to the > more modern arrangement where there's no callback into ffi_prep_args. This is a bit confusing to me. The assembler routine now does: lg %r15,120(%r2) # Set up outgoing stack without ever restoring the initial stack pointer before returning to its caller. This probably works right now since the value loaded here is determined like that: /* Pass the outgoing stack frame in the r15 save slot. */ frame->gpr_save[8] = (unsigned long)(stack - sizeof(struct call_frame)); and since "stack" was allocated via alloca and ffi_call_int does not require an argument save area when calling any of its subroutines, the stack pointer value computed here should always in fact be identical to the value %r15 already has at the above location. Using the 160 bytes below "stack" as register save area for use of the target function called by ffi_call_SYSV is also only safe if those bytes are in fact the register save area ffi_call_int provides for its caller, e.g. again if the value is already identical to %r15. (If this were any other value, we might clobber parts of ffi_call_int's stack frame that it conceivably might still access.) However, if the procedure only works if the "lg" is a nop, why is it even done? Also, the whole setup seems a bit fragile since changes to ffi_call_int might cause it to need an argument save area ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com