From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 442D13858D1E for ; Mon, 17 Jul 2023 06:43:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 442D13858D1E 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-wm1-x335.google.com with SMTP id 5b1f17b1804b1-3fbe35e028aso6571215e9.0 for ; Sun, 16 Jul 2023 23:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689576198; x=1690180998; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=imPgzzTuHfxg8dxdh4mQhdHobKgAFB0FxozdB6eXRFI=; b=swzyTq/uPt7c6ky4ZLdjIbnDHHIvrONhtBGLrvXlz+wyPmztZSuC6YzRoEcbvKe0sx HUyrQDHeaB5vJ1gLvhFoIyIWPG1zyOhwopdH7SCplt4YNygbWQOk7zUcYIHrk5w4dHE/ 3+RsYI8jEGMqv9aHW9fzDp/sTZaK6zonyi/9uapDyPX0mo042lai3S1mAwVYh+D7fpSV CjkEynrjpDgEewGabkRBFiDTUUJ03fRc5kDt6CgnKbkkv3w2+MzMXPFa2Vmpf/8tHiD3 8HCnUW0iASBnu0yU6eyN/M36ePBL2IM8d41feokLlmmELXXxixLl0GINiJTO3bTRA/A2 X0cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689576198; x=1690180998; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=imPgzzTuHfxg8dxdh4mQhdHobKgAFB0FxozdB6eXRFI=; b=Rl9tFU3fz2Y33fJ8yGUt5vVZEDsx54ocBpb9fhkMdj7A+gfAcnsTeppDxwDyX40MDW osnvEL41qNZoyavNNDx0sjbQK2GIzrxz5vyRV8OPiG0CuQ1ANjWJGOCdMqnMCSJsgjGY wWVZZzq50Fft6WrJuCXBS8Wb9cAAVkz6nEZTlC2r288cRK92sEA4tOTtHqDwOD4b+Xep JVblc8LJYnCdEDUAKHhZ3XpiiAcNZsnI7C7wqIVvRbxbkVdNxENZJNFciGQ5tttFN3EG xCy6hYjwMSz56HqrOZVRTSBXRHs5wqcWfYOrjQknCmqvnjLT54hKBgTmuUxCfRuTXB4U XOPQ== X-Gm-Message-State: ABy/qLYY8sS0DKWoTuFddhgPCfh7JOlslfQ9Xz0dFrsgPhQ/nLZuEeWB xkBhrhJcnAU9y/Kn4nhhDUQ= X-Google-Smtp-Source: APBJJlHxOLBW3lh8a9Me5AElr8Pa5OCN2qq+AuD6kaWS+UaKgSfP6l3t3YsAE/bQ2EpZB5aaMh318g== X-Received: by 2002:a05:600c:3ca9:b0:3fb:dde9:1de8 with SMTP id bg41-20020a05600c3ca900b003fbdde91de8mr4837319wmb.2.1689576197966; Sun, 16 Jul 2023 23:43:17 -0700 (PDT) Received: from smtpclient.apple ([2a01:e34:ec28:8cb0:9cad:66bd:3216:a470]) by smtp.gmail.com with ESMTPSA id k8-20020a5d5188000000b00314172ba213sm18055491wrv.108.2023.07.16.23.43.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2023 23:43:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: [PATCH] core: Support heap-based trampolines From: FX Coudert In-Reply-To: Date: Mon, 17 Jul 2023 08:43:07 +0200 Cc: gcc-patches@gcc.gnu.org, Iain Sandoe , maxim.blinov@embecosm.com, ebotcazou@adacore.com, Jeff Law Content-Transfer-Encoding: quoted-printable Message-Id: <3BD4592C-0F69-4880-8702-F586070FA115@gmail.com> References: To: Richard Biener X-Mailer: Apple Mail (2.3731.600.7) 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,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: Hi, > 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. If I do that, do the Linux maintainers want Linux in or out? > 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? 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). > Was there ever an attempt to provide a "generic" trampoline driven by > a more complex descriptor? > (well, it could be a bytecode interpreter and the trampoline being > bytecode on the stack?!) 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. = 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. > Otherwise I suggest to split the patch into libgcc, generic and target = parts.