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
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(6) |
|
2
(6) |
3
(9) |
4
(4) |
5
(1) |
6
|
7
|
8
|
|
9
|
10
(2) |
11
(1) |
12
(2) |
13
(4) |
14
(6) |
15
(8) |
|
16
(9) |
17
(5) |
18
(13) |
19
(6) |
20
(15) |
21
(17) |
22
(19) |
|
23
(2) |
24
(4) |
25
(2) |
26
(10) |
27
(6) |
28
(9) |
29
(3) |
|
30
|
|
|
|
|
|
|
|
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
>>
>
|