From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59246 invoked by alias); 25 Jul 2018 04:50:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59228 invoked by uid 89); 25 Jul 2018 04:50:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=now, HX-Greylist:Wed, protections X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jul 2018 04:50:13 +0000 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 085F73084037; Wed, 25 Jul 2018 04:50:12 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-68.rdu2.redhat.com [10.10.112.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2A3D2010CBC; Wed, 25 Jul 2018 04:50:10 +0000 (UTC) Subject: Re: [2/5] C-SKY port: Backend implementation To: Sandra Loosemore , "gcc-patches@gcc.gnu.org" Cc: Xianmiao Qu , Yunhai Shang References: <49d0a2c8-51a0-4a74-d015-0bf1c1098e38@codesourcery.com> <28cb3a6e-4594-3545-5236-c68784af6a57@codesourcery.com> <8a1b9bac-82dc-bb4f-e0a2-9a9b9cbea98a@redhat.com> <5ca2a106-d1d7-6eee-b0b8-2c5f2eb5e0a4@codesourcery.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Wed, 25 Jul 2018 04:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5ca2a106-d1d7-6eee-b0b8-2c5f2eb5e0a4@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg01456.txt.bz2 On 07/24/2018 06:17 PM, Sandra Loosemore wrote: > On 07/24/2018 03:24 PM, Jeff Law wrote: >>> >>>> Any thoughts on using the newer function descriptor bits rather than >>>> old >>>> style stack trampolines? >>> >>> Has that been committed?  I vaguely remembered discussion of a new way >>> to handle nested functions without using the trampoline interface, but I >>> couldn't find any documentation in the internals manual. >> It did.  See TARGET_CUSTOM_FUNCTION_DESCRIPTORS and the (relatively few) >> ports that define it. > > Hmmm, I completely failed to make that connection from the docs -- the > whole description of that hook is pretty gibberishy and I thought it was > something for targets where the ABI already specifies some "standard > calling sequence" using descriptors (C-SKY doesn't), rather than a > generic alternative to executable trampolines.  Putting on my doc > maintainer hat briefly, I can see this needs a lot of work.  :-( Most likely :-) So many things to do, so little time. > > Anyway, is this required for new ports nowadays?  If so, I at least know > what to search for now.  At this point I couldn't say whether this would > do anything to fix the situation on ck801 targets where there simply > aren't enough spare registers available to the trampoline to both hold > the static link and do an indirect jump. It's not required, but preferred, particularly if the part has an MMU that can provide no-execute protections on pages in memory. If the target doesn't have an mmu, then it's of marginal value. The key advantage it has over the old trampoline implementation is that stacks can remain non-executable, even for Ada and nested functions. That's a big win from a security standpoint. Jeff