[PATCH 1/5] valgrind: fix vg_regtest return code

[PATCH 1/5] valgrind: fix vg_regtest return code

[Randy MacLeod]

Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 ...rn-a-valid-exit_code-from-vg_regtest.patch | 27 +++++++++++++++++++
 .../valgrind/valgrind_3.15.0.bb               |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 meta/recipes-devtools/valgrind/valgrind/0001-Return-a-valid-exit_code-from-vg_regtest.patch

diff --git a/meta/recipes-devtools/valgrind/valgrind/0001-Return-a-valid-exit_code-from-vg_regtest.patch b/meta/recipes-devtools/valgrind/valgrind/0001-Return-a-valid-exit_code-from-vg_regtest.patch
new file mode 100644
index 0000000000..e7af5efecc
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0001-Return-a-valid-exit_code-from-vg_regtest.patch
@@ -0,0 +1,27 @@
+From 5eebdefd2251803e7d21081745018fcb16b2ba71 Mon Sep 17 00:00:00 2001
+From: Randy MacLeod <Randy.MacLeod@windriver.com>
+Date: Wed, 8 May 2019 20:16:52 -0400
+Subject: [PATCH] Return a valid exit_code from vg_regtest
+
+Upstream-Status: Pending
+
+Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
+---
+ tests/vg_regtest.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tests/vg_regtest.in b/tests/vg_regtest.in
+index 909af3be8..f2799c4e3 100755
+--- a/tests/vg_regtest.in
++++ b/tests/vg_regtest.in
+@@ -403,6 +403,7 @@ sub mysystem($)
+             exit 1;
+         }
+     }
++    return $exit_code;
+ }
+ # if $keepunfiltered, copies $1 to $1.unfiltered.out
+ # renames $0 tp $1
+-- 
+2.17.0
+
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
index 3159f32230..9749fdb244 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
@@ -36,6 +36,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
            file://0001-fix-opcode-not-supported-on-mips32-linux.patch \
            file://0001-Guard-against-__GLIBC_PREREQ-for-musl-libc.patch \
            file://0001-Make-local-functions-static-to-avoid-assembler-error.patch \
+           file://0001-Return-a-valid-exit_code-from-vg_regtest.patch \
            "
 SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975"
 SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1"
-- 
2.17.0

[PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

About half the ptests will fail if the executables deployed
as part of the ptest package are stripped. Currently
there is no easy way to only strip the main valgrind
package so leave it and the ptests *all* unstripped.

There is an enhancement filed to enable wildcard stripping:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
so this recipe can be fixed once that is implemented.

Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
index 9749fdb244..b72f4d76ee 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
@@ -114,6 +114,10 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
 # One of the tests contains a bogus interpreter path on purpose.
 # Skip file dependency check
 SKIP_FILEDEPS_${PN}-ptest = '1'
+# INHIBIT_PACKAGE_STRIP_${PN}-ptest = '1'
+# PACKAGE_DEBUG_SPLIT_STYLE_${PN}-ptest = 'debug-file-directory'
+INHIBIT_PACKAGE_STRIP = '1'
+PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
 
 do_compile_ptest() {
     oe_runmake check
-- 
2.17.0

[PATCH 3/5] valgrind: update the ptest subdirs list

[Randy MacLeod]

Split the list into one directory per line.
Sort the list alphabetically.
Add the gdbserver_tests directory to get the 'gone' executable
which is needed by:
    memcheck/tests/gone_abrt_xml.vgtest

Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
index b72f4d76ee..4c5a4b3c70 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
@@ -139,7 +139,17 @@ do_install_ptest() {
         # exclude shell or the package won't install
         rm -rf none/tests/shell* 2>/dev/null
 
-        subdirs="tests cachegrind/tests callgrind/tests drd/tests helgrind/tests massif/tests memcheck/tests none/tests"
+        subdirs=" \
+	   cachegrind/tests \
+	   callgrind/tests \
+	   drd/tests \
+	   gdbserver_tests \
+	   helgrind/tests \
+	   massif/tests \
+	   memcheck/tests \
+	   none/tests \
+	   tests \
+	"
 
         # Get the vg test scripts, filters, and expected files
         for dir in $subdirs ; do
-- 
2.17.0

[PATCH 4/5] valgrind: adjust test filters and expected output

[Randy MacLeod]

Skip two filters in filter_xml_frames since they
are intended to filter filesystem paths under '/usr' that
vary from platform to platform. In the ptest case
for Yocto's valgrind, the ptest executables are placed under:
   /usr/lib/valgrind/ptest
and if these frames are filtered out, then several 'drd' tests fail
the comparision between expected and actual output.

Also adjust the std_list expected output to agree with that
produced when the --yocto-ptest option to vg_regtest is used.

Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 ...-filter_xml_frames-do-not-filter-usr.patch | 39 +++++++++++++++++++
 ...rind-adjust-std_list-expected-output.patch | 32 +++++++++++++++
 .../valgrind/valgrind_3.15.0.bb               |  2 +
 3 files changed, 73 insertions(+)
 create mode 100644 meta/recipes-devtools/valgrind/valgrind/0001-valgrind-filter_xml_frames-do-not-filter-usr.patch
 create mode 100644 meta/recipes-devtools/valgrind/valgrind/0002-valgrind-adjust-std_list-expected-output.patch

diff --git a/meta/recipes-devtools/valgrind/valgrind/0001-valgrind-filter_xml_frames-do-not-filter-usr.patch b/meta/recipes-devtools/valgrind/valgrind/0001-valgrind-filter_xml_frames-do-not-filter-usr.patch
new file mode 100644
index 0000000000..bf0f0ded21
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0001-valgrind-filter_xml_frames-do-not-filter-usr.patch
@@ -0,0 +1,39 @@
+From d1dea3c2bcf1e22baab39e2c0b8ca59db8a5bc37 Mon Sep 17 00:00:00 2001
+From: Randy MacLeod <Randy.MacLeod@windriver.com>
+Date: Mon, 13 May 2019 17:12:21 -0400
+Subject: [PATCH 1/2] valgrind: filter_xml_frames: do not filter /usr
+
+filter_xml_frames is intended to filter system paths under
+'/usr' that vary from platform to platform. In the ptest case
+for Yocto's valgrind, the ptest executables are placed under:
+   /usr/lib/valgrind/ptest
+and if these frames are filtered out, then the 'drd' tests fail
+the comparision between exepected and actual output.
+
+Changing this filter allows the comparison to succeed without
+any negative impact.
+
+Upstream-Status: Inappropriate [Yocto specific]
+
+Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
+---
+ tests/filter_xml_frames | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tests/filter_xml_frames b/tests/filter_xml_frames
+index f1fa3f070..04fbc82de 100755
+--- a/tests/filter_xml_frames
++++ b/tests/filter_xml_frames
+@@ -47,7 +47,8 @@ while (my $line = <>)
+         $has_function_name = 1 if ($line =~ /<fn>/);
+ # This may require tweaking; currently  /lib and /usr/lib are matched
+         $has_system_obj = 1 if ($line =~ /<obj>\/lib/);
+-        $has_system_obj = 1 if ($line =~ /<obj>\/usr\/lib/);
++# for Yocto, skip /usr since tests are under /usr/lib/...
++#        $has_system_obj = 1 if ($line =~ /<obj>\/usr\/lib/);
+     }
+ }
+ 
+-- 
+2.17.0
+
diff --git a/meta/recipes-devtools/valgrind/valgrind/0002-valgrind-adjust-std_list-expected-output.patch b/meta/recipes-devtools/valgrind/valgrind/0002-valgrind-adjust-std_list-expected-output.patch
new file mode 100644
index 0000000000..a82972ec1b
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0002-valgrind-adjust-std_list-expected-output.patch
@@ -0,0 +1,32 @@
+From 6e1e9265b03cf51d09c028d657fe826d7156a783 Mon Sep 17 00:00:00 2001
+From: Randy MacLeod <Randy.MacLeod@windriver.com>
+Date: Mon, 13 May 2019 17:26:26 -0400
+Subject: [PATCH 2/2] valgrind: adjust std_list expected output
+
+The run-ptest script uses a custom --yocto-ptest option
+to change the summary statistics that valgrind issues
+to a format that matches what ptest-runner expects.
+
+Only this std_list test which checks that strcpy() works
+properly on Ubuntu-12.04 and later is affected by this change.
+It's normal output when called with --yocto-ptest is a blank
+line so adjust the expected output.
+
+Upstream-Status: Inappropriate [Yocto specific]
+
+Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
+---
+ drd/tests/std_list.stderr.exp | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/drd/tests/std_list.stderr.exp b/drd/tests/std_list.stderr.exp
+index d18786f80..8b1378917 100644
+--- a/drd/tests/std_list.stderr.exp
++++ b/drd/tests/std_list.stderr.exp
+@@ -1,3 +1 @@
+ 
+-
+-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+-- 
+2.17.0
+
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
index 4c5a4b3c70..8fecdefb91 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
@@ -37,6 +37,8 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
            file://0001-Guard-against-__GLIBC_PREREQ-for-musl-libc.patch \
            file://0001-Make-local-functions-static-to-avoid-assembler-error.patch \
            file://0001-Return-a-valid-exit_code-from-vg_regtest.patch \
+           file://0001-valgrind-filter_xml_frames-do-not-filter-usr.patch \
+           file://0002-valgrind-adjust-std_list-expected-output.patch \
            "
 SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975"
 SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1"
-- 
2.17.0

[PATCH 5/5] valgrind: fix call/cachegrind ptests

[Randy MacLeod]

Use the *_annotate executables from ${bindir}

Actually install cachegrind/tests/a.c since it is used by
the call/cachegrind/tests/ann[12].vgtest files.

With this change and the previous commits, the ptest results
on qemux86-64 when invoked with:
    runqemu qemux86 kvm nographic slirp qemuparams="-m 2048"
are:

=== Test Summary ===
TOTAL: 159
PASSED: 149
FAILED: 1
SKIPPED: 9

Only drd/tests/pth_detached3 remains to be fixed.

Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
index 8fecdefb91..f8b6b003a1 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb
@@ -160,6 +160,8 @@ do_install_ptest() {
         cd $saved_dir
     done
 
+    # Hide then restore a.c that is used by ann[12].vgtest in call/cachegrind
+    mv ${D}${PTEST_PATH}/cachegrind/tests/a.c ${D}${PTEST_PATH}/cachegrind/tests/a_c
     # clean out build artifacts before building the rpm
     find ${D}${PTEST_PATH} \
          \( -name "Makefile*" \
@@ -168,6 +170,14 @@ do_install_ptest() {
         -o -name "*.S" \
         -o -name "*.h" \) \
         -exec rm {} \;
+    mv ${D}${PTEST_PATH}/cachegrind/tests/a_c ${D}${PTEST_PATH}/cachegrind/tests/a.c
+
+    # find *_annotate in ${bindir} for yocto build
+    sed -i s:\.\./\.\./cachegrind/cg_annotate:${bindir}/cg_annotate: ${D}${PTEST_PATH}/cachegrind/tests/ann1.vgtest
+    sed -i s:\.\./\.\./cachegrind/cg_annotate:${bindir}/cg_annotate: ${D}${PTEST_PATH}/cachegrind/tests/ann2.vgtest
+
+    sed -i s:\.\./\.\./callgrind/callgrind_annotate:${bindir}/callgrind_annotate: ${D}${PTEST_PATH}/callgrind/tests/ann1.vgtest
+    sed -i s:\.\./\.\./callgrind/callgrind_annotate:${bindir}/callgrind_annotate: ${D}${PTEST_PATH}/callgrind/tests/ann2.vgtest
 
     # needed by massif tests
     cp ${B}/massif/ms_print ${D}${PTEST_PATH}/massif/ms_print
-- 
2.17.0

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Richard Purdie]

On Mon, 2019-05-13 at 23:57 -0400, Randy MacLeod wrote:
> About half the ptests will fail if the executables deployed
> as part of the ptest package are stripped. Currently
> there is no easy way to only strip the main valgrind
> package so leave it and the ptests *all* unstripped.
> 
> There is an enhancement filed to enable wildcard stripping:
>    https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
> so this recipe can be fixed once that is implemented.
> 
> Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
> ---
>  meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
>  1 file changed, 4 insertions(+)

I did test whether we could get away with a dependency on valgrind-dbg
as in theory that should behave the same way. It doesn't which means
the debug symbol linkage isn't being honoured by valgrind and that is
something we need to look into too :/.

I'm torn on whether to accept this patch or try and fix partial
stripping...

Cheers,

Richard

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Burton, Ross]

On Mon, 13 May 2019 at 20:57, Randy MacLeod <Randy.MacLeod@windriver.com> wrote:
> About half the ptests will fail if the executables deployed
> as part of the ptest package are stripped. Currently
> there is no easy way to only strip the main valgrind
> package so leave it and the ptests *all* unstripped.

What's the disk usage impact of an unstripped valgrind package?

Ross

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

On 5/14/19 10:08 AM, Richard Purdie wrote:
> On Mon, 2019-05-13 at 23:57 -0400, Randy MacLeod wrote:
>> About half the ptests will fail if the executables deployed
>> as part of the ptest package are stripped. Currently
>> there is no easy way to only strip the main valgrind
>> package so leave it and the ptests *all* unstripped.
>>
>> There is an enhancement filed to enable wildcard stripping:
>>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
>> so this recipe can be fixed once that is implemented.
>>
>> Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
>> ---
>>   meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
>>   1 file changed, 4 insertions(+)
> 
> I did test whether we could get away with a dependency on valgrind-dbg
> as in theory that should behave the same way. It doesn't which means
> the debug symbol linkage isn't being honoured by valgrind and that is
> something we need to look into too :/.

I tried that as well. When it didn't work and I couldn't find an
example that used that sort of dependency, I looked for other solutions
and ended up with the admittedly poor one here which only has the
one benefit that it works. ;-)

