[meta-freescale] [PATCH v3 5/7] valgrind: add bbappend for multilib support and override memcpy/memset

[Otavio Salvador]

On Mon, Aug 24, 2015 at 12:31 AM, Zhenhua Luo <zhenhua.luo at freescale.com> wrote:
> * Add bbappend for qoriq(except e500v2) to create a symbolic link as the
>   user expects to see a /usr/bin/valgrind on 64-bit MACHINE's, ensure that
>   the link created, points to the *64-bit* valgrind. Assume that the presence
>   of the patterns: "\-64b" in ${MACHINE} and "64" in ${TARGET_ARCH}, indicate
>   the 64-bit flavour and that their absence indicates 32-bit flavour respectively.
>   Now, when both 32-bit and 64-bit flavours are available to choose from; it
>   does happen that even though ${MACHINE} is chosen to indicate the choice of
>   the 32-bit case, the 64-bit tools are built too. So, ensure that on 32-bit,
>   the link points to the 32-bit valgrind, and of-course, that on 64-bit, the
>   link points to the 64-bit valgrind.
> * Override the 32-bit implementations of memcpy(), memset() from glibc.
>   On 64-bit platforms, for 32-bit mode, the Freescale optimized implementations
>   of the glibc functions memcpy(), memset() use POWER ISA Category:64-bit
>   instructions. By design, these are not implementatble in Valgrind in 32-bit
>   mode. Therefore, we override the library versions with plain classic POWER
>   32-bit alternate versions (emitted at -O0 by GCC).
> * Add COMPATIBLE_MACHINE
>
> Signed-off-by: Ting Liu <b28495 at freescale.com>
> Signed-off-by: Zhenhua Luo <zhenhua.luo at freescale.com>


If user is debugging memory in over 32bit space it will work?

...
> +++ b/recipes-devtools/valgrind/valgrind_3.10.1.bbappend
> @@ -0,0 +1,28 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
> +
> +SRC_URI_append_qoriq-ppc = " \
> +    file://override-32-bit-glibc-memcpy-memset.patch \
> +"
> +EXTRA_OECONF_append_qoriq-ppc = " --program-prefix=${TARGET_ARCH}-"
> +
> +do_install_append_qoriq-ppc() {
> +    # Create a symbolic link as the user expects to see a /usr/bin/valgrind
> +    # On 64-bit MACHINE's, ensure that the link created, points to the *64-bit*
> +    # valgrind. Assume that the presence of the patterns: "\-64b" in ${MACHINE}
> +    # and "64" in ${TARGET_ARCH}, indicate the 64-bit flavour and that their
> +    # absence indicates 32-bit flavour respectively. Now, when both 32-bit and
> +    # 64-bit flavours are available to choose from; it does happen that even
> +    # though ${MACHINE} is chosen to indicate the choice of the 32-bit case, the
> +    # 64-bit tools are built too. So, ensure that on 32-bit, the link points
> +    # to the 32-bit valgrind, and of-course, that on 64-bit, the link points
> +    # to the 64-bit valgrind.
> +    if (!(echo "${MACHINE}"     | grep --quiet "\-64b") && # 32-bit
> +        !(echo "${TARGET_ARCH}" | grep --quiet "64")) ||
> +         (echo "${MACHINE}"     | grep --quiet "\-64b"  && # 64-bit
> +          echo "${TARGET_ARCH}" | grep --quiet "64"); then
> +        cd ${D}/${bindir}
> +        ln -sf ${TARGET_ARCH}-valgrind valgrind
> +    fi
> +}

I understand the need for this but I think a better way to do is:

 - use program-prefix always
 - use update-alternatives to maintain the link

This can be done upstream.

> +COMPATIBLE_MACHINE = "(e500mc|e5500|e5500-64b|e6500|e6500-64b)"

This breaks build of valgrind for all other machines.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750