This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 07/07/14 14:19, Pavel Pisa wrote:
> 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.

That would be my preference.

> 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?

At this level, the .arch effectively acts as an assertion for the file
that it does not contain any instructions that require a higher version
of the architecture.  If someone were to modify the code and introduce a
new instruction that required a later version of the architecture, then
this would catch that issue immediately, rather than waiting until link
time (or worse, at run time).

> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]