Ross asked about the disk usage impact:

du -sk for .../packages-split/foo

Type         valgrind    valgrind-ptest
unstripped   169732      138192
stripped      27224       99836

ls -l /.../packages-split/usr/bin/valgrind
unstripped: 88672
   stripped: 22728

To be sure such bloat doesn't slip into the 2.8 release,
we should probably wait for the partial stripping ER implementation
and/or I can figure out what's wrong with adding a
    valgrind-ptest -> valgrind-dbg
dependency.

> 
> I'm torn on whether to accept this patch or try and fix partial
> stripping...

Let's wait. See above.

We at least understand all but one of the valgrind ptest problems
that were happening on x86-64. The drd/tests/pth_detached3 [1] failure
seems to be with valgrind itself. The executable is meant to segfault
and it does:

root@qemux86-64:/usr/lib/valgrind/ptest# drd/tests/pth_detached3
[ 2148.508705] pth_detached3[9127]: segfault at 7ffc5acd0090 ip 
0000003a0460a15c sp 00007ffc5accfa08 error 6 in 
libpthread-2.29.so[3a04607000+f000]
[ 2148.515650] Code: 10 00 00 00 f0 83 88 08 03 00 00 10 64 48 8b 3c 25 
00 03 00 00 e8 64 7c 00 00 0f 1f 40 00 8b 87 d0 02 00 00 85 c0 78 36 31 
c0 <f6
Segmentation fault

