Re: [PATCH] Use correct ARM architecture profile for optimized ARMv6t2/v7 memchr version.

[Pavel Pisa <ppisa4lists at pikron dot com>]

Hello Richard,

On Monday 07 of July 2014 10:36:56 Richard Earnshaw wrote:
> On 06/07/14 16:30, Pavel Pisa wrote:
> > This prevents next error at link time for Cortex-R multilib option
> >
> > Conflicting architecture profiles A/R
> > .../arm-rtems4.11/bin/ld: failed to merge target
> >
> > Simple ".arch armv6t2" defines null profile and  can be used
> > probably for all targets but chosen solution is consistent
> > with attributes of other libc library objects.
> >
> > Other option is to eliminate ".arch" line altogether.
>
> No, please don't do it this way.  It will give the surprising result for
> ARMv8-a (or later) of going backwards to v6t2.
>
> You only need object file attributes to be compatible with your existing
> code.   armv6t2 will be enough for that; so why are you trying to
> overcomplicate this?
>
> R.

Thanks for reply and excuse me. I do not have enough knowledge
about all architecture combinations to be sure that all combinations
are correct. I would prepare patch with proposed unconditional change
to

  .arch armv6t2

if you prefer and are confident about that solution and you
do not want/have time to do it yourself.

I (personally) would prefer to remove arch line altogether. I have tried
that and there seems to be no problem during all RTEMS enabled multilib
GCC+NEWLIB combinations build. All objects in libray would be consistent
in flags for this case.

What is reason for .arch line? Is it possible that for some combination
of multilib options which falls into

  #if defined(_ISA_ARM_7) || defined(__ARM_ARCH_6T2__)

some instruction or operands combination is not available
and armv6t2 enables it?

I would prefer arch line removal solution even to ensure that
instructions not available for given target are not generated
(cause build failure catch by GAS) instead of runtime
undefined instruction exception.

But again, I have not enough experience to guess if removing
the line does not cause problem with some older GAS version/target
system configuration or something else.

Excuse me for troubling you, but I really do not know
what is the best practical solution and I fear to enforce
something which is different from passed switches.

Best wishes,

               Pavel