From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109417 invoked by alias); 28 Sep 2017 16:13:14 -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 109138 invoked by uid 89); 28 Sep 2017 16:13:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Best X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Sep 2017 16:13:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6DC91435; Thu, 28 Sep 2017 09:13:10 -0700 (PDT) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 172B03F53D; Thu, 28 Sep 2017 09:13:09 -0700 (PDT) Subject: Re: [PATCH, GCC/ARM, ping] Remove ARMv8-M code for D17-D31 To: Kyrill Tkachov , "Richard Earnshaw (lists)" , Ramana Radhakrishnan , "gcc-patches@gcc.gnu.org" References: <5da9957f-06bc-11dd-a63a-6bf341b84486@foss.arm.com> <8248378c-d652-1f75-369f-904706f4b022@arm.com> <08072c0e-614d-0855-8040-3ccd9e417c05@foss.arm.com> <5a7866d8-e0fb-00d4-7f46-ae90f298fb07@foss.arm.com> <6753e9df-975d-b97f-b419-9283ba5aa8e9@foss.arm.com> <2b4031d6-cc6c-67e4-c372-319694df65be@foss.arm.com> <59AFADD3.10303@foss.arm.com> From: Thomas Preudhomme Message-ID: <49cae04c-8969-e720-d144-be07e1ba61b5@foss.arm.com> Date: Thu, 28 Sep 2017 16:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <59AFADD3.10303@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg01885.txt.bz2 Committed (sorry for delay). Best regards, Thomas On 06/09/17 09:12, Kyrill Tkachov wrote: > Hi Thomas, > > On 05/09/17 10:04, Thomas Preudhomme wrote: >> Ping? >> > > This is ok if a bootstrap and test run on arm-none-linux-gnueabihf shows no > problems. > Thanks, > Kyrill > >> Best regards, >> >> Thomas >> >> On 25/08/17 12:18, Thomas Preudhomme wrote: >>> Hi, >>> >>> I've now also added a couple more changes: >>> >>> * size to_clear_bitmap according to maxregno to be consistent with its use >>> * use directly TARGET_HARD_FLOAT instead of clear_vfpregs >>> >>> >>> Original message below (ChangeLog unchanged): >>> >>> Function cmse_nonsecure_entry_clear_before_return has code to deal with >>> high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do >>> not support more than 16 double VFP registers (D0-D15). This makes this >>> security-sensitive code harder to read for not much benefit since >>> libcall for cmse_nonsecure_call functions do not deal with those high >>> VFP registers anyway. >>> >>> This commit gets rid of this code for simplicity and fixes 2 issues in >>> the same function: >>> >>> - stop the first loop when reaching maxregno to avoid dealing with VFP >>> registers if targetting Thumb-1 or using -mfloat-abi=soft >>> - include maxregno in that loop >>> >>> ChangeLog entry is as follows: >>> >>> *** gcc/ChangeLog *** >>> >>> 2017-06-13 Thomas Preud'homme >>> >>> * config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security >>> Extensions with more than 16 double VFP registers. >>> (cmse_nonsecure_entry_clear_before_return): Remove second entry of >>> to_clear_mask and all code related to it. Replace the remaining >>> entry by a sbitmap and adapt code accordingly. >>> >>> Testing: Testsuite shows no regression when run for ARMv8-M Baseline and >>> ARMv8-M Mainline. >>> >>> Is this ok for trunk? >>> >>> Best regards, >>> >>> Thomas >>> >>> On 23/08/17 11:56, Thomas Preudhomme wrote: >>>> Ping? >>>> >>>> Best regards, >>>> >>>> Thomas >>>> >>>> On 17/07/17 17:25, Thomas Preudhomme wrote: >>>>> My bad, found an off-by-one error in the sizing of bitmaps. Please find >>>>> fixed patch in attachment. >>>>> >>>>> ChangeLog entry is unchanged: >>>>> >>>>> *** gcc/ChangeLog *** >>>>> >>>>> 2017-06-13 Thomas Preud'homme >>>>> >>>>> * config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security >>>>> Extensions with more than 16 double VFP registers. >>>>> (cmse_nonsecure_entry_clear_before_return): Remove second entry of >>>>> to_clear_mask and all code related to it. Replace the remaining >>>>> entry by a sbitmap and adapt code accordingly. >>>>> >>>>> Best regards, >>>>> >>>>> Thomas >>>>> >>>>> On 17/07/17 09:52, Thomas Preudhomme wrote: >>>>>> Ping? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Thomas >>>>>> >>>>>> On 12/07/17 09:59, Thomas Preudhomme wrote: >>>>>>> Hi Richard, >>>>>>> >>>>>>> On 07/07/17 15:19, Richard Earnshaw (lists) wrote: >>>>>>>> >>>>>>>> Hmm, I think that's because really this is a partial conversion. It >>>>>>>> looks like doing this properly would involve moving that existing code >>>>>>>> to use sbitmaps as well. I think doing that would be better for >>>>>>>> long-term maintenance perspectives, but I'm not going to insist that you >>>>>>>> do it now. >>>>>>> >>>>>>> There's also the assert later but I've found a way to improve it >>>>>>> slightly. While switching to auto_sbitmap I also changed the code >>>>>>> slightly to allocate directly bitmaps to the right size. Since the change >>>>>>> is probably bigger than what you had in mind I'd appreciate if you can >>>>>>> give me an OK again. See updated patch in attachment. ChangeLog entry is >>>>>>> unchanged: >>>>>>> >>>>>>> 2017-06-13 Thomas Preud'homme >>>>>>> >>>>>>> * config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security >>>>>>> Extensions with more than 16 double VFP registers. >>>>>>> (cmse_nonsecure_entry_clear_before_return): Remove second entry of >>>>>>> to_clear_mask and all code related to it. Replace the remaining >>>>>>> entry by a sbitmap and adapt code accordingly. >>>>>>> >>>>>>>> >>>>>>>> As a result I'll let you take the call as to whether you keep this >>>>>>>> version or go back to your earlier patch. If you do decide to keep this >>>>>>>> version, then see the comment below. >>>>>>> >>>>>>> Given the changes I'm more happy with how the patch looks now and making >>>>>>> it go in can be a nice incentive to change other ARMv8-M Security >>>>>>> Extension related code later on. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Thomas >