but when run under valgrind, there's an extra frame in the stack trace:

root@qemux86-64:# cat drd/tests/pth_detached3.stderr.diff1
--- pth_detached3.stderr.exp1   2019-05-14 15:46:06.000000000 +0000
+++ pth_detached3.stderr.out    2019-05-14 16:13:34.355000000 +0000
@@ -1,12 +1,19 @@

  pthread_detach(): invalid thread ID 0x........
-   at 0x........: pthread_detach (drd_pthread_intercepts.c:?)
+   at 0x........: vgDrd_set_joinable (drd_pthread_intercepts.c:?)
+   by 0x........: pthread_detach (drd_pthread_intercepts.c:?)
     by 0x........: main (pth_detached3.c:21)
...

I need to learn a bit more before considering whether to just add
the missing lines to the expected output file to allow the test to pass.

qemuarm64 is still a problem that I intend to work on it soon.
ptests trigger the OOM killer even if I give the system 3GB of RAM
but I haven't really worked to understand why.

../Randy

> 
> Cheers,
> 
> Richard
> 


-- 
# Randy MacLeod
# Wind River Linux


[1] drd/tests/pth_detached3.c

/* Invoke pthread_detach() with an invalid thread ID. */

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>

static void* thread_func(void* arg)
{
   return 0;
}

