Patchwork [v2] valgrind: Enable valgrind for armv7

login
register
mail settings
Submitter Samuel Stirtzel
Date May 23, 2012, 12:46 p.m.
Message ID <1337777200-8672-1-git-send-email-s.stirtzel@googlemail.com>
Download mbox | patch
Permalink /patch/28421/
State New
Headers show

Comments

Samuel Stirtzel - May 23, 2012, 12:46 p.m.
Valgrind supports the armv7 architecture, this patch allows armv7 users to build and use Valgrind

This patch was run-tested on a Gumstix Overo (armv7a cortex-a8)
* The test consisted of running valgrinds memcheck (memory leakage detection),
* and callgrind (profiling) on a Qt 4 application

Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Koen Kooi - May 23, 2012, 12:53 p.m.
Op 23 mei 2012, om 14:46 heeft Samuel Stirtzel het volgende geschreven:

> Valgrind supports the armv7 architecture, this patch allows armv7 users to build and use Valgrind
> 
> This patch was run-tested on a Gumstix Overo (armv7a cortex-a8)
> * The test consisted of running valgrinds memcheck (memory leakage detection),
> * and callgrind (profiling) on a Qt 4 application
> 
> Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
> ---
> meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |    3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
> index d7c7b24..0998f72 100644
> --- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
> +++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
> @@ -23,13 +23,16 @@ SRC_URI[md5sum] = "a855fda56edf05614f099dca316d1775"
> SRC_URI[sha256sum] = "5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6"
> 
> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
> +COMPATIBLE_HOST_armv7a = 'arm.*-linux'
> 
> inherit autotools
> 
> EXTRA_OECONF = "--enable-tls"
> +EXTRA_OECONF_armv7a = "--enable-tls -host=armv7-none-linux-gnueabi"

we should already be passing --host through autotools.bbclass. Does the configure have a special check? I've seen a few projects that insist on the -none- TARGET_VENDOR for no good reason :(

> EXTRA_OEMAKE = "-w"
> PARALLEL_MAKE = ""
> 
> FILES_${PN}-dbg += "${libdir}/${PN}/*/.debug/*"
> RRECOMMENDS_${PN}_powerpc += "${TCLIBC}-dbg"
> RRECOMMENDS_${PN}_powerpc64 += "${TCLIBC}-dbg"
> +RRECOMMENDS_${PN}_armv7a += "libc6-dbg"


${TCLIBC}-dbg ?
Samuel Stirtzel - May 23, 2012, 1:03 p.m.
2012/5/23 Koen Kooi <koen@dominion.thruhere.net>:
>
> Op 23 mei 2012, om 14:46 heeft Samuel Stirtzel het volgende geschreven:
>
>> Valgrind supports the armv7 architecture, this patch allows armv7 users to build and use Valgrind
>>
>> This patch was run-tested on a Gumstix Overo (armv7a cortex-a8)
>> * The test consisted of running valgrinds memcheck (memory leakage detection),
>> * and callgrind (profiling) on a Qt 4 application
>>
>> Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
>> ---
>> meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |    3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>> index d7c7b24..0998f72 100644
>> --- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>> +++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>> @@ -23,13 +23,16 @@ SRC_URI[md5sum] = "a855fda56edf05614f099dca316d1775"
>> SRC_URI[sha256sum] = "5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6"
>>
>> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
>> +COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>
>> inherit autotools
>>
>> EXTRA_OECONF = "--enable-tls"
>> +EXTRA_OECONF_armv7a = "--enable-tls -host=armv7-none-linux-gnueabi"
>
> we should already be passing --host through autotools.bbclass. Does the configure have a special check? I've seen a few projects that insist on the -none- TARGET_VENDOR for no good reason :(

At some extend yes, the configuration checks the host, the default
string passed is "arm" but the configure.in checks for:

case "${host_cpu}" in
...
     armv7*)
	AC_MSG_RESULT([ok (${host_cpu})])
	ARCH_MAX="arm"


So if we use the default from autotools it won't work.
I've seen the arch in some examples on the net, do you prefer -host=armv7?

