From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id 515013858D1E for ; Mon, 17 Jul 2023 06:58:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 515013858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sandoe.co.uk Received: (qmail 27647 invoked from network); 17 Jul 2023 06:58:05 -0000 X-APM-Out-ID: 16895770842764 X-APM-Authkey: 257869/1(257869/1) 7 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 17 Jul 2023 06:58:05 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: [PATCH] core: Support heap-based trampolines From: Iain Sandoe In-Reply-To: <3BD4592C-0F69-4880-8702-F586070FA115@gmail.com> Date: Mon, 17 Jul 2023 07:58:04 +0100 Cc: GCC Patches , Maxim Blinov , FX Coudert , Eric Botcazou , Jeff Law , aburgess@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: <6B96AFB9-4476-4E51-8FD7-FDEC43879614@sandoe.co.uk> References: <3BD4592C-0F69-4880-8702-F586070FA115@gmail.com> To: Richard Biener X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On 17 Jul 2023, at 07:43, FX Coudert wrote: >=20 > Hi, >=20 >> Since this affects the ABI of libgcc I think we don't want that part >> to be user configurable but rather determined by >> some static list of targets that opt-in to this config. >=20 > If I do that, do the Linux maintainers want Linux in or out? Presumably that can be a target define, and can be opted in/out in = libgcc/config.host (given that the target maintainer also needs to = provide the builtins). >> 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). 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=99s= just that the mechanism for determining permissions is different). 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). >> Was there ever an attempt to provide a "generic" trampoline driven by >> a more complex descriptor? We did look at the =E2=80=9Cunused address bits=E2=80=9D mechanism that = Ada 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). Andrew Burgess did the original work he might have comments on = alternatives we tried >> (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. indeed it would. > 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. 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 :( Iain >=20 >=20 >> Otherwise I suggest to split the patch into libgcc, generic and = target parts. >=20 >=20