int main(int argc, char** argv)
{
   pthread_t thread;

   pthread_create(&thread, NULL, thread_func, NULL);
   pthread_join(thread, NULL);

   /* Invoke pthread_detach() with the thread ID of a joined thread. */
   pthread_detach(thread);

   /* Invoke pthread_detach() with an invalid thread ID. */
   pthread_detach(thread + 8);

   fprintf(stderr, "Finished.\n");

   return 0;
}

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[richard.purdie]

On Tue, 2019-05-14 at 13:54 -0400, Randy MacLeod wrote:
> On 5/14/19 10:08 AM, Richard Purdie wrote:
> > On Mon, 2019-05-13 at 23:57 -0400, Randy MacLeod wrote:
> > > About half the ptests will fail if the executables deployed
> > > as part of the ptest package are stripped. Currently
> > > there is no easy way to only strip the main valgrind
> > > package so leave it and the ptests *all* unstripped.
> > > 
> > > There is an enhancement filed to enable wildcard stripping:
> > >     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
> > > so this recipe can be fixed once that is implemented.
> > > 
> > > Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
> > > ---
> > >   meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > 
> > I did test whether we could get away with a dependency on valgrind-
> > dbg
> > as in theory that should behave the same way. It doesn't which
> > means
> > the debug symbol linkage isn't being honoured by valgrind and that
> > is
> > something we need to look into too :/.
> 
> I tried that as well. When it didn't work and I couldn't find an
> example that used that sort of dependency, I looked for other
> solutions
> and ended up with the admittedly poor one here which only has the
> one benefit that it works. ;-)

Actually, my test was flawed. I just retested and this time it worked.
What I tested with was:

RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob ${PN} ${PN}-dbg"
INSANE_SKIP_${PN}-ptest = "debug-deps"

Can you see if that works for you?

We also have a problem that its overflowing the 4GB limit on some image
sizes with the debug info included :/

Cheers,

Richard

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

On 5/14/19 5:32 PM, richard.purdie@linuxfoundation.org wrote:
> Actually, my test was flawed. I just retested and this time it worked.
> What I tested with was:
> 
> RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob ${PN} ${PN}-dbg"
> INSANE_SKIP_${PN}-ptest = "debug-deps"

Ah nice. Thanks.

> 
> Can you see if that works for you?

Sure. I'll test and resend the whole series.

> 
> We also have a problem that its overflowing the 4GB limit on some image
> sizes with the debug info included :/

There's an enhancement to track that:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=13025
Kevin owns it and has it scheduled for 2.8 M2.

../Randy

> 
> Cheers,
> 
> Richard


