From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 3AF373858D39 for ; Tue, 19 Oct 2021 09:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3AF373858D39 Received: by mail-wr1-x432.google.com with SMTP id o20so46714580wro.3 for ; Tue, 19 Oct 2021 02:43:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ZRFxekgzwdy14w//QelpgCGlE/LoX8oRPI+bbW1MWlc=; b=aGM47hTTc+0VfcRE1lUB7o0sl5iop2h0z6mbwt1KdDT27cQeyUqvM/gszhBeoigCXs U9oc1EkQA/3EWCd1d8M62kR3sfxS+dqlJLG0tsm8APjCWs6eWf1CU8J769CT5yOP6LVi qvUJYg/J1loCCFPwuPlYDJ+4KF1BKSHWkybRsojGYZCVNOqhtG1zbM7Cs6uzk2QIDeRh 803FirH17dDD3nRmld6U+Vrxg0QHD7mV7lDblyDxNqJDIG0huNDCJe1kVuJQz2I8vCkk Bj8M3YXXawZW1q5W3VziKE4tJEJjamFLhso9avBgJJVdi60zZrNHTVKVIFJKUmrYKKw9 VJdg== X-Gm-Message-State: AOAM531vPwg/D2ApiTkOiYU4oS3vSBa0NcSjjP31SvreBY1IegCFz9KZ 6ppLrYok38z601JMI2+cJlQ= X-Google-Smtp-Source: ABdhPJzp+rxSUeZEW1eJ5MWFebOeUfg+0uB6rSCMAemMcRbG80N7TaiWr/JdwXP+XMv+TgMkoc7U8g== X-Received: by 2002:a05:6000:1541:: with SMTP id 1mr41493775wry.273.1634636634288; Tue, 19 Oct 2021 02:43:54 -0700 (PDT) Received: from nt-f071.wlcli.tugraz.at (nt-f071.wlcli.tugraz.at. [129.27.245.71]) by smtp.gmail.com with ESMTPSA id n66sm1770338wmn.2.2021.10.19.02.43.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 02:43:53 -0700 (PDT) Message-ID: <6a0299e6b3c47cddd88b24d569fca8aeb4717aeb.camel@gmail.com> Subject: Re: wide function pointer type From: Martin Uecker To: Florian Weimer Cc: Martin Uecker via Libffi-discuss , Anthony Green Date: Tue, 19 Oct 2021 11:43:52 +0200 In-Reply-To: <87bl3lgyha.fsf@oldenburg.str.redhat.com> References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.com> <857da973fe5bbb94a363114262b57d42b35cc1f6.camel@gmail.com> <87czo2hjiq.fsf@oldenburg.str.redhat.com> <8d2ddbb76479ce3ad7f99acb3f0b79a6a8d1440b.camel@gmail.com> <87bl3lgyha.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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:43:56 -0000 Am Dienstag, den 19.10.2021, 11:22 +0200 schrieb Florian Weimer: > * 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. Ok. The ones I looked at do, but I looked only at a few. > 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. Yes, but there are many other languages that make use of the static chain. So it would be good to have a standardized ABI for this. > For obvious reasons, the proposal does not achieve interoperability with > std::function from C++, so there is no ABI concern, either. Not directly, but you could automatically create a wide pointer that points to a compile-time stub that calls a std::function. Martin