You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
|
From: Paul F. <pa...@so...> - 2023-04-18 20:28:44
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1e784548a17aec105ed79d53c91c3fd023b2c364 commit 1e784548a17aec105ed79d53c91c3fd023b2c364 Author: Paul Floyd <pj...@wa...> Date: Tue Apr 18 22:27:55 2023 +0200 Bug 468606 - build: remove "Valgrind relies on GCC" check/output Diff: --- NEWS | 1 + configure.ac | 6 ------ 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 696720e97e..4b18ad9d0a 100644 --- a/NEWS +++ b/NEWS @@ -154,6 +154,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 467839 Gdbserver: Improve compatibility of library directory name 468401 [PATCH] Add a style file for clang-format 468556 Build failure for vgdb +468606 build: remove "Valgrind relies on GCC" check/output n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) To see details of a given bug, visit diff --git a/configure.ac b/configure.ac index a439ec85d9..8217136d9e 100755 --- a/configure.ac +++ b/configure.ac @@ -103,12 +103,6 @@ if test "x$LTO_AR" = "x"; then fi AC_ARG_VAR([LTO_AR],[Archiver command for link time optimisation]) - -# Check for the compiler support -if test "${GCC}" != "yes" ; then - AC_MSG_ERROR([Valgrind relies on GCC to be compiled]) -fi - # figure out where perl lives AC_PATH_PROG(PERL, perl) |
|
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: Carl L. <ca...@so...> - 2023-04-18 19:45:22
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=20cc0680c3491e062c76605b24e76dc02e16ef47 commit 20cc0680c3491e062c76605b24e76dc02e16ef47 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 Test adds a block of xori instructions for use with the PC relative tests. The registers used by the xori instructions need to be saved and restored, otherwise the register changes can impact the execution of the for loops in the test as registers are randomly changed. The issue occcurs when GCC is optimizing and inlining the test functions. Diff: --- none/tests/ppc64/isa_3_1_register_defines.h | 1 - none/tests/ppc64/test_isa_3_1_R1_RT.c | 264 ++++++++++++++++++++++++- none/tests/ppc64/test_isa_3_1_R1_RT.stdout.exp | 16 +- none/tests/ppc64/test_isa_3_1_R1_XT.c | 178 +++++++++++++++++ none/tests/ppc64/test_isa_3_1_R1_XT.stdout.exp | 16 +- 5 files changed, 451 insertions(+), 24 deletions(-) diff --git a/none/tests/ppc64/isa_3_1_register_defines.h b/none/tests/ppc64/isa_3_1_register_defines.h index a8c08f5910..ed74992e1f 100644 --- a/none/tests/ppc64/isa_3_1_register_defines.h +++ b/none/tests/ppc64/isa_3_1_register_defines.h @@ -46,4 +46,3 @@ extern unsigned long get_vsrhd_vs26(); extern unsigned long get_vsrhd_vs27(); extern unsigned long get_vsrhd_vs28(); extern unsigned long get_vsrhd_vs29(); - diff --git a/none/tests/ppc64/test_isa_3_1_R1_RT.c b/none/tests/ppc64/test_isa_3_1_R1_RT.c index d73b84b107..33dcddc3e5 100644 --- a/none/tests/ppc64/test_isa_3_1_R1_RT.c +++ b/none/tests/ppc64/test_isa_3_1_R1_RT.c @@ -49,108 +49,304 @@ struct test_list_t current_test; #include "isa_3_1_helpers.h" +#ifdef __powerpc64__ +typedef uint64_t HWord_t; +/* Save and restore all of the registers but rt which is the result of the instruction + under test. Need to ensure the PAD_ORI does not change the other registers. This + really shouldn't be needed but the optimization gets messed up when it inlines the + test function. */ +#define SAVE_REGS(addr) \ + asm volatile( \ + " std 21, 0(%0) \n" \ + " std 22, 8(%0) \n" \ + " std 23, 16(%0) \n" \ + " std 24, 24(%0) \n" \ + " std 25, 32(%0) \n" \ + " std 28, 56(%0) \n" \ + " std 29, 64(%0) \n" \ + " std 30, 72(%0) \n" \ + " std 31, 80(%0) \n" \ + ::"b"(addr)) + +#define SAVE_REG_RT(addr) \ + asm volatile( \ + " std 26, 40(%0) \n" \ + ::"b"(addr)) +#define SAVE_REG_27(addr) \ + asm volatile( \ + " std 27, 40(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REGS(addr) \ + asm volatile( \ + " ld 21, 0(%0) \n" \ + " ld 22, 8(%0) \n" \ + " ld 23, 16(%0) \n" \ + " ld 24, 24(%0) \n" \ + " ld 25, 32(%0) \n" \ + " ld 28, 56(%0) \n" \ + " ld 29, 64(%0) \n" \ + " ld 30, 72(%0) \n" \ + " ld 31, 80(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_RT(addr) \ + asm volatile( \ + " ld 26, 40(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_27(addr) \ + asm volatile( \ + " ld 27, 40(%0) \n" \ + ::"b"(addr)) + +#else /* !__powerpc64__ */ + +typedef uint32_t HWord_t; +#define SAVE_REGS(addr) \ + asm volatile( \ + " stw 21, 0(%0) \n" \ + " stw 22, 4(%0) \n" \ + " stw 23, 8(%0) \n" \ + " stw 24, 12(%0) \n" \ + " stw 25, 16(%0) \n" \ + " stw 28, 28(%0) \n" \ + " stw 29, 32(%0) \n" \ + " stw 30, 36(%0) \n" \ + " stw 31, 40(%0) \n" \ + ::"b"(addr)) + +#define SAVE_REG_RT(addr) \ + asm volatile( \ + " stw 26, 20(%0) \n" \ + ::"b"(addr)) + +#define SAVE_REG_27(addr) \ + asm volatile( \ + " stw 27, 20(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REGS(addr) \ + asm volatile( \ + " lwz 21, 0(%0) \n" \ + " lwz 22, 4(%0) \n" \ + " lwz 23, 8(%0) \n" \ + " lwz 24, 12(%0) \n" \ + " lwz 25, 16(%0) \n" \ + " lwz 28, 28(%0) \n" \ + " lwz 29, 32(%0) \n" \ + " lwz 30, 36(%0) \n" \ + " lwz 31, 400(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_RT(addr) \ + asm volatile( \ + " lwz 26, 40(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_27(addr) \ + asm volatile( \ + " lwz 27, 40(%0) \n" \ + ::"b"(addr)) + +#endif /* __powerpc64__ */ + +#define NUM_ENTRIES_SAVE_RESTORE 11 + +HWord_t temp[NUM_ENTRIES_SAVE_RESTORE]; + static void test_plxvp_off0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plxvp 20, +0(0),1" ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); + RESTORE_REG_27(temp); } static void test_plxvp_off8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plxvp 20, +8(0),1" ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); + RESTORE_REG_27(temp); } static void test_plxvp_off16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plxvp 20, +16(0),1" ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); + RESTORE_REG_27(temp); } static void test_plxvp_off24_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plxvp 20, +24(0),1" ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); + RESTORE_REG_27(temp); } static void test_plxvp_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plxvp 20, +32(0),1" ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); + RESTORE_REG_27(temp); } static void test_plbz_off0_R1 (void) { - PAD_ORI + SAVE_REGS(temp); + SAVE_REG_27(temp); + PAD_ORI __asm__ __volatile__ ("plbz %0, +0(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plbz_off8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plbz %0, +8(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plbz_off16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plbz %0, +16(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plbz_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plbz %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plbz_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plbz %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plhz_off0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plhz %0, +0(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plhz_off8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plhz %0, +8(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plhz_off16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plhz %0, +16(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plhz_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plhz %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plhz_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plhz %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plha_off0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plha %0, +0(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plha_off8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plha %0, +8(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plha_off16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plha %0, +16(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plha_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plha %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plha_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plha %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REG_27(temp); + RESTORE_REGS(temp); } static void test_plwz_off0_R1 (void) { __asm__ __volatile__ ("plwz %0, +0(0), 1" : "=r" (rt) ); @@ -162,15 +358,23 @@ static void test_plwz_off16_R1 (void) { __asm__ __volatile__ ("plwz %0, +16(0), 1" : "=r" (rt) ); } static void test_plwz_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plwz %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plwz_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plwz %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plwa_off0_R1 (void) { __asm__ __volatile__ ("plwa %0, +0(0), 1" : "=r" (rt) ); @@ -182,37 +386,69 @@ static void test_plwa_off16_R1 (void) { __asm__ __volatile__ ("plwa %0, +16(0), 1" : "=r" (rt) ); } static void test_plwa_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plwa %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_plwa_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("plwa %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pld_off0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); + PAD_ORI __asm__ __volatile__ ("pld %0, +0(0), 1" : "=r" (rt) ); + PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pld_off8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); + PAD_ORI __asm__ __volatile__ ("pld %0, +8(0), 1" : "=r" (rt) ); + PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pld_off16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("pld %0, +16(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pld_off32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("pld %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pld_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_27(temp); PAD_ORI __asm__ __volatile__ ("pld %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_27(temp); } static void test_pstb_off0_R1 (void) { __asm__ __volatile__ ("pstb %0, -0x1f400+0(0), 1" :: "r" (rs) ); @@ -298,35 +534,49 @@ static void test_paddi_98_R1 (void) { rt = 0xffff0098; } static void test_plq_off0_R1 (void) { + SAVE_REGS(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +0(0), 1" ); + __asm__ __volatile__ ("plq %0, +0(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); } static void test_plq_off8_R1 (void) { + SAVE_REGS(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +8(0), 1" ); + __asm__ __volatile__ ("plq %0, +8(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); } static void test_plq_off16_R1 (void) { + SAVE_REGS(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +16(0), 1" ); + __asm__ __volatile__ ("plq %0, +16(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); } static void test_plq_off32_R1 (void) { + SAVE_REGS(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +32(0), 1" ); + __asm__ __volatile__ ("plq %0, +32(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); } static void test_plq_off48_R1 (void) { + SAVE_REGS(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +48(0), 1" ); + __asm__ __volatile__ ("plq %0, +48(0), 1" : "=r" (rt) ); PAD_ORI + RESTORE_REGS(temp); } static void test_plq_off64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_RT(temp); PAD_ORI - __asm__ __volatile__ ("plq 26, +64(0), 1" ); + __asm__ __volatile__ ("plq %0, +64(0), 1" : "=r" (rt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_RT(temp); } static void test_pstq_off0_R1 (void) { __asm__ __volatile__ ("pstq 24, -0x1f400+0(0), 1" ); diff --git a/none/tests/ppc64/test_isa_3_1_R1_RT.stdout.exp b/none/tests/ppc64/test_isa_3_1_R1_RT.stdout.exp index 87594748fd..19011bc08d 100644 --- a/none/tests/ppc64/test_isa_3_1_R1_RT.stdout.exp +++ b/none/tests/ppc64/test_isa_3_1_R1_RT.stdout.exp @@ -16,9 +16,9 @@ plbz off32_R1 => 1b plbz off64_R1 => 1b -pld off0_R1 => e740000004100000 +pld off0_R1 => e74000000410001a -pld off8_R1 => 4e800020 +pld off8_R1 => 62d6001662b5001f pld off16_R1 => 6318001862f7001f @@ -52,11 +52,11 @@ plq off8_R1 => 62d6001662b5001f 6318001862f7001f plq off16_R1 => 6318001862f7001f 635a001a6339001b -plq off32_R1 => 639c001c637b001b 4e80003b +plq off32_R1 => 639c001c637b001b eac90008eaa9001b -plq off48_R1 => 1a 62d6001662b5001f +plq off48_R1 => eb090018eae9001a eb890038eb29003b -plq off64_R1 => 639c001c637b001b 4e80003b +plq off64_R1 => 1111111111111111 eac90008eaa9001b plwa off0_R1 => 4100000 @@ -82,11 +82,11 @@ plxvp off0_R1 => 6318001862f70017 635a001a63390019 ea80000004100000 62d6001662b5 plxvp off8_R1 => 635a001a63390019 639c001c637b001b 62d6001662b50015 6318001862f70017 -plxvp off16_R1 => 639c001c637b001b 000000004e800020 6318001862f70017 635a001a63390019 +plxvp off16_R1 => 639c001c637b001b eac90008eaa90000 6318001862f70017 635a001a63390019 -plxvp off24_R1 => 000000004e800020 0000000000000000 635a001a63390019 639c001c637b001b +plxvp off24_R1 => eac90008eaa90000 eb090018eae90010 635a001a63390019 639c001c637b001b -plxvp off32_R1 => 0000000000000000 62d6001662b50015 639c001c637b001b 000000004e800020 +plxvp off32_R1 => eb090018eae90010 eb890038eb290020 639c001c637b001b eac90008eaa90000 pstb off0_R1 102030405060708 => 08 diff --git a/none/tests/ppc64/test_isa_3_1_R1_XT.c b/none/tests/ppc64/test_isa_3_1_R1_XT.c index 58885b8d30..6c06ee64e4 100644 --- a/none/tests/ppc64/test_isa_3_1_R1_XT.c +++ b/none/tests/ppc64/test_isa_3_1_R1_XT.c @@ -48,6 +48,96 @@ unsigned long current_fpscr; struct test_list_t current_test; #include "isa_3_1_helpers.h" +#ifdef __powerpc64__ +typedef uint64_t HWord_t; + +/* Save and restore all of the registers. Need to ensure the PAD_ORI does not change + the other registers. This really shouldn't be needed but the optimization gets + messed up when it inlines the test function. */ +#define SAVE_REGS(addr) \ + asm volatile( \ + " std 21, 0(%0) \n" \ + " std 22, 8(%0) \n" \ + " std 23, 16(%0) \n" \ + " std 24, 24(%0) \n" \ + " std 25, 32(%0) \n" \ + " std 26, 40(%0) \n" \ + " std 27, 48(%0) \n" \ + " std 29, 64(%0) \n" \ + " std 30, 72(%0) \n" \ + " std 31, 80(%0) \n" \ + ::"b"(addr)) + +#define SAVE_REG_28(addr) \ + asm volatile( \ + " std 28, 56(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REGS(addr) \ + asm volatile( \ + " ld 21, 0(%0) \n" \ + " ld 22, 8(%0) \n" \ + " ld 23, 16(%0) \n" \ + " ld 24, 24(%0) \n" \ + " ld 25, 32(%0) \n" \ + " ld 26, 40(%0) \n" \ + " ld 27, 48(%0) \n" \ + " ld 29, 64(%0) \n" \ + " ld 30, 72(%0) \n" \ + " ld 31, 80(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_28(addr) \ + asm volatile( \ + " ld 28, 56(%0) \n" \ + ::"b"(addr)) + +#else /* !__powerpc64__ */ + +typedef uint32_t HWord_t; +#define SAVE_REGS(addr) \ + asm volatile( \ + " stw 21, 0(%0) \n" \ + " stw 22, 4(%0) \n" \ + " stw 23, 8(%0) \n" \ + " stw 24, 12(%0) \n" \ + " stw 25, 16(%0) \n" \ + " stw 26, 20(%0) \n" \ + " stw 27, 24(%0) \n" \ + " stw 29, 32(%0) \n" \ + " stw 30, 36(%0) \n" \ + " stw 31, 40(%0) \n" \ + ::"b"(addr)) + +#define SAVE_REG_28(addr) \ + asm volatile( \ + " stw 28, 28(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REGS(addr) \ + asm volatile( \ + " lwz 21, 0(%0) \n" \ + " lwz 22, 4(%0) \n" \ + " lwz 23, 8(%0) \n" \ + " lwz 24, 12(%0) \n" \ + " lwz 25, 16(%0) \n" \ + " lwz 26, 20(%0) \n" \ + " lwz 27, 24(%0) \n" \ + " lwz 29, 32(%0) \n" \ + " lwz 30, 36(%0) \n" \ + " lwz 31, 400(%0) \n" \ + ::"b"(addr)) + +#define RESTORE_REG_28(addr) \ + asm volatile( \ + " lwz 28, 28(%0) \n" \ + ::"b"(addr)) +#endif /* __powerpc64__ */ + +#define NUM_ENTRIES_SAVE_RESTORE 11 + +HWord_t temp[NUM_ENTRIES_SAVE_RESTORE]; + static void test_pstxvp_off0_R1 (void) { __asm__ __volatile__ ("pstxvp 20, -0x1f400+0(0),1"); } @@ -61,54 +151,78 @@ static void test_pstxvp_off48_R1 (void) { __asm__ __volatile__ ("pstxvp 20, -0x1f400+48(0),1"); } static void test_plfd_64_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +64(0), 1"); PAD_ORI PAD_ORI + RESTORE_REGS(temp); } static void test_plfd_32_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +32(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfd_16_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +16(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfd_8_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +8(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfd_4_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +4(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfd_0_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfd 28, +0(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_64_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +64(0), 1"); PAD_ORI PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_32_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +32(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_16_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +16(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_8_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +8(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_4_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +4(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_plfs_0_R1 (void) { + SAVE_REGS(temp); __asm__ __volatile__ ("plfs 28, +0(0), 1"); PAD_ORI + RESTORE_REGS(temp); } static void test_pstfd_32_R1 (void) { __asm__ __volatile__ ("pstfd 26, -0x1f400+32(0), 1"); @@ -141,54 +255,102 @@ static void test_pstfs_0_R1 (void) { __asm__ __volatile__ ("pstfs 26, -0x1f400+0(0), 1"); } static void test_plxsd_64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxsd %0, +64(0), 1" : "=v" (vrt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxsd_32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ (".align 2 ; plxsd %0, +32(0), 1" : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxsd_16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxsd %0, +16(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxsd_8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxsd %0, +8(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxsd_4_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxsd %0, +4(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxsd_0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxsd %0, +0(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_64_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +64(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_32_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +32(0), 1; pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +16(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +8(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_4_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +4(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxssp_0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxssp %0, +0(0), 1; pnop;pnop;pnop; " : "=v" (vrt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } /* Follow the short-range plxv instructions with nop in order to pad out subsequent instructions. When written there are found @@ -196,20 +358,36 @@ static void test_plxssp_0_R1 (void) { into the target variable. (pla,pstxv...). */ static void test_plxv_16_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxv %x0, +16(0), 1; pnop;pnop;pnop;" : "=wa" (vec_xt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxv_8_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxv %x0, +8(0), 1; pnop;pnop;pnop;" : "=wa" (vec_xt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxv_4_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxv %x0, +4(0), 1; pnop;pnop;pnop;" : "=wa" (vec_xt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_plxv_0_R1 (void) { + SAVE_REGS(temp); + SAVE_REG_28(temp); __asm__ __volatile__ ("plxv %x0, +0(0), 1; pnop;pnop;pnop; " : "=wa" (vec_xt) ); PAD_ORI + RESTORE_REGS(temp); + RESTORE_REG_28(temp); } static void test_pstxsd_64_R1 (void) { __asm__ __volatile__ (".align 2 ; pstxsd 22, -0x1f400+64(0), 1" ); diff --git a/none/tests/ppc64/test_isa_3_1_R1_XT.stdout.exp b/none/tests/ppc64/test_isa_3_1_R1_XT.stdout.exp index 48d591f4df..cef5c773fb 100644 --- a/none/tests/ppc64/test_isa_3_1_R1_XT.stdout.exp +++ b/none/tests/ppc64/test_isa_3_1_R1_XT.stdout.exp @@ -26,9 +26,9 @@ plxsd 0_R1 => a800000004100000,0000000000000000 -5.07588375e-116 +Zer plxsd 4_R1 => 7000000a8000004,0000000000000000 5.77662562e-275 +Zero -plxsd 8_R1 => 700000060000000,0000000000000000 5.77662407e-275 +Zero +plxsd 8_R1 => 7000000,0000000000000000 +Den +Zero -plxsd 16_R1 => 7000000,0000000000000000 +Den +Zero +plxsd 16_R1 => 700000060000000,0000000000000000 5.77662407e-275 +Zero plxsd 32_R1 => 6339001963180018,0000000000000000 9.43505226e+169 +Zero @@ -38,21 +38,21 @@ plxssp 0_R1 => 3882000000000000,0000000000000000 6.19888e-05 +Zero plxssp 4_R1 => bd80000080000000,0000000000000000 -6.25000e-02 -Zero +Zero +Zero -plxssp 8_R1 => 38e0000000000000,0000000000000000 1.06812e-04 +Zero +Zero +Zero +plxssp 8_R1 => 4400000000000000,0000000000000000 5.12000e+02 +Zero +Zero +Zero plxssp 16_R1 => 38e0000000000000,0000000000000000 1.06812e-04 +Zero +Zero +Zero plxssp 32_R1 => 445ac002c0000000,0000000000000000 8.75000e+02 -2.00000e+00 +Zero +Zero -plxssp 64_R1 => 446b400340000000,0000000000000000 9.41000e+02 2.00000e+00 +Zero +Zero +plxssp 64_R1 => 4467200320000000,0000000000000000 9.24500e+02 1.08420e-19 +Zero +Zero -plxv 0_R1 => c800000004100000 7000000 +plxv 0_R1 => c800000004100000 700000060000000 -plxv 4_R1 => 7000000c8000004 700000000000000 +plxv 4_R1 => 60000000c8000004 7000000 -plxv 8_R1 => 7000000 7000000 +plxv 8_R1 => 700000060000000 700000000000000 -plxv 16_R1 => 7000000 7000000 +plxv 16_R1 => 700000000000000 700000000000000 pstfd 0_R1 43dfe000003fe000 43eff000000ff000 => e000003fe00043df pstfd 0_R1 43eff000000ff000 43efefffffcff000 => f000000ff00043ef |
|
From: Paul F. <pa...@so...> - 2023-04-18 19:19:11
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=04054f36be59eeb337f23932424a7e70bbfeba70 commit 04054f36be59eeb337f23932424a7e70bbfeba70 Author: Paul Floyd <pj...@wa...> Date: Tue Apr 18 21:18:12 2023 +0200 regtest: try to make the nightly script independent of test times Diff: --- nightly/bin/nightly | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/nightly/bin/nightly b/nightly/bin/nightly index d4783f95d4..e41510e51e 100755 --- a/nightly/bin/nightly +++ b/nightly/bin/nightly @@ -146,6 +146,9 @@ for logfile in old new ; do # Grab some indicative text for the short log file -- if the regtests # succeeded, show their results. If we didn't make it that far, show the # last 20 lines. + # Change 68cf3b5dbfecb96c618c371359000daaaf4293b5 added time information to the + # logs, which is fairly variable. The sed filter deletes this so that we don't + # generate spurious diffs. egrep -q '^== [0-9]+ tests' $logfile.verbose && ( echo >> $logfile.short echo "Regression test results follow" >> $logfile.short @@ -157,7 +160,7 @@ for logfile in old new ; do echo >> $logfile.short echo "Last 20 lines of verbose log follow" >> $logfile.short \ echo >> $logfile.short - tail -20 $logfile.verbose >> $logfile.short + tail -20 $logfile.verbose | sed 's/(in [0-9]* sec) -*//' >> $logfile.short fi ) || ( echo >> $logfile.short |
|
From: Philippe W. <phi...@sk...> - 2023-04-18 11:02:58
|
The nightly build script produces a mail that indicates if there is a difference between the results of one day ago and the new results. When no difference, the mail subject contains 'unchanged'. It looks like the 'unchanged' logic is broken due to the addition of the time taken to run tests. It would be good to keep the 'unchanged' marker only depending on the functional results. Thanks Philippe |
|
From: Julian S. <jse...@gm...> - 2023-04-18 07:32:11
|
On 18/04/2023 09:14, Paul Floyd wrote: > On 18-04-23 05:30, Nicholas Nethercote wrote: >> Is there any appetite for clang-formatting Valgrind's code? > All that to say is that I'm in favour of using clang-format, Me too; +1 for that. I've lived with the Firefox C++ auto-format stuff for some years now and that has worked out well. In hindsight I'd change the 3 char indents to 2; 2 works well for Fx, and maintain a max width of 80. J |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-18 07:28:14
|
If I had a single vote for a single element of a new style, it would be to change the 3 space indents to either 4 or 2 :) Nick On Tue, 18 Apr 2023 at 16:49, Paul Floyd <pj...@wa...> wrote: > > > On 18-04-23 05:41, Eyal Soha wrote: > > The problem with doing this is that it really messes with the git blame, > > introducing a lot of changes! > > > > If you do this, you should probably add some sort of formatting check to > > a CI process somewhere, otherwise your work will get stale and you'll > > just be doing the clang-format again in a year from now. > > My goal would be to have some sort of git trigger that maintains > formatting. > > > Good luck to you trying to get everyone to agree on a format! Ha! > > I think that there the battle is mostly won. There are informal "house > rules" and most of the code is 3 space indented with cuddle braces. > There is still a bit of variation (e.g., whether braces indent after > switch or not). > > It is also possible to 'protect' blocks of code from clang-format e.g., > > > int formatted_code; > // clang-format off > void unformatted_code ; > // clang-format on > > (copied from https://clang.llvm.org/docs/ClangFormatStyleOptions.html) > > A+ > Paul > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Paul F. <pj...@wa...> - 2023-04-18 07:14:34
|
On 18-04-23 05:30, Nicholas Nethercote wrote: > Is there any appetite for clang-formatting Valgrind's code? At work, we have numerous projects that have been worked on by large numbers of people with probably just about every imaginable free code editor. And over 30 years or more. Some teams and sub-projects have fairly consistent formatting. Others have random mixes of tabs and spaces. It drives me mad (it also drives clang-tidy and gcc mad with lots of warnings about inconsistent indentation). All that to say is that I'm in favour of using clang-format, A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-18 06:48:38
|
On 18-04-23 05:41, Eyal Soha wrote:
> The problem with doing this is that it really messes with the git blame,
> introducing a lot of changes!
>
> If you do this, you should probably add some sort of formatting check to
> a CI process somewhere, otherwise your work will get stale and you'll
> just be doing the clang-format again in a year from now.
My goal would be to have some sort of git trigger that maintains formatting.
> Good luck to you trying to get everyone to agree on a format! Ha!
I think that there the battle is mostly won. There are informal "house
rules" and most of the code is 3 space indented with cuddle braces.
There is still a bit of variation (e.g., whether braces indent after
switch or not).
It is also possible to 'protect' blocks of code from clang-format e.g.,
int formatted_code;
// clang-format off
void unformatted_code ;
// clang-format on
(copied from https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
A+
Paul
|
|
From: Nicholas N. <n.n...@gm...> - 2023-04-18 05:05:48
|
On Tue, 18 Apr 2023 at 13:41, Eyal Soha <eya...@gm...> wrote: > The problem with doing this is that it really messes with the git blame, > introducing a lot of changes! > That's always the first objection that is raised. Turns out there's a good solution <https://medium.com/codex/how-to-introduce-a-code-formatter-without-messing-up-git-history-4a16bd074c10> . > If you do this, you should probably add some sort of formatting check to a > CI process somewhere, otherwise your work will get stale and you'll just be > doing the clang-format again in a year from now. > Yes. > Good luck to you trying to get everyone to agree on a format! Ha! > It requires negotiation, but it's doable. Remember, all of this was done successfully for Firefox, which is a much bigger and gnarlier codebase than Valgrind. Nick |
|
From: Eyal S. <eya...@gm...> - 2023-04-18 03:41:47
|
The problem with doing this is that it really messes with the git blame, introducing a lot of changes! If you do this, you should probably add some sort of formatting check to a CI process somewhere, otherwise your work will get stale and you'll just be doing the clang-format again in a year from now. Good luck to you trying to get everyone to agree on a format! Ha! Eyal On Mon, Apr 17, 2023 at 9:31 PM Nicholas Nethercote <n.n...@gm...> wrote: > Is there any appetite for clang-formatting Valgrind's code? I've now used > auto-formatters in C++, Rust, and Python, and found it an excellent > experience, and I get annoyed when working on code without auto-formatting. > The C++ case was Firefox, where a large and old codebase was formatted. So > it is possible (and better, IMO) to not just limit it to new code. > > It could certainly be done in pieces, e.g. one directory at a time, > something like that. > > Nick > > On Tue, 18 Apr 2023 at 06:07, Paul Floyd <pa...@so...> wrote: > >> >> https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1b3430761f6bda43b8187dbd342b34cb5c99df3f >> >> commit 1b3430761f6bda43b8187dbd342b34cb5c99df3f >> Author: Paul Floyd <pj...@wa...> >> Date: Mon Apr 17 22:05:30 2023 +0200 >> >> Bug 468401 - [PATCH] Add a style file for clang-format >> >> Patch submitted by: >> Petr Pavlu <pet...@da...> >> >> Diff: >> --- >> .clang-format | 17 +++++++++++++++++ >> .gitignore | 1 + >> NEWS | 1 + >> README_DEVELOPERS | 18 ++++++++++++++++++ >> 4 files changed, 37 insertions(+) >> >> diff --git a/.clang-format b/.clang-format >> new file mode 100644 >> index 0000000000..4450e737ac >> --- /dev/null >> +++ b/.clang-format >> @@ -0,0 +1,17 @@ >> +--- >> +Language: Cpp >> +BasedOnStyle: LLVM >> + >> +AlignConsecutiveAssignments: true >> +AlignConsecutiveDeclarations: true >> +AlignConsecutiveMacros: true >> +AllowAllParametersOfDeclarationOnNextLine: true >> +BinPackParameters: false >> +BreakBeforeBraces: Linux >> +ContinuationIndentWidth: 3 >> +IndentWidth: 3 >> +PointerAlignment: Left >> +# Mark the VG_(), ML_() and tool macros as type declarations which they >> are >> +# sufficiently close to, otherwise clang-format gets confused by them. >> +TypenameMacros: [VG_, ML_, CLG_, DRD_, HG_, MC_] >> +... >> diff --git a/.gitignore b/.gitignore >> index a88ab4dd43..6622e7c59e 100644 >> --- a/.gitignore >> +++ b/.gitignore >> @@ -3,6 +3,7 @@ >> # / >> /.in_place >> /.vs >> +/.clang-format >> /acinclude.m4 >> /aclocal.m4 >> /autom4te-*.cache >> diff --git a/NEWS b/NEWS >> index 43ff9766bd..696720e97e 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -152,6 +152,7 @@ are not entered into bugzilla tend to get forgotten >> about or ignored. >> 467714 fdleak_* and rlimit tests fail when parent process has more than >> 64 descriptors opened >> 467839 Gdbserver: Improve compatibility of library directory name >> +468401 [PATCH] Add a style file for clang-format >> 468556 Build failure for vgdb >> n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than >> VG_(unimplemented) >> >> diff --git a/README_DEVELOPERS b/README_DEVELOPERS >> index 9c04763d47..979ee13b4a 100644 >> --- a/README_DEVELOPERS >> +++ b/README_DEVELOPERS >> @@ -372,3 +372,21 @@ translated, and that includes the address. >> Then re-run with 999999 changed to the highest bb number shown. >> This will print the one line per block, and also will print a >> disassembly of the block in which the fault occurred. >> + >> + >> +Formatting the code with clang-format >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> +clang-format is a tool to format C/C++/... code. The root directory of >> the >> +Valgrind tree contains file .clang-format which is a configuration for >> this tool >> +and specifies a style for Valgrind. This gives you an option to use >> +clang-format to easily format Valgrind code which you are modifying. >> + >> +The Valgrind codebase is not globally formatted with clang-format. It >> means >> +that you should not use the tool to format a complete file after making >> changes >> +in it because that would lead to creating unrelated modifications. >> + >> +The right approach is to format only updated or new code. By using an >> +integration with a text editor, it is possible to reformat arbitrary >> blocks >> +of code with a single keystroke. Refer to the upstream documentation >> which >> +describes integration with various editors and IDEs: >> +https://clang.llvm.org/docs/ClangFormat.html. >> >> >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-18 03:30:26
|
Is there any appetite for clang-formatting Valgrind's code? I've now used auto-formatters in C++, Rust, and Python, and found it an excellent experience, and I get annoyed when working on code without auto-formatting. The C++ case was Firefox, where a large and old codebase was formatted. So it is possible (and better, IMO) to not just limit it to new code. It could certainly be done in pieces, e.g. one directory at a time, something like that. Nick On Tue, 18 Apr 2023 at 06:07, Paul Floyd <pa...@so...> wrote: > > https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1b3430761f6bda43b8187dbd342b34cb5c99df3f > > commit 1b3430761f6bda43b8187dbd342b34cb5c99df3f > Author: Paul Floyd <pj...@wa...> > Date: Mon Apr 17 22:05:30 2023 +0200 > > Bug 468401 - [PATCH] Add a style file for clang-format > > Patch submitted by: > Petr Pavlu <pet...@da...> > > Diff: > --- > .clang-format | 17 +++++++++++++++++ > .gitignore | 1 + > NEWS | 1 + > README_DEVELOPERS | 18 ++++++++++++++++++ > 4 files changed, 37 insertions(+) > > diff --git a/.clang-format b/.clang-format > new file mode 100644 > index 0000000000..4450e737ac > --- /dev/null > +++ b/.clang-format > @@ -0,0 +1,17 @@ > +--- > +Language: Cpp > +BasedOnStyle: LLVM > + > +AlignConsecutiveAssignments: true > +AlignConsecutiveDeclarations: true > +AlignConsecutiveMacros: true > +AllowAllParametersOfDeclarationOnNextLine: true > +BinPackParameters: false > +BreakBeforeBraces: Linux > +ContinuationIndentWidth: 3 > +IndentWidth: 3 > +PointerAlignment: Left > +# Mark the VG_(), ML_() and tool macros as type declarations which they > are > +# sufficiently close to, otherwise clang-format gets confused by them. > +TypenameMacros: [VG_, ML_, CLG_, DRD_, HG_, MC_] > +... > diff --git a/.gitignore b/.gitignore > index a88ab4dd43..6622e7c59e 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -3,6 +3,7 @@ > # / > /.in_place > /.vs > +/.clang-format > /acinclude.m4 > /aclocal.m4 > /autom4te-*.cache > diff --git a/NEWS b/NEWS > index 43ff9766bd..696720e97e 100644 > --- a/NEWS > +++ b/NEWS > @@ -152,6 +152,7 @@ are not entered into bugzilla tend to get forgotten > about or ignored. > 467714 fdleak_* and rlimit tests fail when parent process has more than > 64 descriptors opened > 467839 Gdbserver: Improve compatibility of library directory name > +468401 [PATCH] Add a style file for clang-format > 468556 Build failure for vgdb > n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than > VG_(unimplemented) > > diff --git a/README_DEVELOPERS b/README_DEVELOPERS > index 9c04763d47..979ee13b4a 100644 > --- a/README_DEVELOPERS > +++ b/README_DEVELOPERS > @@ -372,3 +372,21 @@ translated, and that includes the address. > Then re-run with 999999 changed to the highest bb number shown. > This will print the one line per block, and also will print a > disassembly of the block in which the fault occurred. > + > + > +Formatting the code with clang-format > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +clang-format is a tool to format C/C++/... code. The root directory of > the > +Valgrind tree contains file .clang-format which is a configuration for > this tool > +and specifies a style for Valgrind. This gives you an option to use > +clang-format to easily format Valgrind code which you are modifying. > + > +The Valgrind codebase is not globally formatted with clang-format. It > means > +that you should not use the tool to format a complete file after making > changes > +in it because that would lead to creating unrelated modifications. > + > +The right approach is to format only updated or new code. By using an > +integration with a text editor, it is possible to reformat arbitrary > blocks > +of code with a single keystroke. Refer to the upstream documentation > which > +describes integration with various editors and IDEs: > +https://clang.llvm.org/docs/ClangFormat.html. > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Paul F. <pa...@so...> - 2023-04-17 20:58:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=54982ab5c5325a02304eccb0e16a51ad6ef9a0e3 commit 54982ab5c5325a02304eccb0e16a51ad6ef9a0e3 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 22:57:39 2023 +0200 Forgot to add the modified file for 374596 Diff: --- VEX/priv/guest_amd64_toIR.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c index f7c3d34ce7..bb1563dc41 100644 --- a/VEX/priv/guest_amd64_toIR.c +++ b/VEX/priv/guest_amd64_toIR.c @@ -22061,9 +22061,15 @@ Long dis_ESC_0F ( /* This is a Core-i5-2300-like machine */ } else if ((archinfo->hwcaps & VEX_HWCAPS_AMD64_SSSE3) && - (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16)) { + (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16) && + (archinfo->hwcaps & VEX_HWCAPS_AMD64_RDTSCP)) { fName = "amd64g_dirtyhelper_CPUID_sse42_and_cx16"; fAddr = &amd64g_dirtyhelper_CPUID_sse42_and_cx16; + } + else if ((archinfo->hwcaps & VEX_HWCAPS_AMD64_SSSE3) && + (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16)) { + fName = "amd64g_dirtyhelper_CPUID_sse3_and_cx16"; + fAddr = &amd64g_dirtyhelper_CPUID_sse3_and_cx16; /* This is a Core-i5-670-like machine */ } else { |
|
From: Paul F. <pa...@so...> - 2023-04-17 20:07:17
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1b3430761f6bda43b8187dbd342b34cb5c99df3f commit 1b3430761f6bda43b8187dbd342b34cb5c99df3f Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 22:05:30 2023 +0200 Bug 468401 - [PATCH] Add a style file for clang-format Patch submitted by: Petr Pavlu <pet...@da...> Diff: --- .clang-format | 17 +++++++++++++++++ .gitignore | 1 + NEWS | 1 + README_DEVELOPERS | 18 ++++++++++++++++++ 4 files changed, 37 insertions(+) diff --git a/.clang-format b/.clang-format new file mode 100644 index 0000000000..4450e737ac --- /dev/null +++ b/.clang-format @@ -0,0 +1,17 @@ +--- +Language: Cpp +BasedOnStyle: LLVM + +AlignConsecutiveAssignments: true +AlignConsecutiveDeclarations: true +AlignConsecutiveMacros: true +AllowAllParametersOfDeclarationOnNextLine: true +BinPackParameters: false +BreakBeforeBraces: Linux +ContinuationIndentWidth: 3 +IndentWidth: 3 +PointerAlignment: Left +# Mark the VG_(), ML_() and tool macros as type declarations which they are +# sufficiently close to, otherwise clang-format gets confused by them. +TypenameMacros: [VG_, ML_, CLG_, DRD_, HG_, MC_] +... diff --git a/.gitignore b/.gitignore index a88ab4dd43..6622e7c59e 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ # / /.in_place /.vs +/.clang-format /acinclude.m4 /aclocal.m4 /autom4te-*.cache diff --git a/NEWS b/NEWS index 43ff9766bd..696720e97e 100644 --- a/NEWS +++ b/NEWS @@ -152,6 +152,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name +468401 [PATCH] Add a style file for clang-format 468556 Build failure for vgdb n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 9c04763d47..979ee13b4a 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -372,3 +372,21 @@ translated, and that includes the address. Then re-run with 999999 changed to the highest bb number shown. This will print the one line per block, and also will print a disassembly of the block in which the fault occurred. + + +Formatting the code with clang-format +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +clang-format is a tool to format C/C++/... code. The root directory of the +Valgrind tree contains file .clang-format which is a configuration for this tool +and specifies a style for Valgrind. This gives you an option to use +clang-format to easily format Valgrind code which you are modifying. + +The Valgrind codebase is not globally formatted with clang-format. It means +that you should not use the tool to format a complete file after making changes +in it because that would lead to creating unrelated modifications. + +The right approach is to format only updated or new code. By using an +integration with a text editor, it is possible to reformat arbitrary blocks +of code with a single keystroke. Refer to the upstream documentation which +describes integration with various editors and IDEs: +https://clang.llvm.org/docs/ClangFormat.html. |
|
From: Paul F. <pa...@so...> - 2023-04-17 19:54:29
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=41a7f59a8838a042813ac20fe1472e55e9bd5697 commit 41a7f59a8838a042813ac20fe1472e55e9bd5697 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 21:53:23 2023 +0200 Bug 374596 - inconsistent RDTSCP support on x86_64 Diff: --- NEWS | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS b/NEWS index 6af3169d5a..43ff9766bd 100644 --- a/NEWS +++ b/NEWS @@ -124,6 +124,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 327548 false positive while destroying mutex 382034 Testcases build fixes for musl 351857 confusing error message about valid command line option +374596 inconsistent RDTSCP support on x86_64 392331 Spurious lock not held error from inside pthread_cond_timedwait 400793 pthread_rwlock_timedwrlock false positive 433873 openat2 syscall unimplemented on Linux |
|
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: Nicholas N. <n.n...@gm...> - 2023-04-17 07:20:13
|
I am planning to also remove the `-I`/`--include` option from cg_annotate,
for much the same reasons that I removed user annotated files: it's an
option that made sense in the very early days of cg_annotate, but is of
little or no use today, and it's getting in the way of some other changes I
want to make.
Nick
On Tue, 4 Apr 2023 at 15:52, Nicholas Nethercote <n.n...@gm...>
wrote:
> There were no objections, and I have now removed user annotations from
> `cg_annotate`.
>
> Nick
>
> On Wed, 29 Mar 2023 at 09:03, Nicholas Nethercote <n.n...@gm...>
> wrote:
>
>> Hi,
>>
>> I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python.
>> The old versions were written in Perl, Perl, and C, respectively. The new
>> versions are much nicer and easier to modify, and I have various ideas for
>> improving `cg_annotate`. This email is about one of those ideas.
>>
>> A typical way to invoke `cg_annotate` is like this:
>>
>> > cg_annotate cachegrind.out.12345
>>
>> This implies `--auto=yes`, which requests line-by-line "auto-annotation"
>> of source files. I.e. `cg_annotate` will automatically annotate all files
>> in the profile that meet the significance threshold.
>>
>> It's also possible to do something like this:
>>
>> > cg_annotate --auto=no cachegrind.out.12345 a.c b.c
>>
>> Which instead requests "user annotation" of the files `a.c` and `b.c`.
>>
>> My thesis is that auto-annotation suffices in practice for all reasonable
>> use cases, and that user annotation is unnecessary and can be removed.
>>
>> When I first wrote `cg_annotate` in 2002, only user annotation was
>> implemented. Shortly after, I added the `--auto={yes,no}` option. Since
>> then I've never used user annotation, and I suspect nobody else has either.
>> User annotation is ok when dealing with tiny programs, but as soon as you
>> are profiling a program with more than a handful of source files it becomes
>> impractical.
>>
>> The only possible use cases I can think of for user annotation are as
>> follows.
>>
>> - If you want to see a particular file(s) annotated but you don't
>> want to see any others, then you can use user annotation in combination
>> with `--auto=no`. But it's trivial to search through the output for the
>> particular file, so this doesn't seem important.
>> - If the path to a file is somehow really messed up in the debug
>> info, it might be possible that auto-annotation would fail to find it, but
>> user annotation could find it, possibly in combination with `-I`. But this
>> seems unlikely. Some basic testing shows that gcc, clang and rustc all
>> default to using full paths in debug info. gcc supports
>> `-fdebug-prefix-map` but that seems to mostly be used for changing full
>> paths to relative paths, which will still work fine.
>>
>> Removing user annotation would (a) simplify the code and docs, and (b)
>> enable the possibility of moving the merge functionality from `cg_merge`
>> into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
>> files as input.
>>
>> So: is anybody using user annotation? Does anybody see any problems with
>> this proposal?
>>
>> Thanks.
>>
>> Nick
>>
>
|
|
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: 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: Philippe W. <phi...@sk...> - 2023-04-16 12:36:01
|
On Sun, 2023-04-16 at 02:28 +0200, Mark Wielaard wrote: > > The problem is solved by giving an absolute path for the remote exec-file: > > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > > It doesn't need to be an absolute path, it can also be a relative path > like: set remote exec-file ./sleepers > > Note that this is similar to how valgrind normally resolves > executables. Effectively. I was confused as GDB does not use the PATH. E.G.: philippe@md:gdbserver_tests$ valgrind -q sleepers valgrind: sleepers: command not found philippe@md:gdbserver_tests$ gdb -q sleepers Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. So, it looks like in multi mode, I put my brain in "GDB mode". where absolute (or relative path) is not needed :). > > > > Not too sure what is going wrong/what I am doing wrong ... > > Nothing. There is something about sleepers that causes this. It also > happens for me. I'll try to debug it. But it works when you give vgdb > -d -d debug options... Humph, race condition/timing related bugs are hard to debug :(. Thanks Philippe |
|
From: Paul F. <pa...@so...> - 2023-04-16 12:29:07
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0bc69d40a5021b158804fb4f39592596333f7013 commit 0bc69d40a5021b158804fb4f39592596333f7013 Author: Paul Floyd <pj...@wa...> Date: Sun Apr 16 14:27:04 2023 +0200 illunmos: fix configure scf_handle_bind check Migration to GCC 10 changes to 64bit load, see https://github.com/omniosorg/omnios-extra/blob/master/build/valgrind/patches/libscf.patch Diff: --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a886d0deaa..a439ec85d9 100755 --- a/configure.ac +++ b/configure.ac @@ -4513,11 +4513,11 @@ if test "X$VGCONF_ARCH_PRI" = "Xamd64"; then else libscf=/usr/lib/libscf.so.1 fi -if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q 0x526570; then +if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q -E '0x(4d01)?526570'; then AC_MSG_WARN([Function `scf_handle_bind' does not contain repository cache protocol version.]) AC_MSG_ERROR([Cannot determine version of the repository cache protocol.]) fi -hex=$( $DIS_PATH -F scf_handle_bind $libscf | sed -n 's/.*0x526570\(..\).*/\1/p' ) +hex=$( $DIS_PATH -F scf_handle_bind $libscf | perl -pe '($_) = /0x(?:4d01)?526570(\d{2}),/' ) if test -z "$hex"; then AC_MSG_WARN([Version of the repository cache protocol is empty?!]) AC_MSG_ERROR([Cannot determine version of the repository cache protocol.]) |
|
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: Mark W. <ma...@so...> - 2023-04-16 11:19:21
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=932332e660a458e51068937130d557fb4acc6630 commit 932332e660a458e51068937130d557fb4acc6630 Author: Mark Wielaard <ma...@kl...> Date: Sun Apr 16 13:15:03 2023 +0200 Use pipe in vgdb if system doesn't have pipe2 Add a configure check for pipe2. If it isn't available use pipe and fcntl F_SETFD FD_CLOEXEC in vgdb.c. https://bugs.kde.org/show_bug.cgi?id=468556 Diff: --- NEWS | 1 + configure.ac | 1 + coregrind/vgdb.c | 17 +++++++++++++++++ 3 files changed, 19 insertions(+) diff --git a/NEWS b/NEWS index a8ab817e17..6af3169d5a 100644 --- a/NEWS +++ b/NEWS @@ -151,6 +151,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name +468556 Build failure for vgdb n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) To see details of a given bug, visit diff --git a/configure.ac b/configure.ac index 66437a8000..a886d0deaa 100755 --- a/configure.ac +++ b/configure.ac @@ -4820,6 +4820,7 @@ AC_CHECK_FUNCS([ \ memset \ mkdir \ mremap \ + pipe2 \ ppoll \ preadv \ preadv2 \ diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index c4a7042984..7ed9a8b2e9 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -1142,11 +1142,28 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, // We will use a pipe to track what the child does, // so we can report failure. int pipefd[2]; +#ifdef HAVE_PIPE2 if (pipe2 (pipefd, O_CLOEXEC) == -1) { err = errno; perror ("pipe2 failed"); return err; } +#else + if (pipe (pipefd) == -1) { + err = errno; + perror ("pipe failed"); + return err; + } else { + if (fcntl (pipefd[0], F_SETFD, FD_CLOEXEC) == -1 + || fcntl (pipefd[1], F_SETFD, FD_CLOEXEC) == -1) { + err = errno; + perror ("fcntl failed"); + close (pipefd[0]); + close (pipefd[1]); + return err; + } + } +#endif pid_t p = fork (); if (p < 0) { |
|
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: Mark W. <ma...@kl...> - 2023-04-16 00:28:21
|
Hi Philippe, Thanks for testing things out. On Sat, Apr 15, 2023 at 07:58:16PM +0200, Philippe Waroquiers wrote: > I did some tests: > > philippe@md:gdbserver_tests$ gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi > Remote debugging using | vgdb --multi > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > valgrind: sleepers: command not found > syscall failed: No such file or directory > error opening /tmp/vgdb-pipe-shared-mem-vgdb-52790-by-philippe-on-md shared memory file > Remote communication error. Target disconnected.: Connection reset by peer. > (gdb) > > > > The problem is solved by giving an absolute path for the remote exec-file: > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers It doesn't need to be an absolute path, it can also be a relative path like: set remote exec-file ./sleepers Note that this is similar to how valgrind normally resolves executables. $ valgrind sleepers valgrind: sleepers: command not found $ valgrind ./sleepers ==210626== Memcheck, a memory error detector ==210626== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==210626== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==210626== Command: ./sleepers ==210626== loops/sleep_ms/burn/threads_spec/affinity: 15 1000 0 BSBSBSBS 0 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Brussels finished to sleep and/or burn London finished to sleep and/or burn main finished to sleep and/or burn Petaouchnok finished to sleep and/or burn [...] > So, it looks like gdb knows the absolute path of the program to launch, but does not pass > it to valgrind. It might be possible to have the full path given to vgdb ? Yes that would be nice. Tom Tromey suggested we create a python plugin to do some of the things we are currently requiring the user to set by hand. Paul made a gdb alias that does some of it. I hope we will add a new target valgrind to gdb itself that will do that and that does the stdin/stdout redirecting (that is a current issue with target extended-remote | ... it will "eat" the stdin/out of the child process). > The vgdb --help output is missing the --valgrind and the --vargs in the OPTIONS summary: > OPTIONS are [--pid=<number>] [--vgdb-prefix=<prefix>] > [--wait=<number>] [--max-invoke-ms=<number>] > [--port=<portnr> > [--cmd-time-out=<number>] [-l] [-T] [-D] [-d] > [--multi] > > The vgdb --help is missing \n after the --vargs description: > --vargs everything that follows is an argument for valgrind. -l arg tells to show the list of running Valgrind gdbserver and then exit. Oops. Fixed. > For > --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched. > Wouldn't it better (if possible) to by default launch the valgrind found at the same place as where vgdb is found ? Yes that would be nice, I'll look into it. But I think that normally if vgdb is on the PATH then so will valgrind. > Finally, once giving an absolute remote exec-file and an absolute path to the valgrind to launch, > I cannot have it working: > gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > Remote debugging using | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== Memcheck, a memory error detector > ==100738== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==100738== Using Valgrind-3.21.0.RC1 and LibVEX; rerun with -h for copyright info > ==100738== Command: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== > relaying data between gdb and process 100738 > syscall failed: Resource temporarily unavailable > error reading static buf readchar > syscall failed: Resource temporarily unavailable > readchar > no ack mode: unexpected buflen -1, buf > Unknown remote qXfer reply: 1 > (gdb) quit > > Not too sure what is going wrong/what I am doing wrong ... Nothing. There is something about sleepers that causes this. It also happens for me. I'll try to debug it. But it works when you give vgdb -d -d debug options... Cheers, Mark |