-- 
# Randy MacLeod
# Wind River Linux

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[richard.purdie]

On Tue, 2019-05-14 at 17:42 -0400, Randy MacLeod wrote:
> On 5/14/19 5:32 PM, richard.purdie@linuxfoundation.org wrote:
> > Actually, my test was flawed. I just retested and this time it
> > worked.
> > What I tested with was:
> > 
> > RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob ${PN}
> > ${PN}-dbg"
> > INSANE_SKIP_${PN}-ptest = "debug-deps"
> 
> Ah nice. Thanks.

Note I add PN above, I'm going to send a different patch which does
that in the ptest bbclass as it fixes a ton of problems. Its not quite
a straightforward patch though.

> > Can you see if that works for you?
> 
> Sure. I'll test and resend the whole series.
> 
> > We also have a problem that its overflowing the 4GB limit on some
> > image
> > sizes with the debug info included :/
> 
> There's an enhancement to track that:
>    https://bugzilla.yoctoproject.org/show_bug.cgi?id=13025
> Kevin owns it and has it scheduled for 2.8 M2.

The immediate problem will have to be fixed before valgrind can merge:

https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/602

Cheers,

Richard

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Mittal, Anuj]

On Tue, 2019-05-14 at 17:42 -0400, Randy MacLeod wrote:
> > We also have a problem that its overflowing the 4GB limit on some
> > image
> > sizes with the debug info included :/
> 
> There's an enhancement to track that:
>    https://bugzilla.yoctoproject.org/show_bug.cgi?id=13025
> Kevin owns it and has it scheduled for 2.8 M2.

Chee Yang had sent patches that add 'install' feature to a wic image 
as a first step towards achieving this ... It'd be great if those can
be reviewed:

https://patchwork.openembedded.org/series/17478/

Thanks,

Anuj

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

On 5/14/19 5:46 PM, richard.purdie@linuxfoundation.org wrote:
> On Tue, 2019-05-14 at 17:42 -0400, Randy MacLeod wrote:
>> On 5/14/19 5:32 PM, richard.purdie@linuxfoundation.org wrote:
>>> Actually, my test was flawed. I just retested and this time it
>>> worked.
>>> What I tested with was:
>>>
>>> RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob ${PN}
>>> ${PN}-dbg"
>>> INSANE_SKIP_${PN}-ptest = "debug-deps"
>>
>> Ah nice. Thanks.
> 
> Note I add PN above, I'm going to send a different patch which does
> that in the ptest bbclass as it fixes a ton of problems. Its not quite
> a straightforward patch though.
> 
>>> Can you see if that works for you?
>>
>> Sure. I'll test and resend the whole series.
>>
>>> We also have a problem that its overflowing the 4GB limit on some
>>> image
>>> sizes with the debug info included :/
>>
>> There's an enhancement to track that:
>>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13025
>> Kevin owns it and has it scheduled for 2.8 M2.
> 
> The immediate problem will have to be fixed before valgrind can merge:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/602
> 
> Cheers,
> 
> Richard
> 

More test results!

The qemuarm64 valgrind ptest failures are due to a hard-coded
timeout patch in vg_regtest. It timed out at 30 seconds but
always left orphaned process hanging which eventually triggered
an OOM killer rampage. I bumped the timeout to 300 seconds to
see what that would do. It takes a long, long time but
the final result is the same as x86:

qemuarm64:
=== Test Summary ===
TOTAL: 159
PASSED: 149
FAILED: 1
SKIPPED: 9
DURATION: 10083
END: /usr/lib/valgrind/ptest
2019-05-14T23:16


qemuppc (300 second timeout):
=== Test Summary ===
TOTAL: 159
PASSED: 146
FAILED: 3
SKIPPED: 10
DURATION: 5492
END: /usr/lib/valgrind/ptest
2019-05-15T01:59
STOP: ptest-runner
root@qemuppc:/usr/lib/valgrind/ptest# grep FAIL 
valgrind_ptest_20190515-002816.log
FAIL: drd/tests/annotate_trace_memory
    but ^^^-- sorting exp-32bit and out file -> no diff
