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

[Luo Zhenhua]

> -----Original Message-----
> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
> Sent: Thursday, August 27, 2015 9:46 PM
> To: Luo Zhenhua-B19537 <zhenhua.luo at freescale.com>
> Cc: meta-freescale at yoctoproject.org
> Subject: Re: [meta-freescale] [PATCH v3 5/7] valgrind: add bbappend for
> multilib support and override memcpy/memset
> 
> 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?
[Luo Zhenhua-B19537] currently no issue is reported for the implementation, 

> > +++ 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.
[Luo Zhenhua-B19537] I tried to utilize update-alternatives bbclass, the following syntax is not supported by update-alternatives. 
	ALTERNATIVE_${PN} = "valgrind-${TARGET_ARCH}"
	ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"

	ERROR: ParseError at ./poky/meta/recipes-devtools/valgrind/valgrind_3.10.0.bb:102: unparsed line: 'ALTERNATIVE_LINK_NAME[valgrind-${TARGET_ARCH}] = "valgrind"'

> > +COMPATIBLE_MACHINE = "(e500mc|e5500|e5500-64b|e6500|e6500-64b)"
> 
> This breaks build of valgrind for all other machines.
[Luo Zhenhua-B19537] You are right,  I will drop this line in new version. 


Best Regards,

Zhenhua

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