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 <lib...@danielengel.com> 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.
