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

[Otavio Salvador]

On Fri, Aug 28, 2015 at 5:18 AM, Luo Zhenhua <zhenhua.luo at freescale.com> wrote:
>> -----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"'

So please add the patch, set package-arch accordingly and let's work
on this at upstream. This is a valid use case for multilib and we
ought to discuss this at oe-core to see how to address the issue in a
clean way.


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