From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 507673858D35 for ; Mon, 18 Oct 2021 05:58:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 507673858D35 Received: by mail-wr1-x435.google.com with SMTP id r7so39190000wrc.10 for ; Sun, 17 Oct 2021 22:58:47 -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=Sy8RerTkQcTv3dPbFgHNfjp72Cd8xDSakUrS9l7lXAs=; b=rl26cF10i4m2XR+qZyi3eETe8DHhK8jkUSJXmeDpgZQFmYia6eiJ3QjBbo8uOURL8G NaAM1gKJhYsBfvVIjpBawM/r079LLQGPfrKFzP2q8iU0Q1W//gzPH6FnyIsc2qA9zNzU hYPbFKk2K0xTSMCPHDET1PskNq2XRgTwFLjdMLddIuavR5NO5SflI6TvfyVGk3fvnFdU 7mFUgcEolkmuE8tuE1SCY3Qzlz52zlNPLvpvxOaC4IlePo2xAtV6yxF1Xq9DRhLFGdru EJUkzcCVZWS+MGmyrPuC4ZqI6c0jyi73Qg+iklo/e1kOeP+F3mj3eStTCqQOs+4p8zS6 d13w== X-Gm-Message-State: AOAM531hUowx1z/fb9XyDk8GR+SyAY0Ks0UnhyZhbCMzKgicLZRKThg6 8eHn2HaoUDv2ntBm0YlvhVU= X-Google-Smtp-Source: ABdhPJz3Xvv/p8EXB1tlOkXJyMEXY8a3dG1eXd6FGCVWcuQXR55yYTM2SNJKxbCYLwVi0JB8/le9HQ== X-Received: by 2002:a05:6000:2a4:: with SMTP id l4mr34322839wry.221.1634536726456; Sun, 17 Oct 2021 22:58:46 -0700 (PDT) Received: from 2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at (2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at. [2a02:8388:e205:e880:569c:680a:c69b:a1ad]) by smtp.gmail.com with ESMTPSA id x7sm11336044wrq.69.2021.10.17.22.58.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Oct 2021 22:58:46 -0700 (PDT) Message-ID: <857da973fe5bbb94a363114262b57d42b35cc1f6.camel@gmail.com> Subject: Re: wide function pointer type From: Martin Uecker To: Anthony Green Cc: libffi-discuss Date: Mon, 18 Oct 2021 07:58:45 +0200 In-Reply-To: References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.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: Mon, 18 Oct 2021 05:58:48 -0000 I would be interested to learn about ABI issues I might not be aware of. 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. If not, we might need to restrict conversion for regular functions pointers to wide pointers to only allow functions without variadic args, or define a new ABI for wide pointers, but this then partially defeats the point (on the affected architecture). Martin Am Montag, den 18.10.2021, 07:33 +0200 schrieb Martin Uecker: > Hi Anthony, > > Am Sonntag, den 17.10.2021, 19:35 -0400 schrieb Anthony Green: > > Hi Martin, > > > > I haven't read the whole proposal yet, but I'll try to this week. I > > did, however, read the first paragraph, and it says: "Trying to use > > regular function pointers for callbacks with data requires run-time > > code generation (e.g. nested functions in GCC or XL C, and closures in > > libffi [1]) but this is complex, inefficient, and problematic from a > > security point of view." > > > > This is no longer true for libffi on the important Linux platforms. > > We use static code templates that are placed in memory at a fixed, > > predetermined distance from the data they reference. There is no > > runtime code generation. Well, to be fair, perhaps it is still > > complex, but it's far more secure than before. > > > > Thanks for sharing. I'm not a language expert, but I know others here are. > > Thank you for your comments! I had to submit this to WG14 to meet > the deadline for C23. So the final version (so far) is here: > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf > > Of course, it is still possible to modify the proposal later. > > It is great to hear that libffi can create trampolines > without run-time code generation! We previously discussed > such an approach also for GCC, but nothing was implemented. > > > Martin > > > > AG > > > > On Sun, Oct 10, 2021 at 7:32 AM Martin Uecker via Libffi-discuss > > wrote: > > > > > > Hi all, > > > > > > I will propose a wide function pointer type (actually > > > a wide function type) to WG14 for C23 as a common > > > type for callbacks, closures, which now require an > > > additional void pointer argument in C APIs. This > > > is intended to be compatible with ABIs with now > > > use a static chain register. > > > > > > An early draft can be found here: > > > > > > http://wwwuser.gwdg.de/~muecker1/wide_v4.pdf > > > > > > > > > I thought you might be interested and I would love > > > to hear your feedback. > > > > > > Martin > > > > > > > > >