From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id BF1C13858C66 for ; Wed, 19 Jul 2023 09:04:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF1C13858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so1263016a12.0 for ; Wed, 19 Jul 2023 02:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689757476; x=1692349476; h=mime-version:user-agent:content-transfer-encoding:in-reply-to:date :cc:to:from:subject:message-id:from:to:cc:subject:date:message-id :reply-to; bh=4Pz+rjM1vyMeACAm61Lb0Hk5hxoZqGqi/SDQiCKiiRU=; b=EioQ1CPPjqu5mqPfmBVepMjaZKDe2YnRcAERMVhcyyZMZdRNQT49rldD2bsUndHPSg fTcCI7btpCtDaKUbjKOC6bYTy7JmHXjZVMCr6axoY4gGzpxwe6y7GS0KYWk7u7ZwIZBO /FKq7zCrBjDuw79+dU8ckLAg0XTx0xZdwE59ak3i4dO4l3Gh8ySRFBE8694YYTYRUvbY 6GOKKcrAJq+sQz43SeRmzaxRrcVxsIlI6cjJcTThE/kWhYjitTwVy718cpuWYS7nx6ok 6jXUXaRq6Nh2zfr1FBTtpdonl+Ii0dkb58Qt7XeB2K8X1ooawZM5AAMm3xosB/1AdMEE CWlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689757476; x=1692349476; h=mime-version:user-agent:content-transfer-encoding:in-reply-to:date :cc:to:from:subject:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=4Pz+rjM1vyMeACAm61Lb0Hk5hxoZqGqi/SDQiCKiiRU=; b=knITr9a6CVx0YoFm6xB2Q7Iskxfn9qtHV1IUP4Zb+9Pb82pc3QuMItlXYOnCIm05GC 3Dehmh915TK39dNwmiOMgIZsDoUImZlH+s4jsx2LodmTGPLeDMouIb7qSP+k3xYF7Nty khwUom93tMabSn++ccvgW0vlPkHfaSkggIw7TANECcyDJ5kPCSHWEkt179vH2SvR00tw I9GwRds/xKNPixmQYiscXm0Jn+2SUcTUFgA6vXHiustBaoNsqrJOZ15OtMG+ANe2cnW/ F4IlIIqD6lpQvlu2WpWosqlIbiYLXV80ni+WCLOG/+bz8IbEAk8IKGs5YW3xk8b29foL TbLA== X-Gm-Message-State: ABy/qLaqPM7d+zs3nCj3ycvVlUXT56rY2KKxtOOXlnyGNkQYpTTCjHMm U6ZqMJ06QeT7hjkzxqoosgAngNJD4wIong== X-Google-Smtp-Source: APBJJlGEiCghe8Gud8tF8baaq1yV86hrsYio2f41TfPOOmw1V2fGOdwCB8ytUvdyFtIuUFArjwCX2w== X-Received: by 2002:a05:6402:3551:b0:51e:85d7:2c79 with SMTP id f17-20020a056402355100b0051e85d72c79mr1768417edd.7.1689757476085; Wed, 19 Jul 2023 02:04:36 -0700 (PDT) Received: from thinkpad-2.fritz.box ([2a02:810d:acbf:c050:8e97:5915:746b:2720]) by smtp.gmail.com with ESMTPSA id d19-20020aa7d693000000b0051e229d04fcsm2473527edr.70.2023.07.19.02.04.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 02:04:35 -0700 (PDT) Message-ID: Subject: Re: [PATCH] core: Support heap-based trampolines From: Martin Uecker To: gcc-patches@gcc.gnu.org Cc: iain@sandoe.co.uk Date: Wed, 19 Jul 2023 11:04:35 +0200 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 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,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 List-Id: >=20 > > On 17 Jul 2023,=20 >=20 > >> You mention setjmp/longjmp - on darwin and other platforms > requiring > >> non-stack based trampolines > >> does the system runtime provide means to deal with this issue like > an > >> alternate allocation method > >> or a way to register cleanup? > >=20 > > There is an alternate mechanism relying on system libraries that is > possible on darwin specifically (I don=E2=80=99t know for other targets) = but > it will only work for signed binaries, and would require us to > codesign everything produced by gcc. During development, it was > deemed too big an ask and the current strategy was chosen (Iain can > surely add more background on that if needed). >=20 > I do not think that this solves the setjump/longjump issue - since > there=E2=80=99s still a notional allocation that takes place (it=E2=80=99= s just that > the mechanism for determining permissions is different). >=20 > It is also a big barrier for the general user - and prevents normal > folks from distributing GCC - since codesigning requires an external > certificate (i.e. I would really rather avoid it). >=20 > >> Was there ever an attempt to provide a "generic" trampoline driven > by > >> a more complex descriptor? >=20 > We did look at the =E2=80=9Cunused address bits=E2=80=9D mechanism that A= da has used > - but that is not really available to a non-private ABI (unless the > system vendor agrees to change ABI to leave a bit spare) for the base > arch either the bits are not there (e.g. X86) or reserved (e.g. > AArch64). >=20 > Andrew Burgess did the original work he might have comments on > alternatives we tried >=20 For reference, I proposed a patch for this in 2018. It was not accepted because minimum alignment for functions would increase for some archs: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html > >> (well, it could be a bytecode interpreter and the trampoline being > >> bytecode on the stack?!) > >=20 > > My own opinion is that executable stack should go away on all > targets at some point, so a truly generic solution to the problem > would be great. >=20 > indeed it would. >=20 I think we need a solution rather sooner than later on all archs. Martin > > Having something that works reliably across all targets, like you > suggest, is a much bigger project that this patch, and I am not aware > of any previous attempt at it. >=20 > The bytecode interpreter idea is neat; (a) I wonder about > performance and (b) it is, as FX says, a bigger project - certainly > bigger than the voluntary Darwin time available :( >=20 > Iain >=20 > >=20 > >=20 > >> Otherwise I suggest to split the patch into libgcc, generic and > target parts. > >=20 > >=20 >=20