From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 6191B3858001 for ; Mon, 11 Jan 2021 14:49:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6191B3858001 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 05B2B1042; Mon, 11 Jan 2021 06:49:38 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3D09D3F70D; Mon, 11 Jan 2021 06:49:37 -0800 (PST) Subject: Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0 To: Daniel Engel , Christophe Lyon Cc: gcc Patches References: <3b36bc72-e92e-4372-8da4-43ade34d868b@www.fastmail.com> <962a0e7d-f431-42ee-aa42-e4e4cc823a10@www.fastmail.com> <35908b07-8822-e415-2abc-e04b8c9a692d@foss.arm.com> <7e0f7bb7-c2c4-4c77-8dc2-5f5c20a7bcec@www.fastmail.com> <3ba1767e-26f3-96d2-e5c7-987ca0a10f1d@foss.arm.com> <17c601ba-60e4-446c-b7b4-b1674d8500e5@www.fastmail.com> <9d670702-2520-4f50-8113-98883ca4b7a0@www.fastmail.com> From: Richard Earnshaw Message-ID: Date: Mon, 11 Jan 2021 14:49:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9d670702-2520-4f50-8113-98883ca4b7a0@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 14:49:39 -0000 On 09/01/2021 18:04, Daniel Engel wrote: > On Sat, Jan 9, 2021, at 5:09 AM, Christophe Lyon wrote: >> On Sat, 9 Jan 2021 at 13:27, Daniel Engel wrote: >>> >>> On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote: >>>> On 07/01/2021 00:59, Daniel Engel wrote: >>>>> --snip-- >>>>> >>>>> On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote: >>>>> >>>>>> -- snip -- >>>>>> >>>>>> - finally, your popcount implementations have data in the code segment. >>>>>> That's going to cause problems when we have compilation options such as >>>>>> -mpure-code. >>>>> >>>>> I am just following the precedent of existing lib1funcs (e.g. __clz2si). >>>>> If this matters, you'll need to point in the right direction for the >>>>> fix. I'm not sure it does matter, since these functions are PIC anyway. >>>> >>>> That might be a bug in the clz implementations - Christophe: Any thoughts? >>> >>> __clzsi2() has test coverage in "gcc.c-torture/execute/builtin-bitops-1.c" >> Thanks, I'll have a closer look at why I didn't see problems. >> >>> The 'clzs' and 'ctz' functions should never have problems. -mpure-code >>> appears to be valid only when the 'movt' instruction is available, which >>> means that the 'clz' instruction will also be available, so no array loads. >> No, -mpure-code is also supported with v6m. >> >>> Is the -mpure-code state detectable as a preprocessor flag? While >> No. >> >>> 'movw'/'movt' appears to be the canonical solution, I'm not sure it >>> should be the default just because a processor supports Thumb-2. >>> >>> Do users wanting to use -mpure-code recompile the toolchain to avoid >>> constant data in compiled C functions? I don't think this is the >>> default for the typical toolchain scripts. >> No, users of -mpure-code do not recompile the toolchain. > > I won't claim that my use of inline constants is correct. It was not > hard to find references to high security model processors that block > reading from executable sections. > > However, if all of the above is true, I think libgcc as a whole > will have much bigger problems. I count over 500 other instances > in the disassembled v6m *.a file where functions load pc-relative > data from '.text'. The difference is that when the data-in-text references come from C code, they can be eliminated simply by rebuilding the library with -mpure-code on. That's difficult, if not impossible to fix when the source for a function is written in assembler. > > For example: > * C version of popcount > * __powidf2 (0x3FF00000) > * __mulsc3 (0x7F7FFFFF) > * Most soft-float functions. > > Still not seeing a clear resolution here. Is it acceptable to use the > > "ldr rD, =const" No, that's just short-hand for an LDR from a literal pool that is generated auto-magically by the assembler. I also wouldn't trust that when using any section other than .text for code, unless you add explicit .ltorg directives to state where the currently pending literals are to be dumped. > > pattern? > > Thanks, > Daniel > R.