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

[Khem Raj]

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


> 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/d61bda75/attachment.sig>