>
>> EXTRA_OEMAKE = "-w"
>> PARALLEL_MAKE = ""
>>
>> FILES_${PN}-dbg += "${libdir}/${PN}/*/.debug/*"
>> RRECOMMENDS_${PN}_powerpc += "${TCLIBC}-dbg"
>> RRECOMMENDS_${PN}_powerpc64 += "${TCLIBC}-dbg"
>> +RRECOMMENDS_${PN}_armv7a += "libc6-dbg"
>
>
> ${TCLIBC}-dbg ?
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Samuel Stirtzel - May 23, 2012, 1:43 p.m.
2012/5/23 Samuel Stirtzel <s.stirtzel@googlemail.com>:
> 2012/5/23 Koen Kooi <koen@dominion.thruhere.net>:
>>
>> Op 23 mei 2012, om 14:46 heeft Samuel Stirtzel het volgende geschreven:
>>
>>> Valgrind supports the armv7 architecture, this patch allows armv7 users to build and use Valgrind
>>>
>>> This patch was run-tested on a Gumstix Overo (armv7a cortex-a8)
>>> * The test consisted of running valgrinds memcheck (memory leakage detection),
>>> * and callgrind (profiling) on a Qt 4 application
>>>
>>> Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
>>> ---
>>> meta/recipes-devtools/valgrind/valgrind_3.7.0.bb |    3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>>> index d7c7b24..0998f72 100644
>>> --- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>>> +++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
>>> @@ -23,13 +23,16 @@ SRC_URI[md5sum] = "a855fda56edf05614f099dca316d1775"
>>> SRC_URI[sha256sum] = "5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6"
>>>
>>> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
>>> +COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>>
>>> inherit autotools
>>>
>>> EXTRA_OECONF = "--enable-tls"
>>> +EXTRA_OECONF_armv7a = "--enable-tls -host=armv7-none-linux-gnueabi"
>>
>> we should already be passing --host through autotools.bbclass. Does the configure have a special check? I've seen a few projects that insist on the -none- TARGET_VENDOR for no good reason :(
>
> At some extend yes, the configuration checks the host, the default
> string passed is "arm" but the configure.in checks for:
>
> case "${host_cpu}" in
> ...
>     armv7*)
>        AC_MSG_RESULT([ok (${host_cpu})])
>        ARCH_MAX="arm"
>
>
> So if we use the default from autotools it won't work.
> I've seen the arch in some examples on the net, do you prefer -host=armv7?