FAIL: drd/tests/annotate_trace_memory_xml <-- same
FAIL: drd/tests/std_list
FAILED: 3

I'm not sure why the output file is not ordered as expected but
I will likely not investigate qemuppc unless someone knows of a
use-case where this is an actual problem.


We need to agree on how to handle the ptest timeout.
I'll check if other recipes accept the optional timeout from:
    # ptest-runner -h
    Usage: ptest-runner [-d directory] [-e exclude] [-l list] \
      [-t timeout] [-x xml-filename] [-h] [ptest1 ptest2 ...]

It's tempting to just bump the timeout to 300 seconds
since anything that fails with that timeout really should
be fixed. The right thing is to pass the timeout from ptest-runner
down to valgrind's vg_regtest script. If we have people who set
timeouts to a non-default value and will be running valgrind's
ptest then I could do that.

Since I'm a completist, I'm going to try qemumips64 next! :)
-- 
# Randy MacLeod
# Wind River Linux

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

On 5/14/19 10:22 PM, Randy MacLeod wrote:
> ...

> It's tempting to just bump the timeout to 300 seconds
> since anything that fails with that timeout really should
> be fixed. The right thing is to pass the timeout from ptest-runner
> down to valgrind's vg_regtest script. If we have people who set
> timeouts to a non-default value and will be running valgrind's
> ptest then I could do that.
>
> Since I'm a completist, I'm going to try qemumips64 next! :)

Okay, so maybe I'm not a MIPS64 completist!


qemumips64 hangs on drd/tests/annotate_barrier. I'm not sure why.

When run under gdb:

(gdb) bt
#0  vgPlain_machine_get_hwcaps () at ../../valgrind-3.15.0/coregrind/m_machine.c:1910
#1  0x00000000580b5a80 in valgrind_main (argc=<optimized out>, argv=0x580bb430 <_start_in_C_linux+224>, envp=0x120015520)
     at ../../valgrind-3.15.0/coregrind/m_main.c:1375
#2  0x00000000580bb430 in _start_in_C_linux (pArgc=0xffffffabe0) at ../../valgrind-3.15.0/coregrind/m_main.c:2985
#3  0x00000000580b47e8 in __start ()
Backtrace stopped: frame did not save the PC
(gdb) bt full
#0  vgPlain_machine_get_hwcaps () at ../../valgrind-3.15.0/coregrind/m_machine.c:1910
         have_MSA = 1 '\001'
         saved_set = {sig = {0, 0}}
         tmp_set = {sig = {8, 0}}
         saved_sigill_act = {sa_flags = 0, ksa_handler = 0x0, sa_mask = {sig = {0, 0}}, sa_restorer = 0xffffffae8e}
         tmp_sigill_act = {sa_flags = 1073741824, ksa_handler = 0x58036f90 <handler_unsup_insn>, sa_mask = {sig = {0, 0}}, sa_restorer = 0xffffffae8e}
         r = <optimized out>
         __PRETTY_FUNCTION__ = "vgPlain_machine_get_hwcaps"


1905          /* MSA instructions */
1906          have_MSA = True;
1907          if  (VG_MINIMAL_SETJMP(env_unsup_insn)) {
1908             have_MSA = False;
1909          }else  {
1910             __asm__ __volatile__(".word 0x7800088E");/* addv.b w2, w1, w0 */
1911          }

The qemumips64 ptests for valgrind are now on the back burner.

-- 
# Randy MacLeod
# Wind River Linux


[-- Attachment #2: Type: text/html, Size: 3128 bytes --]

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Khem Raj]

