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
(11) |
|
2
|
3
|
4
|
5
(4) |
6
(21) |
7
(14) |
8
(14) |
|
9
(16) |
10
(19) |
11
(18) |
12
(17) |
13
(14) |
14
(21) |
15
(15) |
|
16
(10) |
17
(7) |
18
(15) |
19
(20) |
20
(20) |
21
(14) |
22
(7) |
|
23
(2) |
24
(8) |
25
(15) |
26
(11) |
27
(6) |
28
(10) |
|
|
From: Julian S. <js...@ac...> - 2014-02-26 17:08:34
|
On 02/26/2014 05:40 PM, Patrick J. LoPresti wrote: > It would be very interesting to see a micro-profile of Valgrind. Are you able to do that? Did you have any specific profiler in mind? J |
|
From: Patrick J. L. <lop...@gm...> - 2014-02-26 16:40:59
|
On Wed, Feb 26, 2014 at 7:16 AM, Julian Seward <js...@ac...> wrote: > > > What would make Valgrind faster is > > (1) improve the caching of guest registers in host registers across > basic block boundaries. Currently all guest registers cached in > host registers are flushed back into memory at block boundaries, > and no host register holds any live value across the boundary. > This is simple but very suboptimal, creating large amounts of > memory traffic. Sounds more like large amounts of L1 cache traffic. > I suspect that the combination of (1) and (2) causes processor write > buffers to fill up and start stalling, although I don't have numbers > to prove that. Maybe, but maybe not. (3) and (especially) (4) might well have greater impact. It is notoriously difficult to guess where a modern CPU is spending its time without a profiler. Random memory access is of course a disaster, but that sounds more like (4) than (1) or (2). It would be very interesting to see a micro-profile of Valgrind. - Pat |
|
From: Julian S. <js...@ac...> - 2014-02-26 15:32:15
|
On 02/26/2014 04:21 PM, Yan wrote: > For (3), would something like making all statements conditional (like > LoadG, StoreG, and Exit are) do, or are we talking about something more > complex? >> (3) add some level of control-flow if-then-else support to the IR, so >> that the fast-case paths for the memcheck helper functions >> (helperc_LOADV64le etc) can be generated inline. Something more complex: being able to add control-flow diamonds (if-then-else-merge) into the IR. Then, for example, the load-cases for Memcheck could be put inline: fast/slow case check before the diamond, the fast case code in the then branch, the slow case code calling a helper in the else branch. Doing control flow diamonds in IR means that both the IR optimiser and the register allocator will have to deal with control flow merges, which they don't at present. That would make them more complex, although not as complex as they would be if they had to deal with loops as well. J |
|
From: Yan <ya...@ya...> - 2014-02-26 15:21:51
|
For (3), would something like making all statements conditional (like LoadG, StoreG, and Exit are) do, or are we talking about something more complex? On Wed, Feb 26, 2014 at 7:16 AM, Julian Seward <js...@ac...> wrote: > > On 02/26/2014 12:23 PM, Kirill Batuzov wrote: > > I tend to agree with Kirill. It would be great to make Valgrind/Memcheck > faster, and there are certainly ways to do that, but using LLVM is not > one of them. > > > Second, in DBT you translate code in small portions like basic blocks, > > or extended basic blocks. They have very simple structure. There is no > > loops, there is no redundancy from translation high level language to > > low level. There is nothing good sophisticated optimizations can do > > better then very simple ones. > > Yes. One of the problems of the "Let's use LLVM and it'll all go much > faster" concept is that it lacks a careful analysis of what makes Valgrind > (and QEMU, probably) run slowly in the first place. > > As Kirill says, the short blocks of code that V generates make it > impossible for LLVM to do sophisticated loop optimisations etc. > Given what Valgrind's JIT has to work with -- straight line pieces > of code -- it generally does a not-bad job of instruction selection > and register allocation, and I wouldn't expect that substituting LLVM's > implementation thereof would make much of a difference. > > What would make Valgrind faster is > > (1) improve the caching of guest registers in host registers across > basic block boundaries. Currently all guest registers cached in > host registers are flushed back into memory at block boundaries, > and no host register holds any live value across the boundary. > This is simple but very suboptimal, creating large amounts of > memory traffic. > > (2) improve the way that the guest program counter is represented. > Currently it is updated before every memory access, so that if an > unwind is required, it is possible. But this again causes lots of > excess memory traffic. This is closely related to (1). > > (3) add some level of control-flow if-then-else support to the IR, so > that the fast-case paths for the memcheck helper functions > (helperc_LOADV64le etc) can be generated inline. > > (4) Redesign Memcheck's shadow memory implementation to use a 1 level > map rather than 2 levels as at present. Or something more > TLB-like. > > I suspect that the combination of (1) and (2) causes processor write > buffers to fill up and start stalling, although I don't have numbers > to prove that. What _is_ very obvious from profiling Memcheck using > Cachegrind is that the generated code contains much higher proportion > of memory references than "normal integer code". And in particular > it contains perhaps 4 times as many stores as "normal integer code". > Which can't be a good thing. > > (3) is a big exercise -- much work -- but potentially very beneficial. > (4) is also important if only because we need a multithreaded > implementation of Memcheck. (1) and (2) are smaller projects and would > constitute a refinement of the existing code generation framework. > > > In conclusion I second what have already been said: this project sounds > > like fun to do, but do not expect much practical results from it. > > The above projects (1) .. (4) would also be fun :-) and might generate more > immediate speedups for Valgrind. > > J > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Julian S. <js...@ac...> - 2014-02-26 15:17:14
|
On 02/26/2014 12:23 PM, Kirill Batuzov wrote:
I tend to agree with Kirill. It would be great to make Valgrind/Memcheck
faster, and there are certainly ways to do that, but using LLVM is not
one of them.
> Second, in DBT you translate code in small portions like basic blocks,
> or extended basic blocks. They have very simple structure. There is no
> loops, there is no redundancy from translation high level language to
> low level. There is nothing good sophisticated optimizations can do
> better then very simple ones.
Yes. One of the problems of the "Let's use LLVM and it'll all go much
faster" concept is that it lacks a careful analysis of what makes Valgrind
(and QEMU, probably) run slowly in the first place.
As Kirill says, the short blocks of code that V generates make it
impossible for LLVM to do sophisticated loop optimisations etc.
Given what Valgrind's JIT has to work with -- straight line pieces
of code -- it generally does a not-bad job of instruction selection
and register allocation, and I wouldn't expect that substituting LLVM's
implementation thereof would make much of a difference.
What would make Valgrind faster is
(1) improve the caching of guest registers in host registers across
basic block boundaries. Currently all guest registers cached in
host registers are flushed back into memory at block boundaries,
and no host register holds any live value across the boundary.
This is simple but very suboptimal, creating large amounts of
memory traffic.
(2) improve the way that the guest program counter is represented.
Currently it is updated before every memory access, so that if an
unwind is required, it is possible. But this again causes lots of
excess memory traffic. This is closely related to (1).
(3) add some level of control-flow if-then-else support to the IR, so
that the fast-case paths for the memcheck helper functions
(helperc_LOADV64le etc) can be generated inline.
(4) Redesign Memcheck's shadow memory implementation to use a 1 level
map rather than 2 levels as at present. Or something more
TLB-like.
I suspect that the combination of (1) and (2) causes processor write
buffers to fill up and start stalling, although I don't have numbers
to prove that. What _is_ very obvious from profiling Memcheck using
Cachegrind is that the generated code contains much higher proportion
of memory references than "normal integer code". And in particular
it contains perhaps 4 times as many stores as "normal integer code".
Which can't be a good thing.
(3) is a big exercise -- much work -- but potentially very beneficial.
(4) is also important if only because we need a multithreaded
implementation of Memcheck. (1) and (2) are smaller projects and would
constitute a refinement of the existing code generation framework.
> In conclusion I second what have already been said: this project sounds
> like fun to do, but do not expect much practical results from it.
The above projects (1) .. (4) would also be fun :-) and might generate more
immediate speedups for Valgrind.
J
|
|
From: Christian B. <bor...@de...> - 2014-02-26 11:34:58
|
valgrind revision: 13839 VEX revision: 2825 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29) Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1 C library: GNU C Library stable release version 2.11.3 (20110527) uname -mrs: Linux 3.0.101-0.8-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP3 gcc 4.3.4 on z196 (s390x) ) Started at 2014-02-26 08:47:14 CET Ended at 2014-02-26 12:34:45 CET Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 642 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_cond_destroy_busy (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 642 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable4 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) drd/tests/pth_barrier3 (stderr) drd/tests/pth_barrier_thr_cr (stderr) drd/tests/pth_create_chain (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short 2014-02-26 09:11:55.000000000 +0100 --- new.short 2014-02-26 09:30:08.000000000 +0100 *************** *** 8,16 **** ! == 642 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == ! memcheck/tests/err_disable4 (stderr) ! helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) - drd/tests/pth_barrier3 (stderr) - drd/tests/pth_barrier_thr_cr (stderr) - drd/tests/pth_create_chain (stderr) --- 8,11 ---- ! == 642 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_cond_destroy_busy (stderr) --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=5 --vg=../valgrind-new --vg=../valgrind-old -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 valgrind-new:0.22s no: 4.3s (19.6x, -----) me: 7.0s (31.6x, -----) ca:26.4s (119.9x, -----) he: 5.1s (23.0x, -----) ca: 9.1s (41.5x, -----) dr: 5.5s (25.0x, -----) ma: 4.7s (21.4x, -----) bigcode1 valgrind-old:0.22s no: 4.3s (19.5x, 0.7%) me: 6.9s (31.5x, 0.4%) ca:26.4s (119.9x, 0.0%) he: 5.1s (23.2x, -0.8%) ca: 9.1s (41.4x, 0.2%) dr: 5.5s (25.1x, -0.4%) ma: 4.7s (21.2x, 0.8%) -- bigcode2 -- bigcode2 valgrind-new:0.24s no: 7.2s (30.2x, -----) me:13.8s (57.6x, -----) ca:39.7s (165.5x, -----) he:10.1s (41.9x, -----) ca:14.2s (59.3x, -----) dr: 9.6s (40.1x, -----) ma: 8.1s (33.8x, -----) bigcode2 valgrind-old:0.24s no: 7.2s (30.0x, 0.4%) me:13.8s (57.3x, 0.6%) ca:39.6s (165.0x, 0.3%) he:10.1s (42.0x, -0.1%) ca:14.2s (59.0x, 0.6%) dr: 9.7s (40.4x, -0.6%) ma: 8.1s (33.7x, 0.5%) -- bz2 -- bz2 valgrind-new:0.70s no: 5.0s ( 7.2x, -----) me:13.0s (18.5x, -----) ca:30.7s (43.8x, -----) he:19.8s (28.2x, -----) ca:34.4s (49.1x, -----) dr:31.3s (44.7x, -----) ma: 3.6s ( 5.2x, -----) bz2 valgrind-old:0.70s no: 5.0s ( 7.1x, 1.0%) me:13.0s (18.6x, -0.4%) ca:30.6s (43.7x, 0.2%) he:19.6s (28.0x, 1.0%) ca:34.4s (49.2x, -0.1%) dr:29.2s (41.7x, 6.6%) ma: 4.0s ( 5.7x, -9.0%) -- fbench -- fbench valgrind-new:0.40s no: 1.6s ( 4.0x, -----) me: 4.2s (10.6x, -----) ca: 9.3s (23.2x, -----) he: 6.1s (15.2x, -----) ca: 7.3s (18.2x, -----) dr: 5.7s (14.3x, -----) ma: 1.7s ( 4.2x, -----) fbench valgrind-old:0.40s no: 1.6s ( 4.0x, 0.6%) me: 4.3s (10.7x, -0.9%) ca: 9.2s (23.1x, 0.2%) he: 6.1s (15.2x, 0.5%) ca: 7.3s (18.2x, -0.1%) dr: 5.5s (13.6x, 4.9%) ma: 1.7s ( 4.2x, -0.0%) -- ffbench -- ffbench valgrind-new:0.20s no: 1.0s ( 5.2x, -----) me: 3.0s (15.2x, -----) ca: 3.0s (15.1x, -----) he:43.5s (217.7x, -----) ca: 9.6s (48.1x, -----) dr: 6.9s (34.5x, -----) ma: 1.0s ( 4.8x, -----) ffbench valgrind-old:0.20s no: 1.0s ( 5.1x, 1.0%) me: 3.0s (15.2x, -0.3%) ca: 3.0s (15.1x, 0.0%) he:43.5s (217.7x, -0.0%) ca: 9.6s (48.1x, 0.1%) dr: 6.9s (34.4x, 0.4%) ma: 1.0s ( 4.8x, 0.0%) -- heap -- heap valgrind-new:0.23s no: 1.8s ( 7.7x, -----) me: 8.8s (38.4x, -----) ca:13.3s (57.7x, -----) he:12.6s (54.7x, -----) ca:11.2s (48.7x, -----) dr: 8.2s (35.6x, -----) ma: 7.8s (34.0x, -----) heap valgrind-old:0.23s no: 1.8s ( 7.7x, -0.6%) me: 8.7s (37.8x, 1.5%) ca:13.4s (58.1x, -0.8%) he:12.5s (54.4x, 0.6%) ca:11.2s (48.7x, -0.2%) dr: 7.6s (33.2x, 6.6%) ma: 7.9s (34.5x, -1.3%) -- heap_pdb4 -- heap_pdb4 valgrind-new:0.22s no: 1.9s ( 8.8x, -----) me:12.9s (58.7x, -----) ca:14.3s (65.0x, -----) he:14.2s (64.5x, -----) ca:12.4s (56.2x, -----) dr: 9.1s (41.3x, -----) ma: 8.0s (36.4x, -----) heap_pdb4 valgrind-old:0.22s no: 1.9s ( 8.9x, -0.5%) me:12.8s (58.2x, 0.8%) ca:14.4s (65.3x, -0.5%) he:14.1s (64.0x, 0.7%) ca:12.3s (56.0x, 0.3%) dr: 8.9s (40.3x, 2.5%) ma: 8.0s (36.5x, -0.4%) -- many-loss-records -- many-loss-records valgrind-new:0.02s no: 0.5s (23.5x, -----) me: 2.1s (103.5x, -----) ca: 1.9s (97.0x, -----) he: 2.2s (108.0x, -----) ca: 1.9s (96.0x, -----) dr: 1.8s (89.0x, -----) ma: 1.6s (82.5x, -----) many-loss-records valgrind-old:0.02s no: 0.5s (23.5x, 0.0%) me: 2.0s (102.5x, 1.0%) ca: 1.9s (97.0x, 0.0%) he: 2.1s (106.0x, 1.9%) ca: 1.9s (95.5x, 0.5%) dr: 1.7s (87.0x, 2.2%) ma: 1.7s (83.5x, -1.2%) -- many-xpts -- many-xpts valgrind-new:0.06s no: 0.6s (10.0x, -----) me: 3.2s (53.3x, -----) ca:368.0s (6133.7x, -----) he: 6.5s (109.2x, -----) ca: 2.8s (46.8x, -----) dr: 2.6s (43.3x, -----) ma: 2.6s (43.0x, -----) many-xpts valgrind-old:0.06s no: 0.6s (10.0x, 0.0%) me: 3.2s (53.0x, 0.6%) ca:372.3s (6204.8x, -1.2%) he: 6.5s (108.2x, 0.9%) ca: 2.8s (46.8x, 0.0%) dr: 2.5s (41.5x, 4.2%) ma: 2.6s (43.7x, -1.6%) -- sarp -- sarp valgrind-new:0.02s no: 0.6s (28.0x, -----) me: 3.6s (180.5x, -----) ca: 3.2s (158.0x, -----) he:16.1s (804.5x, -----) ca: 2.0s (102.5x, -----) dr: 1.6s (78.5x, -----) ma: 0.5s (24.0x, -----) sarp valgrind-old:0.02s no: 0.6s (28.5x, -1.8%) me: 3.6s (179.5x, 0.6%) ca: 3.2s (158.5x, -0.3%) he:16.1s (804.0x, 0.1%) ca: 2.0s (102.5x, 0.0%) dr: 1.3s (66.5x, 15.3%) ma: 0.5s (25.5x, -6.2%) -- tinycc -- tinycc valgrind-new:0.22s no: 2.7s (12.2x, -----) me:14.9s (67.9x, -----) ca:29.9s (136.1x, -----) he:27.8s (126.5x, -----) ca:21.4s (97.1x, -----) dr:21.8s (99.0x, -----) ma: 4.0s (18.1x, -----) tinycc valgrind-old:0.22s no: 2.7s (12.1x, 0.7%) me:14.9s (67.8x, 0.1%) ca:29.9s (136.1x, 0.0%) he:27.8s (126.2x, 0.2%) ca:21.2s (96.5x, 0.6%) dr:20.4s (92.9x, 6.2%) ma: 4.3s (19.5x, -7.3%) -- Finished tests in perf ---------------------------------------------- == 11 programs, 154 timings ================= real 184m37.122s user 183m36.014s sys 0m50.961s |
|
From: Kirill B. <bat...@is...> - 2014-02-26 11:23:28
|
Hi, only one letter got to valgrind-developers mailing list. I'll quote the first message of the thread so that those who do not read llvmdev knew what's this discusssion about. === Begin of the first message === > Hi, > > I've seen on the LLVM's Open Projet Page [1] an idea about using LLVM to > generate native code in Valgrind. For what I know, Valgrind uses libVEX > to translate native instructions into a bitcode, used to add the > instrumentation and then translated back to native code for execution. > > Valgrind and LLVM are two tools that I use nearly every day. I'm also > very interested in code generation and optimization, so adding the > possibility to use LLVM to generate native code in libVEX interests me > very much. Is it a good idea? Could a LLVM backend bring something > useful to Valgrind (for instance, faster execution or more targets > supported) ? > > I've sent this message to the LLVM and Valgrind mailing lists because > I've originally found the idea on the LLVM's website, but Valgrind is > the object of the idea. By the way, does anyone already know if LLVM or > Valgrind will be a mentoring organization for this year's GSoC? > > You can find in [2] the list of my past projects. During the GSoC 2011, > I had the chance to use the Clang libraries to compile C code, and the > LLVM JIT to execute it (with instrumented stdlib functions). I have also > played with the LLVM C bindings to generate code when I explored some > parts of Mesa. > > Denis Steckelmacher > > [1] : http://llvm.org/OpenProjects.html#misc_new > [2] : http://steckdenis.be/page-projects.html === End of the first message === The idea of using LLVM backend in some dynamic binary translation (DBT) project has became popular recently. Unfortunately it does not prove to be good. I suggest you check the related work in QEMU. DBT part of both QEMU and Valgrind works in similar way. And there were a bunch of works on using LLVM as a QEMU backend. They resulted in slowdown mostly. In [1] the authors reported 35x slowdown, in [2] there were around 2x slowdown. Finally in [3] the authors reported performance gain, but there are some catches. 1. They used LLVM not only for backend. They replaced internal representation with LLVM. This is not an option for Valgrind because you'll need to rewrite all existing tools (including third party ones) to do it. 2. They use SPEC CPU benchmarks to measure their speedup. Important things about these tests is that they have little code to translate but a lot of computations to do with translated code. And even some of these tests are not doing too well (like 403.gcc). On real life applications (like firefox) where there are a lot of library code to translate and not so much computations to do results may be totally different. LLVM is not doing good as a DBT backend mostly for two reasons. First, in DBT you need to translate while you are running the application. You need to do it really fast. Compiler is not optimized for that task. LLVM JIT? May be. Second, in DBT you translate code in small portions like basic blocks, or extended basic blocks. They have very simple structure. There is no loops, there is no redundancy from translation high level language to low level. There is nothing good sophisticated optimizations can do better then very simple ones. In conclusion I second what have already been said: this project sounds like fun to do, but do not expect much practical results from it. > It would also be interesting to cache the LLVM-generated code > between runs The tricky part here is to build matching between binary code fragments and cached translations from previous runs. In worst case all you know about the binary code is it's address (which can vary between runs) and the binary code itself. [1] : "Dynamically Translating x86 to LLVM using QEMU" http://infoscience.epfl.ch/record/149975/files/x86-llvm-translator-chipounov_2.pdf [2] : llvm-qemu project. http://code.google.com/p/llvm-qemu/ [3] : "LnQ: Building High Performance Dynamic Binary Translator with Existing Compiler Backends" http://people.cs.nctu.edu.tw/~chenwj/slide/paper/lnq.pdf -- Kirill |
|
From: Philippe W. <phi...@sk...> - 2014-02-26 05:47:16
|
valgrind revision: 13839 VEX revision: 2825 C compiler: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) GDB: GNU gdb (GDB) Fedora (7.5.1-37.fc18) Assembler: GNU assembler version 2.23.51.0.1-7.fc18 20120806 C library: GNU C Library stable release version 2.16 uname -mrs: Linux 3.8.8-202.fc18.ppc64p7 ppc64 Vendor version: Fedora release 18 (Spherical Cow) Nightly build on gcc110 ( Fedora release 18 (Spherical Cow), ppc64 ) Started at 2014-02-25 20:00:13 PST Ended at 2014-02-25 21:44:13 PST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 575 tests, 36 stderr failures, 7 stdout failures, 0 stderrB failures, 0 stdoutB failures, 2 post failures == memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) massif/tests/big-alloc (post) massif/tests/deep-D (post) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/jm-vmx (stderr) none/tests/ppc32/test_isa_2_06_part2 (stdout) none/tests/ppc32/test_isa_2_06_part2 (stderr) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/jm-vmx (stderr) none/tests/ppc64/test_isa_2_06_part2 (stdout) none/tests/ppc64/test_isa_2_06_part2 (stderr) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/free_is_write (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/pth_destroy_cond (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 valgrind-new:0.22s no: 1.6s ( 7.2x, -----) me: 2.9s (13.3x, -----) ca:17.9s (81.4x, -----) he: 1.8s ( 8.0x, -----) ca: 5.3s (24.2x, -----) dr: 1.7s ( 7.7x, -----) ma: 2.1s ( 9.8x, -----) bigcode1 valgrind-old:0.22s no: 1.5s ( 6.9x, 3.8%) me: 2.8s (12.8x, 3.4%) ca:17.9s (81.4x, 0.0%) he: 1.7s ( 7.9x, 1.1%) ca: 5.5s (25.0x, -3.4%) dr: 1.7s ( 7.8x, -0.6%) ma: 2.1s ( 9.5x, 2.3%) -- bigcode2 -- bigcode2 valgrind-new:0.23s no: 1.5s ( 6.7x, -----) me: 3.0s (12.9x, -----) ca:18.2s (79.1x, -----) he: 2.1s ( 9.1x, -----) ca: 5.4s (23.5x, -----) dr: 1.8s ( 8.0x, -----) ma: 2.1s ( 9.2x, -----) bigcode2 valgrind-old:0.23s no: 1.5s ( 6.6x, 0.7%) me: 2.9s (12.7x, 1.3%) ca:18.1s (78.9x, 0.3%) he: 2.1s ( 9.1x, 0.0%) ca: 5.4s (23.6x, -0.2%) dr: 1.8s ( 8.0x, 0.0%) ma: 2.1s ( 9.2x, 0.0%) -- bz2 -- bz2 valgrind-new:0.72s no: 4.6s ( 6.3x, -----) me:11.9s (16.6x, -----) ca:25.9s (36.0x, -----) he:14.9s (20.7x, -----) ca:24.4s (33.9x, -----) dr:20.3s (28.2x, -----) ma: 4.7s ( 6.5x, -----) bz2 valgrind-old:0.72s no: 4.5s ( 6.3x, 1.3%) me:11.9s (16.5x, 0.8%) ca:26.0s (36.1x, -0.1%) he:14.8s (20.5x, 0.8%) ca:24.5s (34.1x, -0.4%) dr:20.5s (28.4x, -0.9%) ma: 4.7s ( 6.5x, -0.6%) -- fbench -- fbench valgrind-new:0.34s no: 2.1s ( 6.2x, -----) me: 5.4s (15.9x, -----) ca: 8.4s (24.7x, -----) he: 5.2s (15.4x, -----) ca: 7.5s (22.0x, -----) dr: 4.9s (14.4x, -----) ma: 2.1s ( 6.3x, -----) fbench valgrind-old:0.34s no: 2.1s ( 6.2x, 0.0%) me: 5.2s (15.4x, 3.0%) ca: 8.4s (24.8x, -0.2%) he: 5.2s (15.3x, 0.4%) ca: 7.4s (21.9x, 0.5%) dr: 4.9s (14.3x, 0.2%) ma: 2.2s ( 6.4x, -0.9%) -- ffbench -- ffbench valgrind-new:0.45s no: 1.3s ( 3.0x, -----) me: 2.5s ( 5.6x, -----) ca: 2.5s ( 5.5x, -----) he: 7.1s (15.8x, -----) ca: 7.4s (16.4x, -----) dr: 5.1s (11.3x, -----) ma: 1.0s ( 2.3x, -----) ffbench valgrind-old:0.45s no: 1.3s ( 3.0x, 0.0%) me: 2.6s ( 5.8x, -3.5%) ca: 2.5s ( 5.5x, 0.8%) he: 7.2s (16.0x, -0.8%) ca: 7.0s (15.6x, 4.6%) dr: 4.9s (11.0x, 2.6%) ma: 1.0s ( 2.2x, 1.0%) -- heap -- heap valgrind-new:0.41s no: 2.4s ( 5.9x, -----) me: 9.9s (24.1x, -----) ca:13.0s (31.7x, -----) he:11.7s (28.6x, -----) ca:12.2s (29.8x, -----) dr: 8.2s (20.0x, -----) ma: 8.6s (20.9x, -----) heap valgrind-old:0.41s no: 2.4s ( 5.9x, 0.4%) me: 9.9s (24.2x, -0.2%) ca:13.1s (32.0x, -0.9%) he:11.8s (28.7x, -0.3%) ca:12.1s (29.4x, 1.1%) dr: 8.4s (20.4x, -1.8%) ma: 8.6s (21.1x, -0.7%) -- heap_pdb4 -- heap_pdb4 valgrind-new:0.43s no: 2.6s ( 6.1x, -----) me:13.9s (32.2x, -----) ca:14.0s (32.6x, -----) he:13.1s (30.5x, -----) ca:13.2s (30.8x, -----) dr: 9.3s (21.6x, -----) ma: 8.8s (20.4x, -----) heap_pdb4 valgrind-old:0.43s no: 2.6s ( 6.1x, 1.1%) me:13.9s (32.3x, -0.2%) ca:14.0s (32.5x, 0.1%) he:13.3s (30.9x, -1.3%) ca:13.1s (30.5x, 1.0%) dr: 9.3s (21.6x, -0.1%) ma: 8.7s (20.3x, 0.6%) -- many-loss-records -- many-loss-records valgrind-new:0.03s no: 0.5s (17.7x, -----) me: 2.2s (72.7x, -----) ca: 1.9s (62.0x, -----) he: 1.8s (60.0x, -----) ca: 1.9s (62.0x, -----) dr: 1.6s (52.0x, -----) ma: 1.6s (52.0x, -----) many-loss-records valgrind-old:0.03s no: 0.5s (17.7x, 0.0%) me: 2.2s (73.0x, -0.5%) ca: 1.9s (62.3x, -0.5%) he: 1.8s (60.0x, 0.0%) ca: 1.9s (62.7x, -1.1%) dr: 1.6s (52.3x, -0.6%) ma: 1.6s (52.0x, 0.0%) -- many-xpts -- many-xpts valgrind-new:0.07s no: 0.7s (10.6x, -----) me: 3.4s (49.1x, -----) ca: 4.7s (66.6x, -----) he: 4.8s (68.9x, -----) ca: 2.9s (41.4x, -----) dr: 2.3s (33.4x, -----) ma: 2.2s (32.1x, -----) many-xpts valgrind-old:0.07s no: 0.7s (10.6x, 0.0%) me: 3.4s (49.0x, 0.3%) ca: 4.7s (66.7x, -0.2%) he: 4.9s (69.6x, -1.0%) ca: 2.9s (41.3x, 0.3%) dr: 2.3s (33.3x, 0.4%) ma: 2.2s (32.1x, 0.0%) -- sarp -- sarp valgrind-new:0.02s no: 0.4s (20.0x, -----) me: 3.2s (158.5x, -----) ca: 2.9s (145.5x, -----) he:11.0s (551.0x, -----) ca: 1.7s (83.5x, -----) dr: 1.1s (54.0x, -----) ma: 0.4s (21.0x, -----) sarp valgrind-old:0.02s no: 0.4s (21.0x, -5.0%) me: 3.2s (160.5x, -1.3%) ca: 2.9s (147.0x, -1.0%) he:11.0s (551.0x, 0.0%) ca: 1.7s (85.0x, -1.8%) dr: 1.1s (53.5x, 0.9%) ma: 0.4s (21.0x, 0.0%) -- tinycc -- tinycc valgrind-new:0.28s no: 3.0s (10.6x, -----) me:14.2s (50.5x, -----) ca:17.2s (61.5x, -----) he:19.0s (67.7x, -----) ca:15.7s (55.9x, -----) dr:12.4s (44.3x, -----) ma: 3.8s (13.6x, -----) tinycc valgrind-old:0.28s no: 3.0s (10.6x, -0.3%) me:14.2s (50.9x, -0.6%) ca:17.2s (61.5x, 0.0%) he:19.0s (67.9x, -0.3%) ca:15.8s (56.4x, -0.9%) dr:12.4s (44.3x, 0.0%) ma: 3.8s (13.6x, -0.5%) -- Finished tests in perf ---------------------------------------------- == 11 programs, 154 timings ================= real 53m58.326s user 52m29.929s sys 0m20.880s |
|
From: Christian B. <bor...@de...> - 2014-02-26 04:07:41
|
valgrind revision: 13839 VEX revision: 2825 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29) Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1 C library: GNU C Library stable release version 2.11.3 (20110527) uname -mrs: Linux 3.0.101-0.8-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2014-02-26 03:45:01 CET Ended at 2014-02-26 05:07:26 CET Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 642 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_cond_destroy_busy (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 642 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable4 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) drd/tests/pth_barrier3 (stderr) drd/tests/pth_barrier_thr_cr (stderr) drd/tests/pth_create_chain (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Feb 26 04:03:34 2014 --- new.short Wed Feb 26 04:47:42 2014 *************** *** 8,16 **** ! == 642 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == ! memcheck/tests/err_disable4 (stderr) ! helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) - drd/tests/pth_barrier3 (stderr) - drd/tests/pth_barrier_thr_cr (stderr) - drd/tests/pth_create_chain (stderr) --- 8,11 ---- ! == 642 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_cond_destroy_busy (stderr) --tools=none,memcheck --reps=5 --vg=../valgrind-new --vg=../valgrind-old -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 valgrind-new:0.22s no: 4.3s (19.6x, -----) me: 6.9s (31.5x, -----) bigcode1 valgrind-old:0.22s no: 4.3s (19.5x, 0.5%) me: 6.9s (31.5x, -0.1%) -- bigcode2 -- bigcode2 valgrind-new:0.24s no: 7.2s (30.1x, -----) me:13.8s (57.5x, -----) bigcode2 valgrind-old:0.24s no: 7.2s (30.0x, 0.3%) me:13.8s (57.3x, 0.4%) -- bz2 -- bz2 valgrind-new:0.70s no: 5.0s ( 7.1x, -----) me:13.0s (18.5x, -----) bz2 valgrind-old:0.70s no: 4.9s ( 7.1x, 1.2%) me:13.0s (18.6x, -0.2%) -- fbench -- fbench valgrind-new:0.41s no: 1.6s ( 3.9x, -----) me: 4.2s (10.4x, -----) fbench valgrind-old:0.41s no: 1.6s ( 3.9x, 0.0%) me: 4.3s (10.5x, -0.9%) -- ffbench -- ffbench valgrind-new:0.20s no: 1.0s ( 5.2x, -----) me: 3.0s (15.2x, -----) ffbench valgrind-old:0.20s no: 1.0s ( 5.2x, 0.0%) me: 3.1s (15.3x, -0.3%) -- heap -- heap valgrind-new:0.23s no: 1.8s ( 7.8x, -----) me: 8.8s (38.5x, -----) heap valgrind-old:0.23s no: 1.8s ( 7.7x, 1.7%) me: 8.7s (37.9x, 1.6%) -- heap_pdb4 -- heap_pdb4 valgrind-new:0.22s no: 2.0s ( 8.9x, -----) me:13.0s (59.2x, -----) heap_pdb4 valgrind-old:0.22s no: 1.9s ( 8.8x, 1.5%) me:12.8s (58.3x, 1.5%) -- many-loss-records -- many-loss-records valgrind-new:0.03s no: 0.5s (15.3x, -----) me: 2.1s (69.3x, -----) many-loss-records valgrind-old:0.03s no: 0.5s (15.7x, -2.2%) me: 2.1s (68.7x, 1.0%) -- many-xpts -- many-xpts valgrind-new:0.07s no: 0.6s ( 8.7x, -----) me: 3.2s (45.9x, -----) many-xpts valgrind-old:0.07s no: 0.6s ( 8.6x, 1.6%) me: 3.2s (45.6x, 0.6%) -- sarp -- sarp valgrind-new:0.03s no: 0.6s (19.0x, -----) me: 3.6s (120.3x, -----) sarp valgrind-old:0.03s no: 0.6s (19.3x, -1.8%) me: 3.6s (120.0x, 0.3%) -- tinycc -- tinycc valgrind-new:0.22s no: 2.7s (12.4x, -----) me:15.0s (68.0x, -----) tinycc valgrind-old:0.22s no: 2.7s (12.1x, 2.2%) me:14.9s (67.9x, 0.1%) -- Finished tests in perf ---------------------------------------------- == 11 programs, 44 timings ================= real 19m43.996s user 19m17.281s sys 0m24.602s |
|
From: Rich C. <rc...@wi...> - 2014-02-26 04:05:30
|
valgrind revision: 13839 VEX revision: 2825 C compiler: gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012] GDB: GNU gdb (GDB) SUSE (7.5.1-2.1.1) Assembler: GNU assembler (GNU Binutils; openSUSE 12.3) 2.23.1 C library: GNU C Library (GNU libc) stable release version 2.17 (git c758a6861537) uname -mrs: Linux 3.7.9-1.1-desktop x86_64 Vendor version: Welcome to openSUSE 12.3 "Dartmouth" Beta 1 - Kernel %r (%t). Nightly build on ultra ( gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012] Linux 3.7.9-1.1-desktop x86_64 ) Started at 2014-02-25 21:30:01 CST Ended at 2014-02-25 22:05:20 CST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 666 tests, 0 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures == gdbserver_tests/mssnapshot (stderrB) ================================================= ./valgrind-new/gdbserver_tests/mssnapshot.stderrB.diff ================================================= --- mssnapshot.stderrB.exp 2014-02-25 21:48:13.363944177 -0600 +++ mssnapshot.stderrB.out 2014-02-25 21:54:29.323354774 -0600 @@ -1,5 +1,11 @@ relaying data between gdb and process .... +Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 +Try: zypper install -C "debuginfo(build-id)=ecb8ef1a6904a2a3ec60a527f415f520c8636158" vgdb-error value changed from 0 to 999999 +Missing separate debuginfo for /lib64/libpthread.so.0 +Try: zypper install -C "debuginfo(build-id)=ef5f5dbcb2398c608fef7884e1bfb65be3b5f0ef" +Missing separate debuginfo for /lib64/libc.so.6 +Try: zypper install -C "debuginfo(build-id)=bd1473e8e6a4c10a14731b5be4b35b4e87db2af7" general valgrind monitor commands: help [debug] : monitor command help. With debug: + debugging commands v.wait [<ms>] : sleep <ms> (default 0) then continue ================================================= ./valgrind-old/gdbserver_tests/mssnapshot.stderrB.diff ================================================= --- mssnapshot.stderrB.exp 2014-02-25 21:31:44.514768004 -0600 +++ mssnapshot.stderrB.out 2014-02-25 21:36:52.467113947 -0600 @@ -1,5 +1,11 @@ relaying data between gdb and process .... +Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 +Try: zypper install -C "debuginfo(build-id)=ecb8ef1a6904a2a3ec60a527f415f520c8636158" vgdb-error value changed from 0 to 999999 +Missing separate debuginfo for /lib64/libpthread.so.0 +Try: zypper install -C "debuginfo(build-id)=ef5f5dbcb2398c608fef7884e1bfb65be3b5f0ef" +Missing separate debuginfo for /lib64/libc.so.6 +Try: zypper install -C "debuginfo(build-id)=bd1473e8e6a4c10a14731b5be4b35b4e87db2af7" general valgrind monitor commands: help [debug] : monitor command help. With debug: + debugging commands v.wait [<ms>] : sleep <ms> (default 0) then continue |
|
From: Rich C. <rc...@wi...> - 2014-02-26 03:26:51
|
valgrind revision: 13839
VEX revision: 2825
C compiler: gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
GDB: GNU gdb (GDB; openSUSE Factory) 7.6.50.20130731-cvs
Assembler: GNU assembler (GNU Binutils; openSUSE Factory) 2.23.2
C library: GNU C Library (GNU libc) stable release version 2.18 (git )
uname -mrs: Linux 3.11.4-3-desktop x86_64
Vendor version: Welcome to openSUSE 13.1 "Bottle" Beta 1 - Kernel %r (%t).
Nightly build on rodan ( Linux 3.11.4-3-desktop x86_64 )
Started at 2014-02-25 19:22:01 CST
Ended at 2014-02-25 21:26:35 CST
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 588 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/dw4 (stderr)
memcheck/tests/err_disable3 (stderr)
memcheck/tests/err_disable4 (stderr)
memcheck/tests/threadname (stderr)
memcheck/tests/threadname_xml (stderr)
exp-sgcheck/tests/hackedbz2 (stderr)
=================================================
./valgrind-new/exp-sgcheck/tests/hackedbz2.stderr.diff-glibc28-amd64
=================================================
--- hackedbz2.stderr.exp-glibc28-amd64 2014-02-25 20:25:17.780956153 -0600
+++ hackedbz2.stderr.out 2014-02-25 21:25:18.258723326 -0600
@@ -1,7 +1,6 @@
Invalid read of size 1
- at 0x........: vex_strlen (hackedbz2.c:1006)
- by 0x........: add_to_myprintf_buf (hackedbz2.c:1284)
+ at 0x........: add_to_myprintf_buf (hackedbz2.c:1006)
by 0x........: vex_printf (hackedbz2.c:1155)
by 0x........: BZ2_compressBlock (hackedbz2.c:4039)
by 0x........: handle_compress (hackedbz2.c:4761)
=================================================
./valgrind-new/memcheck/tests/dw4.stderr.diff
=================================================
--- dw4.stderr.exp 2014-02-25 20:25:44.462265669 -0600
+++ dw4.stderr.out 2014-02-25 20:43:50.868868477 -0600
@@ -1,3 +1,11 @@
+
+parse_type_DIE: confused by:
+ <1><492>: DW_TAG_structure_type
+ DW_AT_signature : 8 byte signature: 9b d0 55 13 bb 1e e9 37
+
+WARNING: Serious error when reading debug info
+When reading debug info from /usr/local/src/valgrind/nightly/valgrind-new/memcheck/tests/dw4:
+parse_type_DIE: confused by the above DIE
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:49)
@@ -8,12 +16,10 @@
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:51)
- Location 0x........ is 0 bytes inside S2[0].i,
- a global variable declared at dw4.c:42
+ Address 0x........ is 4 bytes inside data symbol "S2"
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:52)
- Location 0x........ is 0 bytes inside local.i,
- declared at dw4.c:46, in frame #1 of thread 1
+ Address 0x........ is on thread 1's stack
=================================================
./valgrind-new/memcheck/tests/err_disable3.stderr.diff
=================================================
--- err_disable3.stderr.exp 2014-02-25 20:25:43.865258743 -0600
+++ err_disable3.stderr.out 2014-02-25 20:43:57.530945710 -0600
@@ -10,8 +10,6 @@
Thread 2:
Invalid read of size 1
at 0x........: err (err_disable3.c:25)
- by 0x........: child_fn (err_disable3.c:31)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable3.c:42)
=================================================
./valgrind-new/memcheck/tests/err_disable4.stderr.diff
=================================================
--- err_disable4.stderr.exp 2014-02-25 20:25:46.242286318 -0600
+++ err_disable4.stderr.out 2014-02-25 20:44:01.743994584 -0600
@@ -1501,8 +1501,6 @@
Thread x:
Invalid read of size 1
at 0x........: err (err_disable4.c:41)
- by 0x........: child_fn_2 (err_disable4.c:55)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable4.c:68)
=================================================
./valgrind-new/memcheck/tests/threadname.stderr.diff
=================================================
--- threadname.stderr.exp 2014-02-25 20:25:43.867258766 -0600
+++ threadname.stderr.out 2014-02-25 20:49:44.742973577 -0600
@@ -9,36 +9,12 @@
Thread 2:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_0 (threadname.c:53)
- ...
Address 0x........ is 0 bytes after a block of size 2 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: bad_things (threadname.c:15)
by 0x........: child_fn_0 (threadname.c:53)
...
-Thread 3 try1:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
- Address 0x........ is 0 bytes after a block of size 3 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
-
-Thread 4 012345678901234:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
- Address 0x........ is 0 bytes after a block of size 4 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
-
Thread 1:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
=================================================
./valgrind-new/memcheck/tests/threadname_xml.stderr.diff
=================================================
--- threadname_xml.stderr.exp 2014-02-25 20:25:46.790292675 -0600
+++ threadname_xml.stderr.out 2014-02-25 20:49:46.740996755 -0600
@@ -94,14 +94,6 @@
<file>threadname.c</file>
<line>...</line>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_0</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
</stack>
<auxwhat>Address 0x........ is 0 bytes after a block of size 2 alloc'd</auxwhat>
<stack>
@@ -135,112 +127,6 @@
<error>
<unique>0x........</unique>
<tid>...</tid>
- <threadname>try1</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 3 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>malloc</fn>
- <dir>...</dir>
- <file>vg_replace_malloc.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
-</error>
-
-<error>
- <unique>0x........</unique>
- <tid>...</tid>
- <threadname>012345678901234</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_2</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 4 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<truncated beyond 100 lines>
=================================================
./valgrind-old/exp-sgcheck/tests/hackedbz2.stderr.diff-glibc28-amd64
=================================================
--- hackedbz2.stderr.exp-glibc28-amd64 2014-02-25 19:22:18.240111768 -0600
+++ hackedbz2.stderr.out 2014-02-25 20:22:20.616900970 -0600
@@ -1,7 +1,6 @@
Invalid read of size 1
- at 0x........: vex_strlen (hackedbz2.c:1006)
- by 0x........: add_to_myprintf_buf (hackedbz2.c:1284)
+ at 0x........: add_to_myprintf_buf (hackedbz2.c:1006)
by 0x........: vex_printf (hackedbz2.c:1155)
by 0x........: BZ2_compressBlock (hackedbz2.c:4039)
by 0x........: handle_compress (hackedbz2.c:4761)
=================================================
./valgrind-old/memcheck/tests/dw4.stderr.diff
=================================================
--- dw4.stderr.exp 2014-02-25 19:23:04.323646358 -0600
+++ dw4.stderr.out 2014-02-25 19:40:59.337117001 -0600
@@ -1,3 +1,11 @@
+
+parse_type_DIE: confused by:
+ <1><492>: DW_TAG_structure_type
+ DW_AT_signature : 8 byte signature: 9b d0 55 13 bb 1e e9 37
+
+WARNING: Serious error when reading debug info
+When reading debug info from /usr/local/src/valgrind/nightly/valgrind-old/memcheck/tests/dw4:
+parse_type_DIE: confused by the above DIE
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:49)
@@ -8,12 +16,10 @@
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:51)
- Location 0x........ is 0 bytes inside S2[0].i,
- a global variable declared at dw4.c:42
+ Address 0x........ is 4 bytes inside data symbol "S2"
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:52)
- Location 0x........ is 0 bytes inside local.i,
- declared at dw4.c:46, in frame #1 of thread 1
+ Address 0x........ is on thread 1's stack
=================================================
./valgrind-old/memcheck/tests/err_disable3.stderr.diff
=================================================
--- err_disable3.stderr.exp 2014-02-25 19:23:02.741628006 -0600
+++ err_disable3.stderr.out 2014-02-25 19:41:05.884192950 -0600
@@ -10,8 +10,6 @@
Thread 2:
Invalid read of size 1
at 0x........: err (err_disable3.c:25)
- by 0x........: child_fn (err_disable3.c:31)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable3.c:42)
=================================================
./valgrind-old/memcheck/tests/err_disable4.stderr.diff
=================================================
--- err_disable4.stderr.exp 2014-02-25 19:23:04.804651938 -0600
+++ err_disable4.stderr.out 2014-02-25 19:41:10.754249445 -0600
@@ -1501,8 +1501,6 @@
Thread x:
Invalid read of size 1
at 0x........: err (err_disable4.c:41)
- by 0x........: child_fn_2 (err_disable4.c:55)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable4.c:68)
=================================================
./valgrind-old/memcheck/tests/threadname.stderr.diff
=================================================
--- threadname.stderr.exp 2014-02-25 19:23:02.743628029 -0600
+++ threadname.stderr.out 2014-02-25 19:46:52.754216799 -0600
@@ -9,36 +9,12 @@
Thread 2:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_0 (threadname.c:53)
- ...
Address 0x........ is 0 bytes after a block of size 2 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: bad_things (threadname.c:15)
by 0x........: child_fn_0 (threadname.c:53)
...
-Thread 3 try1:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
- Address 0x........ is 0 bytes after a block of size 3 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
-
-Thread 4 012345678901234:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
- Address 0x........ is 0 bytes after a block of size 4 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
-
Thread 1:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
=================================================
./valgrind-old/memcheck/tests/threadname_xml.stderr.diff
=================================================
--- threadname_xml.stderr.exp 2014-02-25 19:23:05.799663480 -0600
+++ threadname_xml.stderr.out 2014-02-25 19:46:54.747239919 -0600
@@ -94,14 +94,6 @@
<file>threadname.c</file>
<line>...</line>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_0</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
</stack>
<auxwhat>Address 0x........ is 0 bytes after a block of size 2 alloc'd</auxwhat>
<stack>
@@ -135,112 +127,6 @@
<error>
<unique>0x........</unique>
<tid>...</tid>
- <threadname>try1</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 3 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>malloc</fn>
- <dir>...</dir>
- <file>vg_replace_malloc.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
-</error>
-
-<error>
- <unique>0x........</unique>
- <tid>...</tid>
- <threadname>012345678901234</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_2</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 4 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<truncated beyond 100 lines>
|