|
From: Christian B. <bor...@de...> - 2011-09-03 20:33:14
Attachments:
diffs.gz
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-09-03 22:05:01 CEST Ended at 2011-09-03 22:33:03 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 497 tests, 16 stderr failures, 1 stdout failure, 8 stderrB failures, 0 stdoutB failures, 1 post failure == gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/linux/timerfd-syscall (stderr) memcheck/tests/sbfragment (stdout) massif/tests/big-alloc (post) none/tests/faultstatus (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-09-05 19:36:28
|
As you might know the locked_vs_unlocked testcases fail on s390x:
> helgrind/tests/locked_vs_unlocked1_fwd (stderr)
> helgrind/tests/locked_vs_unlocked1_rev (stderr)
> helgrind/tests/locked_vs_unlocked2 (stderr)
> helgrind/tests/locked_vs_unlocked3 (stderr)
The only difference for all tests is in the backtrace:
on sles
at 0x........: clone (in /...libc...)
- by 0x........: pthread_create@@GLIBC_2.2.5 (in /...libpthread...)
- by 0x........: pthread_create_WRK (hg_intercepts.c:...)
+ by 0x........: do_clone (in /...libpthread...)
+ by 0x........: pthread_create@@GLIBC_2.2 (in /...libpthread...)
on fedora
- by 0x........: pthread_create@@GLIBC_2.2.5 (in /...libpthread...)
- by 0x........: pthread_create_WRK (hg_intercepts.c:...)
+ by 0x........: do_clone.clone.0 (in /...libpthread...)
+ by 0x........: pthread_create@@GLIBC_2.2 (in /...libpthread...)
The full callchain on s390 is something like
pthread_create-->do_clone-->clone instead of pthread_create-->clone.
As you can see, newer version of gcc even create multiple clones of
do_clone (for partial inlining etc). the cleanest solution seems to me
to change the --num-callers=3 in the vgtest to --num-callers=1.
Otherwise I have to add at least 2 expect files to these tests.
Opinions?
Christian
|
|
From: Julian S. <js...@ac...> - 2011-09-05 20:36:12
|
> The full callchain on s390 is something like > pthread_create-->do_clone-->clone instead of pthread_create-->clone. > As you can see, newer version of gcc even create multiple clones of > do_clone (for partial inlining etc). the cleanest solution seems to me > to change the --num-callers=3 in the vgtest to --num-callers=1. > Otherwise I have to add at least 2 expect files to these tests. > > Opinions? I can't see any alternative to adding more expect files. If the differences in stack traces were in hg_intercepts.c then we might be able to throw in some __attribute__((noinline)) directives, to make the stack traces more consistent. But the differences are in libpthread itself, so that doesn't help. <somewhat obvious observation> If gcc is doing partial inlining now (which version, btw?) then this is going to be a general problem, not just an s390-specific one. </somewhat obvious observation> J |
|
From: Christian B. <bor...@de...> - 2011-09-05 21:34:02
|
> I can't see any alternative to adding more expect files. If the > differences in stack traces were in hg_intercepts.c then we might > be able to throw in some __attribute__((noinline)) directives, to > make the stack traces more consistent. But the differences are in > libpthread itself, so that doesn't help. Ok, I will add more exp files. > <somewhat obvious observation> > If gcc is doing partial inlining now (which version, btw?) then > this is going to be a general problem, not just an s390-specific > one. > </somewhat obvious observation> It was probably the wrong name - creating special purpose versions of a function might a better description. see http://gcc.gnu.org/gcc-4.5/changes.html: [...] The function attribute noinline no longer prevents GCC from cloning the function. A new attribute noclone has been introduced for this purpose. Cloning a function means that it is duplicated and the new copy is specialized for certain contexts (for example when a parameter is a known constant). [...] Maybe I can massage the test suite to filter out any \.clone\.[0-9]+ patterns. Christian |
|
From: Christian B. <bor...@de...> - 2011-09-13 15:22:18
|
On 05/09/11 22:35, Julian Seward wrote: > <somewhat obvious observation> > If gcc is doing partial inlining now (which version, btw?) then > this is going to be a general problem, not just an s390-specific > one. > </somewhat obvious observation> Can you look at the patch in https://bugs.kde.org/show_bug.cgi?id=281468 ? It contains a filter that tries to get rid of .clone. constprop. isra. If that looks acceptable, please apply. Christian |
|
From: Florian K. <br...@ac...> - 2011-09-06 15:36:46
|
On 09/05/2011 04:35 PM, Julian Seward wrote: > >> The full callchain on s390 is something like >> pthread_create-->do_clone-->clone instead of pthread_create-->clone. >> As you can see, newer version of gcc even create multiple clones of >> do_clone (for partial inlining etc). the cleanest solution seems to me >> to change the --num-callers=3 in the vgtest to --num-callers=1. >> Otherwise I have to add at least 2 expect files to these tests. >> >> Opinions? > > I can't see any alternative to adding more expect files. Perhaps we can filter the output better. If I run helgrind/tests/locked_vs_unlocked1 with --num-callers=8 I see output like this. ==2080== Thread #3 was created ==2080== at 0x412B688: clone (clone.S:111) ==2080== by 0x40474BB: pthread_create@@GLIBC_2.1 (createthread.c:256) ==2080== by 0x402B51C: pthread_create_WRK (hg_intercepts.c:255) ==2080== by 0x402B5F5: pthread_create@* (hg_intercepts.c:286) ==2080== by 0x8048653: main (locked_vs_unlocked1.c:34) One could argue that the part of the back trace underneath pthread_create_WRK isn't really all that interesting for testing purposes. So if we filtered the above to yield ==2080== Thread #3 was created ==2080== by 0x402B51C: pthread_create_WRK (hg_intercepts.c:255) ==2080== by 0x402B5F5: pthread_create@* (hg_intercepts.c:286) ==2080== by 0x8048653: main (locked_vs_unlocked1.c:34) wouldn't that be good enough? It would get rid of the noise Christian mentioned and we wouldn't need different expect files (or could at least cut down on the number of those). Such a filter could take a list of function names and/or a list of file names and throw away all those back trace lines that do not match either a function or a file from those lists. That should be doable if perl is allowed in fiter scripts (which I presume is the case). Florian |
|
From: Christian B. <bor...@de...> - 2011-09-06 15:47:51
|
FYI, I have added a bugzilla and a patch: https://bugs.kde.org/show_bug.cgi?id=281468 |