On 5/14/19 7:08 AM, Richard Purdie wrote:
> On Mon, 2019-05-13 at 23:57 -0400, Randy MacLeod wrote:
>> About half the ptests will fail if the executables deployed
>> as part of the ptest package are stripped. Currently
>> there is no easy way to only strip the main valgrind
>> package so leave it and the ptests *all* unstripped.
>>
>> There is an enhancement filed to enable wildcard stripping:
>>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
>> so this recipe can be fixed once that is implemented.
>>
>> Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
>> ---
>>   meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
>>   1 file changed, 4 insertions(+)
> 
> I did test whether we could get away with a dependency on valgrind-dbg
> as in theory that should behave the same way. It doesn't which means
> the debug symbol linkage isn't being honoured by valgrind and that is
> something we need to look into too :/.
> 
> I'm torn on whether to accept this patch or try and fix partial
> stripping...

we need PN-syms and PN-dbg and then we can add rdep on PN-syms alone
but sadly thats another hump to climb.

> 
> Cheers,
> 
> Richard
> 

Re: [PATCH 2/5] valgrind: do not strip the package or ptests

[Khem Raj]

On 5/15/19 12:11 PM, Randy MacLeod wrote:
> On 5/14/19 10:22 PM, Randy MacLeod wrote:
>> ...
> 
>> It's tempting to just bump the timeout to 300 seconds
>> since anything that fails with that timeout really should
>> be fixed. The right thing is to pass the timeout from ptest-runner
>> down to valgrind's vg_regtest script. If we have people who set
>> timeouts to a non-default value and will be running valgrind's
>> ptest then I could do that.
>>
>> Since I'm a completist, I'm going to try qemumips64 next! :)
> 
> Okay, so maybe I'm not a MIPS64 completist!
> 
> 

Let me try to help a bit.

> qemumips64 hangs on drd/tests/annotate_barrier. I'm not sure why.
> 
> When run under gdb:
> 
> (gdb) bt
> #0  vgPlain_machine_get_hwcaps () at ../../valgrind-3.15.0/coregrind/m_machine.c:1910
> #1  0x00000000580b5a80 in valgrind_main (argc=<optimized out>, argv=0x580bb430 <_start_in_C_linux+224>, envp=0x120015520)
>      at ../../valgrind-3.15.0/coregrind/m_main.c:1375
> #2  0x00000000580bb430 in _start_in_C_linux (pArgc=0xffffffabe0) at ../../valgrind-3.15.0/coregrind/m_main.c:2985
> #3  0x00000000580b47e8 in __start ()
> Backtrace stopped: frame did not save the PC
> (gdb) bt full
> #0  vgPlain_machine_get_hwcaps () at ../../valgrind-3.15.0/coregrind/m_machine.c:1910
>          have_MSA = 1 '\001'
>          saved_set = {sig = {0, 0}}
>          tmp_set = {sig = {8, 0}}
>          saved_sigill_act = {sa_flags = 0, ksa_handler = 0x0, sa_mask = {sig = {0, 0}}, sa_restorer = 0xffffffae8e}
>          tmp_sigill_act = {sa_flags = 1073741824, ksa_handler = 0x58036f90 <handler_unsup_insn>, sa_mask = {sig = {0, 0}}, sa_restorer = 0xffffffae8e}
>          r = <optimized out>
>          __PRETTY_FUNCTION__ = "vgPlain_machine_get_hwcaps"
> 
> 
> 1905          /* MSA instructions */
> 1906          have_MSA = True;
> 1907          if  (VG_MINIMAL_SETJMP(env_unsup_insn)) {
> 1908             have_MSA = False;
> 1909          }else  {
> 1910             __asm__ __volatile__(".word 0x7800088E");/* addv.b w2, w1, w0 */


I think its stuck executing this instruction which is checking for ASE 
support and I guess we do not have ASE enabled in qemumips64 base arch 
emulation, or the instruction behaves differently on 32bit and 64bit ABIs


> 1911          }
> 
> The qemumips64 ptests for valgrind are now on the back burner.
> 


> -- 
> # Randy MacLeod
> # Wind River Linux
> 
>