From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 924B73857439 for ; Fri, 11 Jun 2021 19:09:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 924B73857439 Received: by mail-wr1-x42f.google.com with SMTP id r9so7108526wrz.10 for ; Fri, 11 Jun 2021 12:09:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:user-agent :mime-version:content-transfer-encoding; bh=61eZQ9OsuJnU6ebGeSDapI7ye65tJn82JnemdVZlbv4=; b=uY6uN8NM0cwFDm2qtJzI6wxeFHsXU5h6v+7VIHymjVck/0kMV2hiSwGg/jdQzrMcJg bk5EvSoillXyfIC3dy3zIpICFckTdVSP2GNApt+bSZtz+DtMBdWlvyGkQYOxpKaTOUKf YA+KM7aaWON9RKiV5KQ+Ng5bmqZ8hWg5t/PlYrVAfo4d34D2Wel2pBs7Gb4CmTTgkUzt eW7wq0BCfx/j1v4y5r649gJeb+vpP1eOUlsWIStMCoglQyB9e1qWOdcbYNhMQsOX6L6o MVDoGTuofZFbOX219d/9ajXd7U5M1CEY3/kpxeKF6WPhqz+aU9W2futXnDbRM5zb6XVZ zu2w== X-Gm-Message-State: AOAM5315j7IITN63AMPxX6Ihiw3xyh7nBFn3iOyM2I40bkTpU03Utm4i XMabhIxeCAoF5O90Z8julh0= X-Google-Smtp-Source: ABdhPJww5jXHqLdsVdcmEfxCrnWs9lsRBzr5ll2eI9r2z+4k2QNFdwsrRCMXswhtDzjT/svCMJQr/A== X-Received: by 2002:a5d:4d4d:: with SMTP id a13mr5773828wru.33.1623438581456; Fri, 11 Jun 2021 12:09:41 -0700 (PDT) Received: from p200300cf07447c35c129da89ed8951f5.dip0.t-ipconnect.de (p200300cf07447c35c129da89ed8951f5.dip0.t-ipconnect.de. [2003:cf:744:7c35:c129:da89:ed89:51f5]) by smtp.gmail.com with ESMTPSA id t1sm7781260wrx.28.2021.06.11.12.09.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 12:09:40 -0700 (PDT) Message-ID: <53d08cb4d231e5cc3ba2f7254df271094796af4d.camel@gmail.com> Subject: Re: [PATCH] Document that -fno-trampolines is for Ada only [PR100735] From: Martin Uecker To: idsandoe@googlemail.com Cc: jeffreyalaw@gmail.com, "gcc-patches@gcc.gnu.org" Date: Fri, 11 Jun 2021 21:09:39 +0200 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 19:09:44 -0000 > > Jeff et. al. > > > On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches wrote: > > On 5/25/2021 2:23 PM, Paul Eggert wrote: > >> The GCC manual's documentation of -fno-trampolines was apparently > >> written from an Ada point of view. However, when I read it I > >> understandably mistook it to say that -fno-trampolines also works for > >> C, C++, etc. It doesn't: it is silently ignored for these languages, > >> and I assume for any language other than Ada. > >> > >> This confusion caused me to go in the wrong direction in a Gnulib > >> dicussion, as I mistakenly thought that entire C apps with nested > >> functions could be compiled with -fno-trampolines and then use nested > >> C functions in stack overflow handlers where the alternate stack > >> is allocated via malloc. I was wrong, as this won't work on common > >> platforms like x86-64 where malloc yields non-executable storage. > >> > >> gcc/ > >> * doc/invoke.texi (Code Gen Options): > >> * doc/tm.texi.in (Trampolines): > >> Document that -fno-trampolines and -ftrampolines work > >> only with Ada. > > So Martin Uecker probably has the most state on this. IIRC when we last discussed -fno- > trampolines the belief was that it could be easily made to work independent of the language, but > that it was ultimately an ABI change. That ultimately derailed plans to use -fno-trampolines for > other languages in the immediate term. > > This is correct, it’s not technically too hard to make it work for another language (I have a hack > in my arm64-darwin branch that does this for gfortran). As noted for most ports it is an ABI > break and thus not usable outside a such a work-around. > > For the record (for the arm64-darwin port in the first instance), together with some of my friends > at embecosm we plan to implement a solution to the trampoline that does not require executable > stack and does not require an ABI break. Perhaps such a solution will be of interest to other > ports that do not want executable stack. > > We’re not quite ready to post the design yet - but will do so in the next few weeks (all being > well). > For reference the discussion and PATCH for C can be found here: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html FWIW: There is a proposal discussed in WG14 to add lambdas. In this context a more general and portable solution to this problem would also be useful. One related idea is to add a wider function pointer type to C that includes a data pointer. A regular function pointer could be converted to the wider pointer but back conversion only works if it originally was a regular function pointer. This pointer type could then also be used for interoperablity with other languages that have callable objects or closures. If GCC could add something like this and there is then implementation experience, we could later try to standardize it. (there was also positive feedback to this idea from some C++ people I spoke to) Martin