On Fri, 15 Jan 2021 at 12:39, Daniel Engel <lib...@danielengel.com> wrote: > > Hi Christophe, > > On Mon, Jan 11, 2021, at 8:39 AM, Christophe Lyon wrote: > > On Mon, 11 Jan 2021 at 17:18, Daniel Engel <lib...@danielengel.com> wrote: > > > > > > On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote: > > > > On Sat, 9 Jan 2021 at 14:09, Christophe Lyon > > > > <christophe.l...@linaro.org> 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. > > > > > > > > > > > > > So, that's because the code goes to the .text section (as opposed to > > > > .text.noread) > > > > and does not have the PURECODE flag. The compiler takes care of this > > > > when generating code with -mpure-code. > > > > And the simulator does not complain because it only checks loads from > > > > the segment with the PURECODE flag set. > > > > > > > This is far out of my depth, but can something like: > > > > > > ifeq (,$(findstring __symbian__,$(shell $(gcc_compile_bare) -dM -E - > > > </dev/null))) > > > > > > be adapted to: > > > > > > a) detect the state of the -mpure-code switch, and > > > b) pass that flag to the preprocessor? > > > > > > If so, I can probably fix both the target section and the data usage. > > > Just have to add a few instructions to finish unrolling the loop. > > > > I must confess I never checked libgcc's Makefile deeply before, > > but it looks like you can probably detect whether -mpure-code is > > part of $CFLAGS. > > > > However, it might be better to write pure-code-safe code > > unconditionally because the toolchain will probably not > > be rebuilt with -mpure-code as discussed before. > > Or that could mean adding a -mpure-code multilib.... > > I have learned a few things since the last update. I think I know how > to get -mpure-code out of CFLAGS and into a macro. However, I have hit > something of a wall with testing. I can't seem to compile any flavor of > libgcc with CFLAGS_FOR_TARGET="-mpure-code". > > 1. Configuring --with-multilib-list=rmprofile results in build failure: > > checking for suffix of object files... configure: error: in > `/home/mirdan/gcc-obj/arm-none-eabi/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details > > cc1: error: -mpure-code only supports non-pic code on M-profile targets >
Yes, I did hit that wall too :-) Hence what we discussed earlier: the toolchain is not rebuilt with -mpure-code. Note that there are problems in newlib too, but users of -mpure-code seem to be able to work around that (eg. using their own startup code and no stdlib) > 2. Attempting to filter the multib list results in configuration error. > This might have been misguided, but it was something I tried: > > Error: --with-multilib-list=armv6s-m not supported. > > Error: --with-multilib-list=mthumb/march=armv6s-m/mfloat-abi=soft not > supported I think only 2 values are supported: aprofile and rmprofile. > 3. Attempting to configure a single architecture results in a build error. > > --with-mode=thumb --with-arch=armv6s-m --with-float=soft > > checking for suffix of object files... configure: error: in > `/home/mirdan/gcc-obj/arm-none-eabi/arm/autofp/v5te/fpu/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details > > conftest.c:9:10: fatal error: ac_nonexistent.h: No such file or directory > 9 | #include <ac_nonexistent.h> > | ^~~~~~~~~~~~~~~~~~ I never saw that error message, but I never build using --with-arch. I do use --with-cpu though. > This has me wondering whether pure-code in libgcc is a real issue ... > If there's a way to build libgcc with -mpure-code, please enlighten me. I haven't done so yet. Maybe building the toolchain --with-cpu=cortex-m0 works? Thanks, Christophe > > > > > > 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. > > > > > > > > > > --snip -- > > > > > > > > > > > Thanks, > Daniel
