[OE-core] [PATCH] valgrind: update to 3.11.0

[Khem Raj]

> On Dec 15, 2015, at 7:11 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> On Tue, Dec 15, 2015 at 5:50 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> 
>>> On Dec 15, 2015, at 2:27 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
>>> 
>>> On Tue, Dec 15, 2015 at 12:43 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>> 
>>>>> On Dec 15, 2015, at 12:16 PM, Paul Eggleton <paul.eggleton at linux.intel.com> wrote:
>>>>> 
>>>>> On Tue, 15 Dec 2015 12:07:48 Andre McCurdy wrote:
>>>>>> On Tue, Dec 15, 2015 at 9:26 AM, Paul Eggleton
>>>>>> 
>>>>>> <paul.eggleton at linux.intel.com> wrote:
>>>>>>> On Tue, 15 Dec 2015 17:28:59 Alexander Kanavin wrote:
>>>>>>>> On 12/15/2015 05:25 PM, Martin Jansa wrote:
>>>>>>>>>> +COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
>>>>>>>>>> +COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>>>>>>>> 
>>>>>>>>> Can you add armv7ve as well?
>>>>>>>> 
>>>>>>>> Armv7ve support is not yet in master, so you'll have to add it later I'm
>>>>>>>> afraid.
>>>>>>> 
>>>>>>> I think by policy we don't have any restrictions on architecture-specific
>>>>>>> flags in OE-Core (at least, assuming they're reasonable).
>>>>>> 
>>>>>> If we're going to duplicate all _armv7a over-rides for _armv7ve then
>>>>>> I'd vote to do so in a single patch series which fixes up the whole of
>>>>>> oe-core rather than adding the over-rides one at a time amongst
>>>>>> version updates etc.
>>>>> 
>>>>> Makes sense, but before doing that would it make sense to have a grouping
>>>>> override for all of them that can be used instead (where appropriate)?
>>>>> 
>>>> 
>>>> stepping back a step. What so different about armv7ve that it needs to be a separate arch
>>>> its just virtual extensions on top of armv7a, so any override pertaining to armv7a should
>>>> be valid for it well. Can you work towards making it so ?
>>> 
>>> Trying to create a common over-ride for both might end up causing more
>>> trouble in the long run.
>> 
>> what problem do you foresee.?
> 
> Just the potential for confusion really. Also wondering what will
> happen if/when people start to seriously use armv7r and armv7m. Should
> they also try to share an over-ride with armv7a ?

‘r' and ‘m’ are different at ISA level not the case with ‘ve'

> 
>>> Perhaps it would instead make sense just to
>>> try to remove some the _armv7a over-rides currently used in oe-core
>>> (and meta-oe)? There aren't that many and some of them look a little
>>> dubious or at least out of date and in need of a review.
>>> 
>>> For example for valgrind, we could blacklist armv4, armv5 and armv6
>>> rather than whitelisting armv7a. The pixman recipe is assuming armv7a
>>> is a reliable way to determine NEON support, which it isn't. The libav
>>> recipes are using _armv7a to force some dubious looking optimisations.
>>> Forcing the bfd linker in DirectFB doesn't need to be architecture
>>> specific, etc. The only genuinely valid looking usage of the armv7a
>>> over-ride seems to be gcc-configure-common.
>> 
>> This patch here https://www.sourceware.org/ml/binutils/2013-11/msg00103.html
>> tells me that armv7e should really be triggering on armv7a as well for all purposes
>> 
>>> 
>>>>> Cheers,
>>>>> Paul
>>>>> 
>>>>> --
>>>>> 
>>>>> Paul Eggleton
>>>>> Intel Open Source Technology Centre
>>>>> --
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core at lists.openembedded.org
>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151215/5da12dc6/attachment.sig>