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
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
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>
| ^~~~~~~~~~~~~~~~~~
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.
> >
> > > > > 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
