From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dancol.org (dancol.org [IPv6:2600:3c01:e000:3d8::1]) by sourceware.org (Postfix) with ESMTPS id 1CE19385E032 for ; Sat, 28 May 2022 15:38:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CE19385E032 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dancol.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dancol.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID: Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NYnhV3JPdcVnm1X1Kb779dcUAO9+AuVJRC5Ho0bcsTU=; b=N+ofK6bKsQSzvRdOBmy25PIZrC hQyelXleRBRnSySAfk6aod59BwQNnUSBR0jsZLtO9jnL/c0wYVb2Ihu243jB4o0n//8LApJuT0Jir xK9t8Iv3eh9Mo46UUkuZa0R9BX0okWjVieLgGK180p6upZ68sCZaKE/b6Zw9+WNHGKFfHRfZ/jzH/ UMWRBBPlrndf9i8LhTWZF6Ab8cIVfKjc82MIncSizJaMeol/eo9wh2N7RXtZO2ThQPBfJX4srzXAL RN2UJbAkQ8RvaT1zd1fwjcoNDDFA6v1g1q5rciPMXkWUmCXPPp4GN52CU1+cuT81z8XlmVTfMt+c0 cXw6Riew==; Received: from [97.104.88.154] (port=42132 helo=[192.168.86.51]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1nuyVw-00040G-A1; Sat, 28 May 2022 08:38:04 -0700 From: To: Anthony Green , "libffi-discuss" Date: Sat, 28 May 2022 11:38:01 -0400 Message-ID: <1810b5137a8.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> In-Reply-To: References: User-Agent: AquaMail/1.35.0 (build: 103500130) Subject: Re: Change in libffi behaviour -- large struct args MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2022 15:38:11 -0000 On May 28, 2022 09:40:34 Anthony Green wrote: > As has been discussed in various github PRs recently, I'd like to > change libffi's behaviour regarding large struct arguments. > > When passing a struct by value, most (all?) ABI definitions ask that > you try to fit structs up to a certain size into registers, and if > they are too large, make a copy and pass them on the stack. > Libffi's current behaviour is to fit small structs in registers, but > then if something is too large, pass it by reference, leaving it as an > exercise for the user to make their own copies. Many libffi users, > like cpython, do this special work themselves. I don't like this > because it exposes this ABI detail, the threshold for struct sizes, to > the libffi caller. Libffi should be making this copy itself. > > The struct_by_value_big.c test checks for this, and most ports fail > today Changing this behaviour won't introduce regressions for libffi > users, and eventually they will be able to remove their special > handling of large struct args. > > AG How might this change interact with, say, C++ types tagged with clang::trivial_abi? Not all types are trivially memcpy-moveable, sadly.