From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 9E9783858D39 for ; Tue, 19 Oct 2021 09:23:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E9783858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-393-gPAzXMQgMiyI1T4DOQjfZQ-1; Tue, 19 Oct 2021 05:23:01 -0400 X-MC-Unique: gPAzXMQgMiyI1T4DOQjfZQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BD2209F92D; Tue, 19 Oct 2021 09:23:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6767860BF1; Tue, 19 Oct 2021 09:22:59 +0000 (UTC) From: Florian Weimer To: Martin Uecker Cc: Martin Uecker via Libffi-discuss , Anthony Green Subject: Re: wide function pointer type References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.com> <857da973fe5bbb94a363114262b57d42b35cc1f6.camel@gmail.com> <87czo2hjiq.fsf@oldenburg.str.redhat.com> <8d2ddbb76479ce3ad7f99acb3f0b79a6a8d1440b.camel@gmail.com> Date: Tue, 19 Oct 2021 11:22:57 +0200 In-Reply-To: <8d2ddbb76479ce3ad7f99acb3f0b79a6a8d1440b.camel@gmail.com> (Martin Uecker's message of "Mon, 18 Oct 2021 09:56:14 +0200") Message-ID: <87bl3lgyha.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Tue, 19 Oct 2021 09:23:06 -0000 * Martin Uecker: > Am Montag, den 18.10.2021, 09:36 +0200 schrieb Florian Weimer: >> * Martin Uecker via Libffi-discuss: >> >> > In particular, I would be good to know whether >> > implementing a perfectly forwarding stub for >> > a variadic functions that loads the static >> > is possible on all architectures. I assume so, >> > but I am not entirely sure. >> >> Are you asking if it is possible to consume an argument in a variadic >> wrapper and forward the remaining arguments to a variadic function? The >> answer to that is no. > > Yes, I assumed this does not work. The question > is more whether architectures exist where the > existing ABI states that the static chain has to be > passed as a first argument (which would then need to be > removed when calling a regular function). > > The implementation most architectures > would use is that 1) the static chain is loaded from > the wide pointer 2) stored in the designated register > or stack slot and then 3) a call is performed > using the same calling convention as used for > regular functions. Many ABIs do not actually specify a register for the chain pointer. For GCC's nested function extension, there are no ABI concerns because the nested function definition and the thunk generation are always built from the same translation unit. So GCC can just pick a custom calling convention, similar to what it does for other local, non-escaping functions. For obvious reasons, the proposal does not achieve interoperability with std::function from C++, so there is no ABI concern, either. Thanks, Florian