This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] Use correct ARM architecture profile for optimized ARMv6t2/v7 memchr version.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Pavel Pisa <ppisa4lists at pikron dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>, "nickc at redhat dot com" <nickc at redhat dot com>, Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Date: Mon, 07 Jul 2014 14:27:40 +0100
- Subject: Re: [PATCH] Use correct ARM architecture profile for optimized ARMv6t2/v7 memchr version.
- Authentication-results: sourceware.org; auth=none
- References: <201407030216 dot 43438 dot ppisa4lists at pikron dot com> <201407061730 dot 35574 dot ppisa4lists at pikron dot com> <53BA5C28 dot 5060501 at arm dot com> <201407071519 dot 01065 dot ppisa4lists at pikron dot com>
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?
> 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
> .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,