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
|
2
|
3
|
4
(1) |
5
(1) |
6
(3) |
7
|
|
8
(1) |
9
(10) |
10
(11) |
11
|
12
|
13
|
14
|
|
15
(1) |
16
(5) |
17
(1) |
18
|
19
|
20
|
21
(1) |
|
22
|
23
|
24
|
25
|
26
|
27
(1) |
28
|
|
29
|
30
(4) |
|
|
|
|
|
|
From: John R. <jr...@bi...> - 2020-11-16 21:45:04
|
> Then I noticed that there are 2 RW LOAD elf segments rather than just 1. Please post the output from "readelf --segments <<the_module_in_question>>" |
|
From: Paul F. <pj...@wa...> - 2020-11-16 20:10:57
|
Hi I've recently been working on Valgrind running on FreeBSD 12.2 (released 27 October). There were a few nits that were easy to fix, but also one bigger issue that was causing something like 50 failures. Today I debugged at least the point in the code where I can add a workaround. There were lots of DRD and Helgrind failures due to race conditions. There were also memcheck errors related to varinfo for global variables. Initially I suspected this was related to debuginfo (the default compiler switched from clang 8 to clang 10). But this doesn't seem to be the case. Then I noticed that there are 2 RW LOAD elf segments rather than just 1. Eventually I followed this path to ML_(read_elf_debug_info) where item.bias is calculated, and I noticed that in some cases the result was negative. The calculation is item.bias = map->avma - map->foff + a_phdr.p_offset - a_phdr.p_vaddr; if I clamp this to zero, then it seems to make the problem go away. Here's a trace that I added with an example output from drd/tests/bar_trivial which generates 2 race false positives. PT_LOAD[3]: calc bias avma 0x200000 foff 0x0 poff 0x8c0 vadd 0x2018c0 res bias -4096 PT_LOAD[5]: calc bias avma 0x202000 foff 0x0 poff 0x10d8 vadd 0x2040d8 res bias -4096 The 2 false positives look like the got.plt entries for 'sleep' and 'pthread_barrier_read', here is a readelf extract, and these addresses match the final log error messages (maybe I'm wrong and this is just a coincidence). 000000204128 000900000007 R_X86_64_JUMP_SLOT 0000000000000000 pthread_barrier_wait + 0 000000204138 000c00000007 R_X86_64_JUMP_SLOT 0000000000000000 sleep + 0 I can see that a_phdr.p_vaddr corresponds to the VirtAddr values that I see in the readelf Progam Headers table. a_phdr. p_offset is also read from the guest binary. map->avma is the start of the memory segment and map->foff its offset. I don't understand why 0x200000 since it looks to me like the two RW sements are getting loaded here --9344:1: aspacem 3: file 0000202000-0000203fff 8192 rw--- d=0x696e301b i=913176 o=0 (1,73) --9344:1: aspacem 4: file 0000204000-0000204fff 4096 rw--- d=0x696e301b i=913176 o=4096 (1,73) Does anyone have a suggestion as to what might be going wrong? My hunch is that this is related to there being 2 RW segments, but I haven't yet pinned it down. A+ Paul |
|
From: Carl L. <ca...@so...> - 2020-11-16 17:55:07
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=025bdca23b2fca0dd68b6077426500237aee85c5 commit 025bdca23b2fca0dd68b6077426500237aee85c5 Author: Carl Love <ce...@us...> Date: Thu Nov 12 15:18:23 2020 -0600 PowerPC, fix for conv_f16_to_double xscvhpdp assembler code The previous commit: commit eb82a294573d15c1be663673d55b559a82ca29d3 Author: Julian Seward <js...@ac...> Date: Tue Nov 10 21:10:48 2020 +0100 Add a missing ifdef, whose absence caused build breakage on non-POWER targets. fixed the compile issue in conv_f16_to_double() where non-Power platforms do not support the power xscvhpdp assembly instructions. The instruction is supported by ISA 3.0 platforms. Older Power platforms still fail to compile with the assembly instruction. This patch fixes the if def for power systems that do not support ISA 3.0. Diff: --- Makefile.all.am | 9 ++++++++- VEX/priv/guest_ppc_helpers.c | 2 +- configure.ac | 16 ++++++++++++++++ 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Makefile.all.am b/Makefile.all.am index 6d88670e05..1b65366715 100644 --- a/Makefile.all.am +++ b/Makefile.all.am @@ -123,6 +123,13 @@ AM_CFLAGS_BASE = \ -fno-strict-aliasing \ -fno-builtin +# Power ISA flag for use by guest_ppc_helpers.c +if HAS_XSCVHPDP +ISA_3_0_BUILD_FLAG = -DHAS_XSCVHPDP +else +ISA_3_0_BUILD_FLAG = +endif + if COMPILER_IS_CLANG AM_CFLAGS_BASE += -Wno-cast-align -Wno-self-assign \ -Wno-tautological-compare @@ -203,7 +210,7 @@ AM_CFLAGS_PSO_PPC64BE_LINUX = @FLAG_M64@ $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE) AM_CCASFLAGS_PPC64BE_LINUX = @FLAG_M64@ -g AM_FLAG_M3264_PPC64LE_LINUX = @FLAG_M64@ -AM_CFLAGS_PPC64LE_LINUX = @FLAG_M64@ $(AM_CFLAGS_BASE) +AM_CFLAGS_PPC64LE_LINUX = @FLAG_M64@ $(AM_CFLAGS_BASE) $(ISA_3_0_BUILD_FLAG) AM_CFLAGS_PSO_PPC64LE_LINUX = @FLAG_M64@ $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE) AM_CCASFLAGS_PPC64LE_LINUX = @FLAG_M64@ -g diff --git a/VEX/priv/guest_ppc_helpers.c b/VEX/priv/guest_ppc_helpers.c index ac4d7044a8..d2410d9537 100644 --- a/VEX/priv/guest_ppc_helpers.c +++ b/VEX/priv/guest_ppc_helpers.c @@ -1112,7 +1112,7 @@ static ULong reinterpret_double_as_long( Double input ) static Double conv_f16_to_double( ULong input ) { -# if defined(__powerpc__) +# if defined (HAS_XSCVHPDP) // This all seems to be very alignment sensitive?? __attribute__ ((aligned (64))) ULong src; __attribute__ ((aligned (64))) Double result; diff --git a/configure.ac b/configure.ac index f01dbff7fc..b837872918 100755 --- a/configure.ac +++ b/configure.ac @@ -1640,6 +1640,20 @@ ac_asm_have_isa_3_00=no AC_MSG_RESULT([no]) ]) +# xscvhpdp checking +AC_MSG_CHECKING([that assembler knows xscvhpdp ]) + +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ +]], [[ + __asm__ __volatile__("xscvhpdp 1,2 "); +]])], [ +ac_asm_have_xscvhpdp=yes +AC_MSG_RESULT([yes]) +], [ +ac_asm_have_xscvhpdp=no +AC_MSG_RESULT([no]) +]) + # isa 3.01 checking AC_MSG_CHECKING([that assembler knows ISA 3.1 ]) @@ -1658,6 +1672,8 @@ AC_MSG_RESULT([no]) AM_CONDITIONAL(HAS_ISA_3_00, [test x$ac_asm_have_isa_3_00 = xyes \ -a x$HWCAP_HAS_ISA_3_00 = xyes]) +AM_CONDITIONAL(HAS_XSCVHPDP, [test x$ac_asm_have_xscvhpdp = xyes]) + AM_CONDITIONAL(HAS_ISA_3_1, [test x$ac_asm_have_isa_3_1 = xyes \ -a x$HWCAP_HAS_ISA_3_1 = xyes]) |
|
From: Assad H. <ass...@li...> - 2020-11-16 11:50:04
|
Hello, The following fix patches are ready for review: https://bugs.kde.org/show_bug.cgi?id=414268 https://bugs.kde.org/show_bug.cgi?id=413547 Thanks |
|
From: Guido R. <gui...@gm...> - 2020-11-16 07:28:31
|
Thanks so much for your answers! And thanks again for the superlative project regards guido On Fri, Nov 6, 2020 at 3:09 PM John Reiser <jr...@bi...> wrote: > > > I tested the model on a x86 linux machine and profiled it with callgrind > > it worked perfectly. > > > > Now I would like to perform the same test on the embedded platform that is the real target of my work: this is a arm-m7 that runs freertos > > Don't bother. Instead run callgrind on a RaspberryPi running Linux. > The results will match within a couple percent. > (Callgrind, like any valgrind tool, covers only code that runs in user mode. > Each valgrind tool runs only one thread at a time. What you measure > is the algorithms used by the source code, and the goodness of the compiler.) > The results also will match within a couple percent of x86 Linux. > Porting valgrind to freertos will take several months. > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |