|
From: Mark W. <ma...@kl...> - 2023-04-15 02:07:05
|
An RC1 tarball for 3.21.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind There are still some patches being reviewed and a RC2 will appear end of next week. If nothing critical emerges after that, a final release will happen on Friday 28 April. |
|
From: Paul F. <pj...@wa...> - 2023-04-16 07:44:33
|
On 04/15/23 04:06 AM, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > First test, Solaris 11.3/ Build fails because pipe2 is not available. Also logged as https://bugs.kde.org/show_bug.cgi?id=468556 gcc -std=gnu11 -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -Wl,-M,/usr/lib/ld/map.noexstk -o valgrind valgrind-launcher-linux.o valgrind-m_debuglog.o gcc -std=gnu11 -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -o vgdb vgdb-vgdb.o vgdb-vgdb-invoker-solaris.o -lsocket Undefined first referenced symbol in file pipe2 vgdb-vgdb.o ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status gmake[3]: *** [vgdb] Error 1 gmake[3]: *** Waiting for unfinished jobs.... mv -f m_replacemalloc/.deps/libreplacemalloc_toolpreload_x86_solaris_a-vg_replace_malloc.Tpo m_replacemalloc/.deps/libreplacemalloc_toolpreload_x86_solaris_a-vg_replace_malloc.Po mv -f m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-generic.Tpo m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-generic.Po mv -f m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-solaris.Tpo m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-solaris.Po gmake[3]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1/coregrind' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1/coregrind' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1' gmake: *** [all] Error 2 A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-16 11:28:40
|
On 15-04-23 04:06, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind Test 2, Illumos (OpenIndiana 22.10 with latest pkg update) Configure failure related to this check if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q 0x526570; then The constant used now seems to be 0x4d0152657015 Just dropping the 0x seems to work. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-16 21:04:06
|
On 15-04-23 04:06, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc Illumos builds OK now from git HEAD. Test 3 macOS 10.13, a bit like Solaris 11.3, no pipe2 vgdb.c:91:32: warning: format specifies type 'long' but the argument has type '__darwin_suseconds_t' (aka 'int') [-Wformat] sprintf(ptr, ".%6.6ld ", dbgtv.tv_usec); ~~~~~~ ^~~~~~~~~~~~~ %6.6d /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ vgdb.c:1145:8: warning: implicit declaration of function 'pipe2' is invalid in C99 [-Wimplicit-function-declaration] if (pipe2 (pipefd, O_CLOEXEC) == -1) { Builds OK from git HEAD. Test 4 Alpine (musl) Builds OK == 614 tests, 102 stderr failures, 27 stdout failures, 1 stderrB failure, 2 stdoutB failures, 4 post failures == Test 5 FreeBSD No problems same as nightly == 796 tests, 2 stderr failures, 1 stdout failure, 1 stderrB failure, 1 stdoutB failure, 0 post failures == A+ Paul |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-16 21:15:32
|
Hi, My plans for the release: - I have one more significant improvement to `cg_annotate` to come, which will add merge and diff capability to it, in a way that is better than the merge/diff capability provided by `cg_merge` and `cg_diff`. - I need to update the Cachegrind docs and the NEWS file for all the changes I've made. I know these will be happening late in the release cycle, but because it's all Python code it should require less testing. The likelihood of platform-specific differences in behaviour is much lower than in most other code within Valgrind. Nick On Sat, 15 Apr 2023 at 12:07, Mark Wielaard <ma...@kl...> wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind > > There are still some patches being reviewed and a RC2 will appear end > of next week. If nothing critical emerges after that, a final release > will happen on Friday 28 April. > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Carl L. <ce...@us...> - 2023-04-17 16:22:39
|
Mark: On Sat, 2023-04-15 at 04:06 +0200, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > I have tried the tar ball on a couple of different Power 10 systems, Power 9 and Power 8. The results on the first Power 10 box with Red Hat Enterprise Linux release 9.0 (Plow) look fine: == 708 tests, 2 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdout\ B failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The results on the second Power 10 with Fedora release 36 (Thirty Six) look a little strange: == 709 tests, 2 stderr failures, 2 stdout failures, 1 stderrB failure, 0 stdout\ B failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/ppc64/test_isa_3_1_R1_RT (stdout) none/tests/ppc64/test_isa_3_1_R1_XT (stdout) The test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests seem to run differently then expected. The tests generate multiple lines of output when only one line was expected. For example: plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 ... (cut about 250 lines) +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 There seem to be about 250 more copies of the output line then expected. This happens on a number of different instructions. The outputs are all identical, just more lines then expected. It appears to be a difference in how the test program runs, not in the resultgenerated by Valgrind. The output on Power 9, with Ubuntu 20.04.5 LTS == 700 tests, 4 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 8 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The output for Power 8, Ubuntu 20.04.5 LTS == 696 tests, 4 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 8 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The Power 8 and 9 results are the same. They both have the same distro. The gdbserver tests can be a bit touchy if the versions are not a perfect match. I would expect that is the cause of the gdbserver failures. I haven't looked to see what the issue is with memcheck and massif but it is probably distro related. Not really that concerned about the results on Power 8 and 9. I will look into why the results are different on the Power 10 systems. As said, the results appear to be a test program issue not an issue with Valgrind itself. I would not hold up the release for this test failure. The RC1 release looks good to me on PowerPC. Carl |
|
From: Carl L. <ce...@us...> - 2023-04-18 19:54:14
|
Mark:
On Mon, 2023-04-17 at 09:22 -0700, Carl Love via Valgrind-developers
wrote:
> The test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests seem to run
> differently then expected. The tests generate multiple lines of
> output
> when only one line was expected. For example:
I have pushed a fix for the two tests. The issue is the tests are
testing load instructions that load relative to the current PC address.
The tests of these instructions adds blocks of OR immediate
instructions before the assembly for the instruction under test.
Unfortunately, the test didn't save and restore the registers touched
by the OR immediate instructions. This is fine as long as you are
calling a function, the touched registers are volitile across a
function call. It seems the more recent GCC is a bit more aggressive
in inlining the test functions. However, the compiler doesn't realize
that the inline OR immediate instructions are touching registers. The
OR immediate instructions were inadvertently changing the value of the
register that held the for loop variable. Thus the loops would execute
more times then expected.
The commit is:
commit 20cc0680c3491e062c76605b24e76dc02e16ef47 (HEAD -> master)
Author: Carl Love <ce...@us...>
Date: Mon Apr 17 17:12:25 2023 -0400
PowerPC:, Fix test test_isa_3_1_R1_RT.c, test_isa_3_1_R1_XT.c
If the commit gets into the current release, great. If not, it is not
an issue. The problem is completely isolated to the test case.
Carl
|
|
From: John R. <jr...@bi...> - 2023-04-19 15:08:19
|
On 4/18/23 12:53, Carl Love via Valgrind-developers wrote:
> Mark:
>
> On Mon, 2023-04-17 at 09:22 -0700, Carl Love via Valgrind-developers
> wrote:
>> The test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests seem to run
>> differently then expected. The tests generate multiple lines of
>> output
>> when only one line was expected. For example:
>
> I have pushed a fix for the two tests. The issue is the tests are
> testing load instructions that load relative to the current PC address.
> The tests of these instructions adds blocks of OR immediate
> instructions before the assembly for the instruction under test.
> Unfortunately, the test didn't save and restore the registers touched
> by the OR immediate instructions. This is fine as long as you are
> calling a function, the touched registers are volitile across a
> function call. It seems the more recent GCC is a bit more aggressive
> in inlining the test functions. However, the compiler doesn't realize
> that the inline OR immediate instructions are touching registers. The
> OR immediate instructions were inadvertently changing the value of the
> register that held the for loop variable. Thus the loops would execute
> more times then expected.
>
> The commit is:
>
> commit 20cc0680c3491e062c76605b24e76dc02e16ef47 (HEAD -> master)
> Author: Carl Love <ce...@us...>
> Date: Mon Apr 17 17:12:25 2023 -0400
>
> PowerPC:, Fix test test_isa_3_1_R1_RT.c, test_isa_3_1_R1_XT.c
>
> If the commit gets into the current release, great. If not, it is not
> an issue. The problem is completely isolated to the test case.
At the lowest level, the problem is that a statement such as
__asm__ __volatile__ ("ori 21,21,21");
in the PAD_ORI macro of none/tests/ppc64/isa_3_1_helpers.h
is incomplete because it does not specify the CLOBBERS portion of __asm__.
[See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html ]
Here is a more-complete statement that tells the compiler
that the __asm__ scribbles on register 21:
__asm__ __volatile__ ("ori 21,21,21"
: /* empty: no outputs from asm to C */
: /* empty: no inputs from C to asm */
: "21" /* clobbers register 21 */
);
Omitting the CLOBBERS is surprising because other __asm__ in the same file
do use it, such as:
__asm__ __volatile__ ("mtcr %0" : : "b"(_arg) : ALLCR );
If the CLOBBERS are specified, the the compiler automatically saves and
restores the clobbered registers, if required because "callee saved" by the
global usage convention. This can be seen by compiling a test such as:
int fn2(int,int,int,int,int,int,int,int,
int,int,int,int,int,int,int,int); /* external */
int fn1(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8)
{
int b1=1, b2=2, b3=3, b4=4, b5=5, b6=6, b7=7, b8=8;
fn2(a1,b1,a2,b2,a3,b3,a4,b4,a5,b5,a6,b6,a7,b7,a8,b8);
__asm__ __volatile__ (
"ori 21,21,21; ori 22,22,22; ori 23,23,23; ori 24,24,24"
: /* empty: no outputs from asm to C */
: /* empty: no inputs from C to asm */
: "21", "22", "23", "24" /* clobbers these registers */
);
fn2(a1,b1,a2,b2,a3,b3,a4,b4,a5,b5,a6,b6,a7,b7,a8,b8);
}
and inspecting the generated code; I used gcc 4.9.2:
fn1:
stwu 1,-160(1)
mflr 0
stw 0,164(1)
stw 21,116(1)
stw 22,120(1)
stw 23,124(1)
stw 24,128(1)
<<snip>>
bl fn2
#APP
# 8 "asm2.c" 1
ori 21,21,21; ori 22,22,22; ori 23,23,23; ori 24,24,24
# 0 "" 2
#NO_APP
<<snip>>
lwz 21,-44(11)
lwz 22,-40(11)
lwz 23,-36(11)
lwz 24,-32(11)
lwz 31,-4(11)
mr 1,11
blr
Not specifying the CLOBBERS may be deliberate, perhaps because the
compiler's automatic save and restore interferes with some other
property of the testing. In that case, there should be a comment
in the code, such as:
/* The __asm__ CLOBBERS are omitted because auto-save and restore
* gets in the way of computing offsets between code blocks.
* Therefore we must save and restore "by hand".
*/
|
|
From: Carl L. <ce...@us...> - 2023-04-19 18:31:31
|
On Wed, 2023-04-19 at 08:08 -0700, John Reiser wrote:
> >
<snip>
> On 4/18/23 12:53, Carl Love via Valgrind-developers wrote:
>
> At the lowest level, the problem is that a statement such as
> __asm__ __volatile__ ("ori 21,21,21");
Yes, that is the issue because it is using registers that the compiler
is not aware of.
> in the PAD_ORI macro of none/tests/ppc64/isa_3_1_helpers.h
> is incomplete because it does not specify the CLOBBERS portion of
> __asm__.
> [See
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
> e= ]
> Here is a more-complete statement that tells the compiler
> that the __asm__ scribbles on register 21:
> __asm__ __volatile__ ("ori 21,21,21"
> : /* empty: no outputs from asm to C */
> : /* empty: no inputs from C to asm */
> : "21" /* clobbers register 21 */
> );
>
I wasn't aware of the full specification on the asm command. This is
really helpful.
> Omitting the CLOBBERS is surprising because other __asm__ in the same
> file
> do use it, such as:
> __asm__ __volatile__ ("mtcr %0" : : "b"(_arg) : ALLCR );
>
> If the CLOBBERS are specified, the the compiler automatically saves
> and
> restores the clobbered registers, if required because "callee saved"
> by the
> global usage convention.
Yup, I tried removing the SAVE_REG and RESTORE_REG macros I added and
updated the PAD_ORI macro instead. This works as you said. It does
have the added advantage of removing the modification of the fetched
register by the instructions under test which my save/restore registers
macro didn't do.
I have created an additional patch to change the fix for the tests
using your approach which I will commit shortly.
Thanks for the help.
Carl
|