Seems to be a more "intelligent" check:
"checking host system type... Invalid configuration `armv7': machine
`armv7' not recognized"

>
>>
>>> EXTRA_OEMAKE = "-w"
>>> PARALLEL_MAKE = ""
>>>
>>> FILES_${PN}-dbg += "${libdir}/${PN}/*/.debug/*"
>>> RRECOMMENDS_${PN}_powerpc += "${TCLIBC}-dbg"
>>> RRECOMMENDS_${PN}_powerpc64 += "${TCLIBC}-dbg"
>>> +RRECOMMENDS_${PN}_armv7a += "libc6-dbg"
>>
>>
>> ${TCLIBC}-dbg ?

v3 coming soon, it looked odd because of angstrom.inc: ${TCLIBC} ?= "eglibc",
but it seems alright with ${TCLIBC}-dbg pointing to libc6-dbg
Khem Raj - May 29, 2012, 8:07 p.m.
> 
> At some extend yes, the configuration checks the host, the default
> string passed is "arm" but the configure.in checks for:
> 
> case "${host_cpu}" in
> ...
>      armv7*)
> 	AC_MSG_RESULT([ok (${host_cpu})])
> 	ARCH_MAX="arm"
> 

in OE we know that compiler is configured to generate code for armv7
therefore you can safely change armv7* above in configure.in to be arm*

> 
> So if we use the default from autotools it won't work.
> I've seen the arch in some examples on the net, do you prefer -host=armv7?
Samuel Stirtzel - May 30, 2012, 1:12 p.m.
2012/5/29 Khem Raj <raj.khem@gmail.com>:
>>
>> At some extend yes, the configuration checks the host, the default
>> string passed is "arm" but the configure.in checks for:
>>
>> case "${host_cpu}" in
>> ...
>>      armv7*)
>>       AC_MSG_RESULT([ok (${host_cpu})])
>>       ARCH_MAX="arm"
>>
>
> in OE we know that compiler is configured to generate code for armv7
> therefore you can safely change armv7* above in configure.in to be arm*
>

On this change I don't have a strong opinion (looks rather cosmetically).
But sure I can send a follow up patch like you suggested.
Khem Raj - May 30, 2012, 1:17 p.m.
On Wednesday, May 30, 2012, Samuel Stirtzel wrote:

> 2012/5/29 Khem Raj <raj.khem@gmail.com <javascript:;>>:
> >>
> >> At some extend yes, the configuration checks the host, the default
> >> string passed is "arm" but the configure.in checks for:
> >>
> >> case "${host_cpu}" in
> >> ...
> >>      armv7*)
> >>       AC_MSG_RESULT([ok (${host_cpu})])
> >>       ARCH_MAX="arm"
> >>
> >
> > in OE we know that compiler is configured to generate code for armv7
> > therefore you can safely change armv7* above in configure.in to be arm*
> >
>
> On this change I don't have a strong opinion (looks rather cosmetically).
> But sure I can send a follow up patch like you suggested.


It is not cosmetic if you see it also enables it for non armv7 archs

>
>
> --
> Regards
> Samuel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <javascript:;>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Samuel Stirtzel - May 30, 2012, 1:37 p.m.
2012/5/30 Khem Raj <raj.khem@gmail.com>:
>
>
> On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>
>> 2012/5/29 Khem Raj <raj.khem@gmail.com>:
>> >>
>> >> At some extend yes, the configuration checks the host, the default
>> >> string passed is "arm" but the configure.in checks for:
>> >>
>> >> case "${host_cpu}" in
>> >> ...
>> >>      armv7*)
>> >>       AC_MSG_RESULT([ok (${host_cpu})])
>> >>       ARCH_MAX="arm"
>> >>
>> >
>> > in OE we know that compiler is configured to generate code for armv7
>> > therefore you can safely change armv7* above in configure.in to be arm*
>> >
>>
>> On this change I don't have a strong opinion (looks rather cosmetically).
>> But sure I can send a follow up patch like you suggested.
>
>
> It is not cosmetic if you see it also enables it for non armv7 archs

Maybe it is a misunderstanding?
Do you also want me to change:

COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
COMPATIBLE_HOST_armv7a = 'arm.*-linux'

to: COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64||arm).*-linux'

Else it would be only a cosmetic change, because the recipe is
preventing non armv7 arch.
Or am I mistaken?
Khem Raj - May 30, 2012, 1:51 p.m.
On Wednesday, May 30, 2012, Samuel Stirtzel wrote:

> 2012/5/30 Khem Raj <raj.khem@gmail.com <javascript:;>>:
> >
> >
> > On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
> >>
> >> 2012/5/29 Khem Raj <raj.khem@gmail.com <javascript:;>>:
> >> >>
> >> >> At some extend yes, the configuration checks the host, the default
> >> >> string passed is "arm" but the configure.in checks for:
> >> >>
> >> >> case "${host_cpu}" in
> >> >> ...
> >> >>      armv7*)
> >> >>       AC_MSG_RESULT([ok (${host_cpu})])
> >> >>       ARCH_MAX="arm"
> >> >>
> >> >
> >> > in OE we know that compiler is configured to generate code for armv7
> >> > therefore you can safely change armv7* above in configure.in to be
> arm*
> >> >
> >>
> >> On this change I don't have a strong opinion (looks rather
> cosmetically).
> >> But sure I can send a follow up patch like you suggested.
> >
> >
> > It is not cosmetic if you see it also enables it for non armv7 archs
>
> Maybe it is a misunderstanding?
> Do you also want me to change:
>
> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>
> to: COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64||arm).*-linux'
>
> Else it would be only a cosmetic change, because the recipe is
> preventing non armv7 arch.
> Or am I mistaken?
>
>
Recipe and package itself are two different things I was commenting on
package itself how it's baked in OE is a different thing

>
> --
> Regards
> Samuel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <javascript:;>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Samuel Stirtzel - May 30, 2012, 2:18 p.m.
2012/5/30 Khem Raj <raj.khem@gmail.com>:
>
>
> On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>
>> 2012/5/30 Khem Raj <raj.khem@gmail.com>:
>> >
>> >
>> > On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>> >>
>> >> 2012/5/29 Khem Raj <raj.khem@gmail.com>:
>> >> >>
>> >> >> At some extend yes, the configuration checks the host, the default
>> >> >> string passed is "arm" but the configure.in checks for:
>> >> >>
>> >> >> case "${host_cpu}" in
>> >> >> ...
>> >> >>      armv7*)
>> >> >>       AC_MSG_RESULT([ok (${host_cpu})])
>> >> >>       ARCH_MAX="arm"
>> >> >>
>> >> >
>> >> > in OE we know that compiler is configured to generate code for armv7

What does this exactly mean, are non armv7 arches also running armv7 code?

>> >> > therefore you can safely change armv7* above in configure.in to be
>> >> > arm*
>> >> >
>> >>
>> >> On this change I don't have a strong opinion (looks rather
>> >> cosmetically).
>> >> But sure I can send a follow up patch like you suggested.
>> >
>> >
>> > It is not cosmetic if you see it also enables it for non armv7 archs
>>
>> Maybe it is a misunderstanding?
>> Do you also want me to change:
>>
>> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
>> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>
>> to: COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64||arm).*-linux'
>>
>> Else it would be only a cosmetic change, because the recipe is
>> preventing non armv7 arch.
>> Or am I mistaken?
>>
>
> Recipe and package itself are two different things I was commenting on
> package itself how it's baked in OE is a different thing

You want to pass configure for non armv7 arches but keep baking for
them disabled?
Sorry I don't get your point, if the machine is not armv7 compatible
then it is not compatible with valgrind.
If they are compatible there is no point in disallowing them to bake the recipe.

Yes it is a difference to enable them at recipe / package level, but
the effective use of this recipe / package restriction combination
does not appear useful (to me).
I think I just miss your point.
Khem Raj - May 30, 2012, 3:05 p.m.
On Wed, May 30, 2012 at 7:18 AM, Samuel Stirtzel
<s.stirtzel@googlemail.com> wrote:
> 2012/5/30 Khem Raj <raj.khem@gmail.com>:
>>
>>
>> On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>>
>>> 2012/5/30 Khem Raj <raj.khem@gmail.com>:
>>> >
>>> >
>>> > On Wednesday, May 30, 2012, Samuel Stirtzel wrote:
>>> >>
>>> >> 2012/5/29 Khem Raj <raj.khem@gmail.com>:
>>> >> >>
>>> >> >> At some extend yes, the configuration checks the host, the default
>>> >> >> string passed is "arm" but the configure.in checks for:
>>> >> >>
>>> >> >> case "${host_cpu}" in
>>> >> >> ...
>>> >> >>      armv7*)
>>> >> >>       AC_MSG_RESULT([ok (${host_cpu})])
>>> >> >>       ARCH_MAX="arm"
>>> >> >>
>>> >> >
>>> >> > in OE we know that compiler is configured to generate code for armv7
>
> What does this exactly mean, are non armv7 arches also running armv7 code?
>
>>> >> > therefore you can safely change armv7* above in configure.in to be
>>> >> > arm*
>>> >> >
>>> >>
>>> >> On this change I don't have a strong opinion (looks rather
>>> >> cosmetically).
>>> >> But sure I can send a follow up patch like you suggested.
>>> >
>>> >
>>> > It is not cosmetic if you see it also enables it for non armv7 archs
>>>
>>> Maybe it is a misunderstanding?
>>> Do you also want me to change:
>>>
>>> COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
>>> COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>>
>>> to: COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64||arm).*-linux'
>>>
>>> Else it would be only a cosmetic change, because the recipe is
>>> preventing non armv7 arch.
>>> Or am I mistaken?
>>>
>>
>> Recipe and package itself are two different things I was commenting on
>> package itself how it's baked in OE is a different thing
>
> You want to pass configure for non armv7 arches but keep baking for
> them disabled?
> Sorry I don't get your point, if the machine is not armv7 compatible
> then it is not compatible with valgrind.
> If they are compatible there is no point in disallowing them to bake the recipe.
>
> Yes it is a difference to enable them at recipe / package level, but
> the effective use of this recipe / package restriction combination
> does not appear useful (to me).
> I think I just miss your point.

Its fine. Dont worry

Patch

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
index d7c7b24..0998f72 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.7.0.bb
@@ -23,13 +23,16 @@  SRC_URI[md5sum] = "a855fda56edf05614f099dca316d1775"
 SRC_URI[sha256sum] = "5d62c0330f1481fe2c593249192fa68ff454c19c34343978cc9ce91aa324cbf6"
 
 COMPATIBLE_HOST = '(i.86|x86_64|powerpc|powerpc64).*-linux'
+COMPATIBLE_HOST_armv7a = 'arm.*-linux'
 
 inherit autotools
 
 EXTRA_OECONF = "--enable-tls"
+EXTRA_OECONF_armv7a = "--enable-tls -host=armv7-none-linux-gnueabi"
 EXTRA_OEMAKE = "-w"
 PARALLEL_MAKE = ""
 
 FILES_${PN}-dbg += "${libdir}/${PN}/*/.debug/*"
 RRECOMMENDS_${PN}_powerpc += "${TCLIBC}-dbg"
 RRECOMMENDS_${PN}_powerpc64 += "${TCLIBC}-dbg"
+RRECOMMENDS_${PN}_armv7a += "libc6-dbg"