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

[Andre McCurdy]

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 ?

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