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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(39) |
2
(29) |
3
(27) |
4
(50) |
5
(37) |
|
6
(14) |
7
(28) |
8
(44) |
9
(38) |
10
(32) |
11
(49) |
12
(51) |
|
13
(37) |
14
(32) |
15
(70) |
16
(50) |
17
(43) |
18
(56) |
19
(23) |
|
20
(22) |
21
(36) |
22
(12) |
23
(22) |
24
(10) |
25
(13) |
26
(21) |
|
27
(17) |
28
(16) |
29
(33) |
30
(14) |
|
|
|
|
From: <js...@ac...> - 2005-11-02 03:30:25
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-11-02 03:30:01 GMT Checking out vex source tree ... failed Last 20 lines of verbose log follow echo Checking out vex source tree ... svn co svn://svn.valgrind.org/vex/trunk -r {2005-11-02T03:30:01} vex svn: Berkeley DB error for filesystem /home/svn/repos/vex/db while opening environment: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: PANIC: fatal region error detected; run recovery ================================================= == Results from 24 hours ago == ================================================= Checking out vex source tree ... failed Last 20 lines of verbose log follow echo Checking out vex source tree ... svn co svn://svn.valgrind.org/vex/trunk -r {2005-11-01T03:30:01} vex svn: Berkeley DB error for filesystem /home/svn/repos/vex/db while opening environment: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: PANIC: fatal region error detected; run recovery ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 2 03:30:16 2005 --- new.short Wed Nov 2 03:30:16 2005 *************** *** 5,7 **** ! Checking out vex source tree ... svn co svn://svn.valgrind.org/vex/trunk -r {2005-11-01T03:30:01} vex svn: Berkeley DB error for filesystem /home/svn/repos/vex/db while opening environment: --- 5,7 ---- ! Checking out vex source tree ... svn co svn://svn.valgrind.org/vex/trunk -r {2005-11-02T03:30:01} vex svn: Berkeley DB error for filesystem /home/svn/repos/vex/db while opening environment: |
|
From: Tom H. <to...@co...> - 2005-11-01 23:54:21
|
The repository has fallen over again: dunsmere [~/src/valgrind-3] % svn update svn: Berkeley DB error for filesystem /home/svn/repos/valgrind/db while opening environment: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: PANIC: fatal region error detected; run recovery Rom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: <sv...@va...> - 2005-11-01 22:37:12
|
Author: njn Date: 2005-11-01 22:37:00 +0000 (Tue, 01 Nov 2005) New Revision: 225 Log: Remove core dumping project; Tom has done this. Modified: trunk/help/projects.html Modified: trunk/help/projects.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/help/projects.html 2005-10-16 17:43:02 UTC (rev 224) +++ trunk/help/projects.html 2005-11-01 22:37:00 UTC (rev 225) @@ -223,16 +223,6 @@ proportion of the Valgrind user base. (Added August 27, 2005)</p> =20 =20 -<h3>Core dumping</h3> -<p>Valgrind 2.4.0 could produce useful core dumps. This functionality -was disabled in the transition to 3.0.0. It would be useful to have it -back. This requires factoring out the x86/Linux-specific parts -suitably. The old code is in m_coredump.c, entirely commented out. -This would be fairly easy, it just requires looking up the ELF -documentation to understand how core dumps are structured. (Added Augus= t -27, 2005)</p> - - <h3>Supporting custom allocators</h3> <p>Valgrind has two client requests, VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK that are intended to support custom allocators. |
|
From: Josef W. <Jos...@gm...> - 2005-11-01 22:24:46
|
On Tuesday 01 November 2005 22:13, Nicholas Nethercote wrote: > On Tue, 1 Nov 2005, Josef Weidendorfer wrote: > > > Regarding helper call vs. inlining: How much effort would it be to let Valgrind > > do the inlining of a C helper? > > A lot, I think. How would you do it? I just thought we could let VEX chasing to the work, and it would help if the helper is found on the client side (in a vgpreload*.so). But it is obviously a lot more difficult, and instrumenting the helper is not really useful :-) > I believe Pin can do this, I read about this, too. You can give a hint to PIN if inlining at different points is possible, so PIN would be able to choose a point where condition codes do not have to be restored afterwards. > but the inlining fails if the C function > modifies the condition codes, so in practice anything more than the > tiniest function will not be inlined. Probably. And such tiny helpers can be inlined manually. Josef > > Nick > > |
|
From: Tom H. <to...@co...> - 2005-11-01 22:02:23
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> Now that you've reimplemented core dumping, can the "Core Dumping" project
> at http://www.valgrind.org/help/projects.html be removed?
Pretty much - the x87 state still isn't being saved on x86 or amd64
but I'm not clear if there is actually enough information in the VEX
guest state to do that at the moment.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 21:13:30
|
On Tue, 1 Nov 2005, Josef Weidendorfer wrote: > Regarding helper call vs. inlining: How much effort would it be to let Valgrind > do the inlining of a C helper? A lot, I think. How would you do it? I believe Pin can do this, but the inlining fails if the C function modifies the condition codes, so in practice anything more than the tiniest function will not be inlined. Nick |
|
From: Jeroen N. W. <jn...@xs...> - 2005-11-01 20:36:32
|
> Closer to the time, I'll trawl through regtest failures on machines I > have access to see if there's anything critical there. It would be > helpful if others could do likewise. The regression test on Debian 3.1 (sarge) with valgrind revision 4979, VEX revision 1427 results in six failures. 1. The most serieus seem to be the error in memcheck/tests/pointer-trace and none/tests/mremap2. (These appeared after the merging in of the ASPACEM branch. (Previously reported on 1 October.)) See attached files memcheck/tests/pointer-trace.stderr.diff and none/tests/mremap2.stdout.diff. 2. AFAIK, the failures of none/tests/faultstatus and none/tests/x86/int are current restrictions in VEX. 3. The failures of memcheck/tests/writev and none/tests/fdleak_fcntl can be fixed with additional .exp files. $ uname -a: Linux DoornRoosje 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux $ gcc -v: gcc version 3.3.5 (Debian 1:3.3.5-13) Jeroen. |
|
From: Josef W. <Jos...@gm...> - 2005-11-01 20:27:14
|
On Tuesday 01 November 2005 18:42, Julian Seward wrote: > > > Why not just increment the real global counter in-line? As opposed to > > incrementing a temporary counter, and periodically adding it to global > > counter? > > Ah yes, that never occurred to me. Regarding helper call vs. inlining: How much effort would it be to let Valgrind do the inlining of a C helper? > The only objection might be that then generated code would be accessing > memory in areas that belong to V and not to the client. So it wouldn't > have worked with pointercheck, but that's no longer the case. > (Didn't JosefW have a similar problem some time back?) Yes. My instrumented code writes to a global tool variable. I switched off pointer check. I had a patch for an UCode memory store instruction to bypass pointer check, but it was not worth it. Josef |
|
From: Julian S. <js...@ac...> - 2005-11-01 20:25:35
|
On Tuesday 01 November 2005 19:48, Tom Hughes wrote: > In message <Pin...@ch...> > > Nicholas Nethercote <nj...@cs...> wrote: > > This machine exhibits a lot of test noise -- a number of tests fail and > > then work again for no apparent reason, and not just the common such ones > > (ie. 'tls' and 'yield'). Tom, any idea why? > > I believe the main cause of this is that because the sysinfo page is > placed at a random address by the kernel it was occasionally placed > at the preferred load address of ld.so which then stopped us mapping > the interpreter. > > What should happen in that case is that the interpreter is mapped at > a different address instead, and I have just committed a fix that > should achieve that. Both 'tls' and 'yield' are sensitive to scheduling. Yield figures out whether a spinloop doing 'rep nop's progresses more slowly than one that doesn't (and is a bit nonsensical). 'tls' I'm less clear about but I did look at it before and thought it might be susceptible to races. J |
|
From: Tom H. <to...@co...> - 2005-11-01 19:48:47
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> This machine exhibits a lot of test noise -- a number of tests fail and
> then work again for no apparent reason, and not just the common such ones
> (ie. 'tls' and 'yield'). Tom, any idea why?
I believe the main cause of this is that because the sysinfo page is
placed at a random address by the kernel it was occasionally placed
at the preferred load address of ld.so which then stopped us mapping
the interpreter.
What should happen in that case is that the interpreter is mapped at
a different address instead, and I have just committed a fix that
should achieve that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 19:46:30
|
Tom, Now that you've reimplemented core dumping, can the "Core Dumping" project at http://www.valgrind.org/help/projects.html be removed? Nick |
|
From: <sv...@va...> - 2005-11-01 19:46:09
|
Author: tom
Date: 2005-11-01 19:46:07 +0000 (Tue, 01 Nov 2005)
New Revision: 4980
Log:
Make the request for space for the interpreter into a hint so that we
can still proceed if the preferred load address is not available.
Modified:
trunk/coregrind/m_ume.c
Modified: trunk/coregrind/m_ume.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_ume.c 2005-11-01 17:52:34 UTC (rev 4979)
+++ trunk/coregrind/m_ume.c 2005-11-01 19:46:07 UTC (rev 4980)
@@ -438,6 +438,7 @@
=20
if (interp !=3D NULL) {
/* reserve a chunk of address space for interpreter */
+ MapRequest mreq;
Addr advised;
Bool ok;
=20
@@ -447,9 +448,10 @@
the specified address. This is a bit of hack, but it should
work because there should be no intervening transactions with
aspacem which could cause those fixed maps to fail. */
- advised =3D VG_(am_get_advisory_client_simple)(=20
- (Addr)interp_addr, interp_size, &ok=20
- );
+ mreq.rkind =3D MHint;
+ mreq.start =3D interp_addr;
+ mreq.len =3D interp_size;
+ advised =3D VG_(am_get_advisory)( &mreq, True/*client*/, &ok );
if (!ok) {
/* bomb out */
SysRes res =3D VG_(mk_SysRes_Error)(VKI_EINVAL);
|
|
From: <sv...@va...> - 2005-11-01 18:59:44
|
Author: sewardj
Date: 2005-11-01 18:59:38 +0000 (Tue, 01 Nov 2005)
New Revision: 1427
Log:
Implement 66 0F 11 =3D MOVUPD (untested)
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/priv/guest-amd64/toIR.c 2005-10-29 22:30:47 UTC (rev 1426)
+++ trunk/priv/guest-amd64/toIR.c 2005-11-01 18:59:38 UTC (rev 1427)
@@ -9777,15 +9777,17 @@
}
=20
/* 66 0F 29 =3D MOVAPD -- move from G (xmm) to E (mem or xmm). */
- if (have66noF2noF3(pfx) && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0x29=
) {
+ /* 66 0F 11 =3D MOVUPD -- move from G (xmm) to E (mem or xmm). */
+ if (have66noF2noF3(pfx) && insn[0] =3D=3D 0x0F=20
+ && (insn[1] =3D=3D 0x29 || insn[1] =3D=3D 0x11)) {
modrm =3D getUChar(delta+2);
if (epartIsReg(modrm)) {
/* fall through; awaiting test case */
} else {
addr =3D disAMode ( &alen, pfx, delta+2, dis_buf, 0 );
storeLE( mkexpr(addr), getXMMReg(gregOfRexRM(pfx,modrm)) );
- DIP("movapd %s,%s\n", nameXMMReg(gregOfRexRM(pfx,modrm)),
- dis_buf );
+ DIP("mov[ua]pd %s,%s\n", nameXMMReg(gregOfRexRM(pfx,modrm)),
+ dis_buf );
delta +=3D 2+alen;
goto decode_success;
}
|
|
From: Bryan M. <om...@br...> - 2005-11-01 18:52:25
|
Nick,
thanks for the input.
My system does indeed keep track of all the pointers that point to an
allocated block - there really is no other way. For convenience a count is
kept but it could quite easily be done by checking the pointer list for
entries when removing a pointer.
The special handling for the stack might be interesting so I will have a read
of that - I was planning to treat the stack as normal memory for simplicity
but optimising this at a later stage may well be required.
I want to get something working as soon as possible so that I can get it in
front of other programmers. Only this way can the benefits of open source be
reaped and on a project like this, that can only be a good thing. So, once it
passes a small number of tests that cover most of the standard issues, I will
post it up so that together we can cover the other cases and make it go
faster.
Bryan
On Tuesday 01 Nov 2005 17:07, Nicholas Nethercote wrote:
> On Sun, 30 Oct 2005, Bryan Meredith wrote:
>
> > Title
> > =====
> > Omega - A Valgrind tool for instant memory leak detection.
> > Designed by Bryan "Brain Murders" Meredith with grateful thanks to the
> > Valgrind team for making their tool and techniques available under the
GPL.
>
> Interesting :)
>
> You should read this paper:
>
> @InProceedings{Mae:precise2004,
> author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
> title = {Precise detection of memory leaks},
> booktitle = {Proceedings of the Second International Workshop on
Dynamic
> Analysis (WODA 2004)},
> pages = {},
> address = {Edinburgh, Scotland},
> month = may,
> year = 2004,
> summary = {Dynamic leak detector. Notable in that it detects the
> leaks when they happen. Does this by doing reference
> counting on each block, and tracking extra information
about
> each pointer. When a pointer is copied or clobbered,
the
> counts are updated. Per-pointer-info is stored in a
tree,
> with one part for stack pointers and the other half for
the
> rest. Some minor complications are used to avoid false
> positives, eg. caused by advancing a pointer past the
start
> of the block and then later back. Memory values are
> shadowed, registers not, but registers are all checked
> linearly when necessary (eg. when deciding whether a
block
> has leaked). Implemented in DIOTA, not surprisingly the
> current version runs programs 200--300 times slower.}
> }
>
> I haven't completely understood your scheme, but it's unclear to me how it
> will work without reference counting.
>
>
> > What Next?
> > ==========
> > I have to code it ;P
> > I have produced this in order to obtain feedback as soon as possible on
> > what will be a very useful tool both to my company and hopefully others.
> > Any and all feedback gratefully received. I understand that some parts
> > have probably been oversimplified and testing of the first
> > implementation will reveal some shortcomings. The main thing is that the
> > principle of using the 'V' bits to track pointers to allocated blocks is
> > sound - implementation of the internal data structures for the allocated
> > blocks, the reverse lookups and handling can be optimised over time as
> > required and thus is not detailed here. This is not to say that I don't
> > have a solution, it's just that it is one of many possible so not as
> > interesting.
>
> It sounds ok. In my experience the journey between the initial idea for a
> tool and the resulting implementation can be tortuous (but hopefully not
> torturous). The paper above should give you ideas about problems you
> haven't thought of, but you won't really know if it's feasible until you
> implement it. It looks like you've thought it through and have a good
> idea of how Valgrind works which is an excellent start. Good luck :)
> Feel free to ask more questions as you go.
>
> Nick
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Julian S. <js...@ac...> - 2005-11-01 18:25:12
|
Greetings. It's once again time for the major-release fun 'n' games.
I'm proposing we make a first release candidate on Friday 18 Nov, with
final release as soon as possible after that, and not later than
Friday 25 Nov, unless something really nasty turns up.
3.1.0 will support {x86,amd64,ppc32}-linux. It will contain the new
address space manager (a.k.a proper 64-bit support), a usable
ppc32-linux port, and many many small fixes relative to 3.0.1.
Larger stuff that needs to be sorted before the RC:
* Tom's biarch stuff
* ppc Altivec support
* coordinate with JosefW so as to have a simultaneous matching
callgrind/kcachegrind release if possible
* fix timestamping to show wallclock time elapsed since the run
started, since it looks like reimplementing localtime_r is
pretty much a non-starter.
Smaller stuff:
* check interface versioning
* reinstate --partial-loads-ok for memcheck
* possible have a --definedness-errors=no flag for mc, to make it
look like addrcheck
* install libcoregrind.a (needed for external tools)
* add ppc32 instruction test program to the testsuite
* fix various missing instructions
What else?
Overall I think the code base is in pretty good shape. The master
bug-status list is kept in docs/internals/3_0_BUGSTATUS.txt.
Please let me know of any stability problems you know of. I have had
OOo crashing on V on some ppc32 distros, which I should look into.
Closer to the time, I'll trawl through regtest failures on machines I
have access to see if there's anything critical there. It would be
helpful if others could do likewise.
J
|
|
From: <sv...@va...> - 2005-11-01 17:52:39
|
Author: sewardj
Date: 2005-11-01 17:52:34 +0000 (Tue, 01 Nov 2005)
New Revision: 4979
Log:
Reinstate and extend lackey's functionality (a major overhaul), from
Jeroen N. Witmond. Thanks for that.
Modified:
trunk/lackey/docs/lk-manual.xml
trunk/lackey/lk_main.c
Modified: trunk/lackey/docs/lk-manual.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/lackey/docs/lk-manual.xml 2005-11-01 17:21:03 UTC (rev 4978)
+++ trunk/lackey/docs/lk-manual.xml 2005-11-01 17:52:34 UTC (rev 4979)
@@ -5,13 +5,12 @@
<chapter id=3D"lk-manual" xreflabel=3D"Lackey">
=20
<title>Lackey: a very simple profiler</title>
-
<para>Lackey is a simple Valgrind tool that does some basic
program measurement. It adds quite a lot of simple
instrumentation to the program's code. It is primarily intended
to be of use as an example tool.</para>
=20
-<para>It measures three things:</para>
+<para>It measures and reports:</para>
=20
<orderedlist>
=20
@@ -19,21 +18,65 @@
<para>The number of calls to
<computeroutput>_dl_runtime_resolve()</computeroutput>, the
function in glibc's dynamic linker that resolves function
- lookups into shared objects.</para>
+ references to shared objects.</para>
+ <para>You can change the name of the function with command line
+ option <computeroutput>--fnname=3D<name></computeroutput>.</para=
>
</listitem>
=20
<listitem>
- <para>The number of UCode instructions (UCode is Valgrind's
- RISC-like intermediate language), x86 instructions, and basic
- blocks executed by the program, and some ratios between the
- three counts.</para>
+ <para>The number of conditional branches encountered and the
+ number and proportion of those taken.</para>
</listitem>
=20
<listitem>
- <para>The number of conditional branches encountered and the
- proportion of those taken.</para>
+
+ <para>Statistics about the amount of work done during the execution
+ of the client program:</para> =20
+
+ <orderedlist>
+
+ <listitem>
+ <para>The number of basic blocks entered and completed by the
+ program. Note that due to optimisations done by the JIT, this
+ is not really an accurate value.</para>
+ </listitem>
+
+ <listitem>
+ <para>The number of guest (x86, amd64, ppc, etc.) instructions and I=
R
+ statements executed. IR is Valgrind's RISC-like intermediate
+ representation via which all instrumentation is done.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Ratios between some of these counts.</para>
+ </listitem>
+
+ <listitem>
+ <para>When command line option
+ <computeroutput>--detailed-counts=3Dyes</computeroutput> is
+ specified, a table is printed with counts of loads, stores and ALU
+ operations for various types of operands.</para>
+
+ <para>The types are identified by their IR name ("I1" ... "I128",
+ "F32", "F64", and "V128").</para>
+ </listitem>
+
+ </orderedlist>
+
</listitem>
=20
+ <listitem>
+ <para>The exit code of the client program.</para>
+ </listitem>
+
</orderedlist>
=20
+<para>Note that Lackey runs quite slowly, especially when
+<computeroutput>--detailed-counts=3Dyes</computeroutput> is specified.
+It could be made to run a lot faster by doing a slightly more
+sophisticated job of the instrumentation, but that would undermine
+its role as a simple example tool. Hence we have chosen not to do
+so.</para>
+
</chapter>
Modified: trunk/lackey/lk_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/lackey/lk_main.c 2005-11-01 17:21:03 UTC (rev 4978)
+++ trunk/lackey/lk_main.c 2005-11-01 17:52:34 UTC (rev 4979)
@@ -1,6 +1,6 @@
=20
/*--------------------------------------------------------------------*/
-/*--- Simple tool for counting UInstrs, using a C helper. ---*/
+/*--- An example Valgrind tool. ---*/
/*--- lk_main.c ---*/
/*--------------------------------------------------------------------*/
=20
@@ -33,33 +33,81 @@
#include "pub_tool_tooliface.h"
#include "pub_tool_libcassert.h"
#include "pub_tool_libcprint.h"
+#include "pub_tool_debuginfo.h"
+#include "pub_tool_libcbase.h"
+#include "pub_tool_options.h"
=20
+
+/* The name of the function of which the number of calls is to be
+ * counted, with default. Override with command line option
+ * --fnname. */
+static Char* lk_clo_fnname =3D "_dl_runtime_resolve";
+
+/* If true, show statistics about loads, stores and alu ops. Set
+ * with command line option --detailed-counts. */
+static Bool lk_clo_detailed_counts =3D False;
+
+/***********************************************************************
+ * Implement the needs_command_line_options for Valgrind.
+ **********************************************************************/
+
+static Bool lk_process_cmd_line_option(Char* arg)
+{
+ VG_STR_CLO(arg, "--fnname", lk_clo_fnname)
+ else VG_BOOL_CLO(arg, "--detailed-counts", lk_clo_detailed_counts)
+ else
+ return False;
+ =20
+ tl_assert(lk_clo_fnname);
+ tl_assert(lk_clo_fnname[0]);
+ return True;
+}
+
+static void lk_print_usage(void)
+{ =20
+ VG_(printf)(
+" --fnname=3D<name> count calls to <name> [_dl_runtime_reso=
lve]\n"
+" --detailed-counts=3Dno|yes count loads, stores and alu ops [no]\n"
+ );
+}
+
+static void lk_print_debug_usage(void)
+{ =20
+}
+
+/***********************************************************************
+ * Data and helpers related to the default operation of Lackey.
+ **********************************************************************/
+
/* Nb: use ULongs because the numbers can get very big */
-static ULong n_dlrr_calls =3D 0;
-static ULong n_BBs =3D 0;
-static ULong n_UInstrs =3D 0;
-static ULong n_guest_instrs =3D 0;
-static ULong n_Jccs =3D 0;
-static ULong n_Jccs_untaken =3D 0;
+static ULong n_func_calls =3D 0;
+static ULong n_BBs_entered =3D 0;
+static ULong n_BBs_completed =3D 0;
+static ULong n_IRStmts =3D 0;
+static ULong n_guest_instrs =3D 0;
+static ULong n_Jccs =3D 0;
+static ULong n_Jccs_untaken =3D 0;
=20
__attribute__((unused))
-static void add_one_dlrr_call(void)
+static void add_one_func_call(void)
{
- n_dlrr_calls++;
+ n_func_calls++;
}
=20
-/* See comment above lk_instrument for reason why n_machine_instrs is
- incremented here. */
-static void add_one_BB(void)
+static void add_one_BB_entered(void)
{
- n_BBs++;
- n_guest_instrs++;
+ n_BBs_entered++;
}
=20
+static void add_one_BB_completed(void)
+{
+ n_BBs_completed++;
+}
+
__attribute__((unused))
-static void add_one_UInstr(void)
+static void add_one_IRStmt(void)
{
- n_UInstrs++;
+ n_IRStmts++;
}
=20
__attribute__((unused))
@@ -78,52 +126,114 @@
n_Jccs_untaken++;
}
=20
-static void lk_post_clo_init(void)
+/***********************************************************************
+ * Data and helpers related to --detailed-counts.
+ **********************************************************************/
+
+/* --- Operations --- */
+
+typedef enum { OpLoad=3D0, OpStore=3D1, OpAlu=3D2 } Op;
+
+#define N_OPS 3
+
+
+/* --- Types --- */
+
+#define N_TYPES 9
+
+static Int type2index ( IRType ty )
{
+ switch (ty) {
+ case Ity_I1: return 0;
+ case Ity_I8: return 1;
+ case Ity_I16: return 2;
+ case Ity_I32: return 3;
+ case Ity_I64: return 4;
+ case Ity_I128: return 5;
+ case Ity_F32: return 6;
+ case Ity_F64: return 7;
+ case Ity_V128: return 8;
+ default: tl_assert(0); break;
+ }
}
=20
-/* Note: machine instructions are marked by an INCEIP at the end of each=
one,
- except for the final one in the basic block which ends in an
- unconditional JMP. Sometimes the final unconditional JMP is preceded=
by
- a conditional JMP (Jcc), and thus it isn't reached. Eg:
+static HChar* nameOfTypeIndex ( IRType ty )
+{
+ switch (ty) {
+ case 0: return "I1"; break;
+ case 1: return "I8"; break;
+ case 2: return "I16"; break;
+ case 3: return "I32"; break;
+ case 4: return "I64"; break;
+ case 5: return "I128"; break;
+ case 6: return "F32"; break;
+ case 7: return "F64"; break;
+ case 8: return "V128"; break;
+ default: tl_assert(0); break;
+ }
+}
=20
- <code a>
- INCEIP ...
=20
- <code b>
- Jcc ...
- JMP ... (will not be reached if Jcc succeeds)
+/* --- Counts --- */
=20
- If we simplemindedly added calls to add_one_guest_instr() before INCE=
IPs
- and unconditional JMPs, we'd sometimes miss the final call (when a
- preceding conditional JMP succeeds), underestimating the machine inst=
ruction
- count.
+static ULong detailCounts[N_OPS][N_TYPES];
=20
- <code a>
- call add_one_guest_instr()
- INCEIP ...
+/* The helper that is called from the instrumented code. */
+static VG_REGPARM(1)
+void increment_detail(ULong* detail)
+{
+ (*detail)++;
+}
=20
- <code b>
- Jcc ...
- call add_one_guest_instr()
- JMP ...
+/* A helper that adds the instrumentation for a detail. */
+static void instrument_detail(IRBB* bb, Op op, IRType type)
+{
+ IRDirty* di;
+ IRExpr** argv;
+ const UInt typeIx =3D type2index(type);
=20
- Instead we add a call before each INCEIP, and also one at the start o=
f the
- block, but not one at the end, viz:
+ tl_assert(op < N_OPS);
+ tl_assert(typeIx < N_TYPES);
=20
- call add_one_guest_instr()
+ argv =3D mkIRExprVec_1( mkIRExpr_HWord( (HWord)&detailCounts[op][type=
Ix] ) );
+ di =3D unsafeIRDirty_0_N( 1, "increment_detail", &increment_detail, a=
rgv);
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+}
=20
- <code a>
- call add_one_guest_instr()
- INCEIP ...
+/* Summarize and print the details. */
=20
- <code b>
- Jcc ...
- JMP ...
+static void print_details ( void )
+{
+ Int typeIx;
+ VG_(message)(Vg_UserMsg,
+ " Type Loads Stores AluOps");
+ VG_(message)(Vg_UserMsg,
+ " -------------------------------------------");
+ for (typeIx =3D 0; typeIx < N_TYPES; typeIx++) {
+ VG_(message)(Vg_UserMsg,
+ " %4s %,12llu %,12llu %,12llu",=20
+ nameOfTypeIndex( typeIx ),
+ detailCounts[OpLoad ][typeIx],
+ detailCounts[OpStore][typeIx],
+ detailCounts[OpAlu ][typeIx]
+ );
+ }
+}
=20
- Which gives us the right answer. And just to avoid two C calls, we f=
old
- the basic-block-beginning call in with add_one_BB(). Phew.
-*/=20
+
+/***********************************************************************
+ * Implement the basic_tool_funcs for Valgrind.
+ **********************************************************************/
+
+static void lk_post_clo_init(void)
+{
+ Int op, tyIx;
+
+ for (op =3D 0; op < N_OPS; op++)
+ for (tyIx =3D 0; tyIx < N_TYPES; tyIx++)
+ detailCounts[op][tyIx] =3D 0;
+}
+
static
IRBB* lk_instrument( IRBB* bb_in, VexGuestLayout* layout,=20
Addr64 orig_addr_noredir, VexGuestExtents* vge,
@@ -132,6 +242,8 @@
IRDirty* di;
Int i;
IRBB* bb;
+ Char fnname[100];
+ IRType type;
=20
if (gWordTy !=3D hWordTy) {
/* We don't currently support this case. */
@@ -144,135 +256,175 @@
bb->next =3D dopyIRExpr(bb_in->next);
bb->jumpkind =3D bb_in->jumpkind;
=20
-#if 0
- /* We need to know the entry point for this bb to do this. In any
- case it's pretty meaningless in the presence of bb chasing since
- we may enter this function part way through an IRBB. */
- /* Count call to dlrr(), if this BB is dlrr()'s entry point */
- if (VG_(get_fnname_if_entry)(orig_addr, fnname, 100) &&
- 0 =3D=3D VG_(strcmp)(fnname, "_dl_runtime_resolve"))=20
- {
- addStmtToIRBB(=20
- bb,
- IRStmt_Dirty(
- unsafeIRDirty_0_N( "add_one_dlrr_call", mkIRExprVec_0() )
- ));
+ // Copy verbatim any IR preamble preceding the first IMark
+ i =3D 0;
+ while (i < bb_in->stmts_used && bb_in->stmts[i]->tag !=3D Ist_IMark) =
{
+ addStmtToIRBB( bb, bb_in->stmts[i] );
+ i++;
}
-#endif
=20
- /* Count this basic block */
- di =3D unsafeIRDirty_0_N( 0, "add_one_BB", &add_one_BB, mkIRExprVec_0=
() );
+ /* Count this basic block. */
+ di =3D unsafeIRDirty_0_N( 0, "add_one_BB_entered", &add_one_BB_entere=
d,
+ mkIRExprVec_0() );
addStmtToIRBB( bb, IRStmt_Dirty(di) );
=20
- for (i =3D 0; i < bb_in->stmts_used; i++) {
+ for (/*use current i*/; i < bb_in->stmts_used; i++) {
IRStmt* st =3D bb_in->stmts[i];
- if (!st) continue;
+ if (!st || st->tag =3D=3D Ist_NoOp) continue;
=20
+ /* Count one VEX statement. */
+ di =3D unsafeIRDirty_0_N( 0, "add_one_IRStmt", &add_one_IRStmt,=20
+ mkIRExprVec_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+ =20
switch (st->tag) {
+ case Ist_IMark:
+ /* Count guest instruction. */
+ di =3D unsafeIRDirty_0_N( 0, "add_one_guest_instr",
+ &add_one_guest_instr,=20
+ mkIRExprVec_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+ =20
+ /* An unconditional branch to a known destination in the
+ * guest's instructions can be represented, in the IRBB to
+ * instrument, by the VEX statements that are the
+ * translation of that known destination. This feature is
+ * called 'BB chasing' and can be influenced by command
+ * line option --vex-guest-chase-thresh.
+ *
+ * To get an accurate count of the calls to a specific
+ * function, taking BB chasing into account, we need to
+ * check for each guest instruction (Ist_IMark) if it is
+ * the entry point of a function.
+ */
+ tl_assert(lk_clo_fnname);
+ tl_assert(lk_clo_fnname[0]);
+ if (VG_(get_fnname_if_entry)(st->Ist.IMark.addr,=20
+ fnname, sizeof(fnname))
+ && 0 =3D=3D VG_(strcmp)(fnname, lk_clo_fnname)) {
+ di =3D unsafeIRDirty_0_N( 0, "add_one_func_call",=20
+ &add_one_func_call,=20
+ mkIRExprVec_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+ }
+ addStmtToIRBB( bb, st );
+ break;
+
case Ist_Exit:
/* Count Jcc */
- addStmtToIRBB(=20
- bb,
- IRStmt_Dirty(
- unsafeIRDirty_0_N( 0, "add_one_Jcc", &add_one_Jcc,=20
- mkIRExprVec_0() )
- ));
- addStmtToIRBB( bb, dopyIRStmt(st) );
+ di =3D unsafeIRDirty_0_N( 0, "add_one_Jcc", &add_one_Jcc,=20
+ mkIRExprVec_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+
+ addStmtToIRBB( bb, st );
+
/* Count non-taken Jcc */
- addStmtToIRBB(=20
- bb,
- IRStmt_Dirty(
- unsafeIRDirty_0_N( 0, "add_one_Jcc_untaken", &add_one_=
Jcc_untaken,=20
- mkIRExprVec_0() )
- ));
+ di =3D unsafeIRDirty_0_N( 0, "add_one_Jcc_untaken",=20
+ &add_one_Jcc_untaken, mkIRExprVec=
_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
break;
=20
- default:
+ /* Someone on the users list asked for something like this
+ * just the other day (Christian Stimming, "Fast profiling in
+ * valgrind?", 25 Oct). Personally I think it'd be a
+ * valuable addition.
+ * =20
+ * Not hard to do either: for stores, examine Ist_Store, and
+ * use typeOfIRExpr(bb->tyenv, st->Ist.Store.data) to get the
+ * store type. For loads and ALU ops, you only need to look
+ * at Ist_Tmp cases where the Ist.Tmp.data is either Iex_Load
+ * or Iex_{Unop,Binop}. All statements you will ever
+ * encounter will satisfy isFlatIRStmt which essentially
+ * constrains them to being flat SSA-style.
+ */
+ case Ist_Store:
+ if (lk_clo_detailed_counts) {
+ type =3D typeOfIRExpr(bb->tyenv, st->Ist.Store.data);
+ tl_assert(type !=3D Ity_INVALID);
+ instrument_detail( bb, OpStore, type );
+ }
addStmtToIRBB( bb, st );
- }
- }
-
- return bb;
- =20
-
-#if 0
- UCodeBlock* cb;
- Int i;
- UInstr* u;
- Char fnname[100];
-
- cb =3D VG_(setup_UCodeBlock)(cb_in);
-
- /* Count basic block */
- VG_(call_helper_0_0)(cb, (Addr) & add_one_BB);
-
- for (i =3D 0; i < VG_(get_num_instrs)(cb_in); i++) {
- u =3D VG_(get_instr)(cb_in, i);
-
- switch (u->opcode) {
- case NOP: case LOCK: case CALLM_S: case CALLM_E:
break;
- =20
- case INCEIP:
- /* Count x86 instr */
- VG_(call_helper_0_0)(cb, (Addr) & add_one_x86_instr);
- VG_(copy_UInstr)(cb, u);
- break;
=20
- case JMP:
- if (u->cond !=3D CondAlways) {
- /* Count Jcc */
- VG_(call_helper_0_0)(cb, (Addr) & add_one_Jcc);
- VG_(copy_UInstr)(cb, u);
- /* Count non-taken Jcc */
- VG_(call_helper_0_0)(cb, (Addr) & add_one_Jcc_untaken);
- } else {
- VG_(copy_UInstr)(cb, u);
+ case Ist_Tmp:
+ if (lk_clo_detailed_counts) {
+ IRExpr* expr =3D st->Ist.Tmp.data;
+ type =3D typeOfIRExpr(bb->tyenv, expr);
+ tl_assert(type !=3D Ity_INVALID);
+ switch (expr->tag) {
+ case Iex_Load:
+ instrument_detail( bb, OpLoad, type );
+ break;
+ case Iex_Unop:
+ case Iex_Binop:
+ case Iex_Mux0X:
+ instrument_detail( bb, OpAlu, type );
+ break;
+ default:
+ break;
+ }
}
+ addStmtToIRBB( bb, st );
break;
=20
default:
- /* Count UInstr */
- VG_(call_helper_0_0)(cb, (Addr) & add_one_UInstr);
- VG_(copy_UInstr)(cb, u);
- break;
+ addStmtToIRBB( bb, st );
}
}
=20
- VG_(free_UCodeBlock)(cb_in);
- return cb;
-#endif
+ /* Count this basic block. */
+ di =3D unsafeIRDirty_0_N( 0, "add_one_BB_completed",=20
+ &add_one_BB_completed, mkIRExprVec_0() );
+ addStmtToIRBB( bb, IRStmt_Dirty(di) );
+
+ return bb;
}
=20
static void lk_fini(Int exitcode)
{
- VG_(message)(Vg_UserMsg,
- "Counted %d calls to _dl_runtime_resolve()", n_dlrr_cal=
ls);
+ char percentify_buf[4]; /* Two digits, '%' and 0. */
+ const int percentify_size =3D sizeof(percentify_buf);
+ const int percentify_decs =3D 0;
+ =20
+ tl_assert(lk_clo_fnname);
+ tl_assert(lk_clo_fnname[0]);
+ VG_(message)(Vg_UserMsg,
+ "Counted %,llu calls to %s()", n_func_calls, lk_clo_fnname);
=20
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg, "Executed:");
- VG_(message)(Vg_UserMsg, " BBs: %u", n_BBs);
- VG_(message)(Vg_UserMsg, " guest instrs: %u", n_guest_instrs);
- VG_(message)(Vg_UserMsg, " UInstrs: %u", n_UInstrs);
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg, "Jccs:");
+ VG_(message)(Vg_UserMsg, " total: %,llu", n_Jccs);
+ VG_(percentify)((n_Jccs - n_Jccs_untaken), (n_Jccs ? n_Jccs : 1),
+ percentify_decs, percentify_size, percentify_buf);
+ VG_(message)(Vg_UserMsg, " taken: %,llu (%s)",=20
+ (n_Jccs - n_Jccs_untaken), percentify_buf);
+ =20
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg, "Executed:");
+ VG_(message)(Vg_UserMsg, " BBs entered: %,llu", n_BBs_entered);
+ VG_(message)(Vg_UserMsg, " BBs completed: %,llu", n_BBs_completed);
+ VG_(message)(Vg_UserMsg, " guest instrs: %,llu", n_guest_instrs);
+ VG_(message)(Vg_UserMsg, " IRStmts: %,llu", n_IRStmts);
+ =20
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg, "Ratios:");
+ tl_assert(n_BBs_entered); // Paranoia time.
+ VG_(message)(Vg_UserMsg, " guest instrs : BB entered =3D %3u : 10",
+ 10 * n_guest_instrs / n_BBs_entered);
+ VG_(message)(Vg_UserMsg, " IRStmts : BB entered =3D %3u : 10",
+ 10 * n_IRStmts / n_BBs_entered);
+ tl_assert(n_guest_instrs); // Paranoia time.
+ VG_(message)(Vg_UserMsg, " IRStmts : guest instr =3D %3u : 10",
+ 10 * n_IRStmts / n_guest_instrs);
=20
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg, "Jccs:");
- VG_(message)(Vg_UserMsg, " total: %u", n_Jccs);
- VG_(message)(Vg_UserMsg, " %% taken: %u%%",
- (n_Jccs - n_Jccs_untaken)*100 /=20
- (n_Jccs ? n_Jccs : 1));
+ if (lk_clo_detailed_counts) {
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg, "IR-level counts by type:");
+ print_details();
+ }
=20
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg, "Ratios:");
- VG_(message)(Vg_UserMsg, " guest instrs : BB =3D %3u : 10",
- 10 * n_guest_instrs / n_BBs);
- VG_(message)(Vg_UserMsg, " UInstrs : BB =3D %3u : 10",
- 10 * n_UInstrs / n_BBs);
- VG_(message)(Vg_UserMsg, " UInstrs : x86_instr =3D %3u : 10",
- 10 * n_UInstrs / n_guest_instrs);
-
- VG_(message)(Vg_UserMsg, "");
- VG_(message)(Vg_UserMsg, "Exit code: %d", exitcode);
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg, "Exit code: %d", exitcode);
}
=20
static void lk_pre_clo_init(void)
@@ -288,6 +440,9 @@
VG_(basic_tool_funcs) (lk_post_clo_init,
lk_instrument,
lk_fini);
+ VG_(needs_command_line_options)(lk_process_cmd_line_option,
+ lk_print_usage,
+ lk_print_debug_usage);
}
=20
VG_DETERMINE_INTERFACE_VERSION(lk_pre_clo_init)
@@ -295,4 +450,3 @@
/*--------------------------------------------------------------------*/
/*--- end lk_main.c ---*/
/*--------------------------------------------------------------------*/
-
|
|
From: Julian S. <js...@ac...> - 2005-11-01 17:49:42
|
> Fixed test to not assume that malloc(10) will return 10 nul bytes! I also noticed that toobig_allocs fails on a 4G-userspace machine with tons of memory and swap (g5), because the allegedly-too-big malloc which is supposed to fail actually succeeds. Is on my todo list. J |
|
From: Julian S. <js...@ac...> - 2005-11-01 17:41:57
|
> Why not just increment the real global counter in-line? As opposed to > incrementing a temporary counter, and periodically adding it to global > counter? Ah yes, that never occurred to me. You could do that too (for a massive speedup) but in fact the two approaches (in-line increments vs rolling multiple increments into one) are independent and so could both be applied, which would give lackey a virtually insignificant overhead compared to no instrumentation at all. The only objection might be that then generated code would be accessing memory in areas that belong to V and not to the client. So it wouldn't have worked with pointercheck, but that's no longer the case. (Didn't JosefW have a similar problem some time back?) Whereas mediating everything through helper calls is 'cleaner' in some respect. > I'm happy for Lackey to change. Ok good. I'll commit what I have. J |
|
From: <sv...@va...> - 2005-11-01 17:21:05
|
Author: tom
Date: 2005-11-01 17:21:03 +0000 (Tue, 01 Nov 2005)
New Revision: 4978
Log:
Fixed test to not assume that malloc(10) will return 10 nul bytes!
Removed:
trunk/memcheck/tests/fwrite.stdout.exp
Modified:
trunk/memcheck/tests/fwrite.c
trunk/memcheck/tests/fwrite.stderr.exp
trunk/memcheck/tests/fwrite.stderr.exp2
Modified: trunk/memcheck/tests/fwrite.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/tests/fwrite.c 2005-11-01 17:15:50 UTC (rev 4977)
+++ trunk/memcheck/tests/fwrite.c 2005-11-01 17:21:03 UTC (rev 4978)
@@ -1,9 +1,17 @@
-
+#include <fcntl.h>
+#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main ( void )
{
char* arr =3D malloc(10);
- (void) write( 1 /* stdout */, arr, 10 );
+ int fd =3D open("/dev/null", O_WRONLY);
+ if (fd < 0) {
+ fprintf(stderr, "open failed\n");
+ } else {
+ (void)write(fd, arr, 10);
+ (void)close(fd);
+ }
+
return 0;
}
Modified: trunk/memcheck/tests/fwrite.stderr.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/tests/fwrite.stderr.exp 2005-11-01 17:15:50 UTC (rev 4=
977)
+++ trunk/memcheck/tests/fwrite.stderr.exp 2005-11-01 17:21:03 UTC (rev 4=
978)
@@ -4,4 +4,4 @@
by 0x........: ...
Address 0x........ is 0 bytes inside a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: main (fwrite.c:6)
+ by 0x........: main (fwrite.c:7)
Modified: trunk/memcheck/tests/fwrite.stderr.exp2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/tests/fwrite.stderr.exp2 2005-11-01 17:15:50 UTC (rev =
4977)
+++ trunk/memcheck/tests/fwrite.stderr.exp2 2005-11-01 17:21:03 UTC (rev =
4978)
@@ -1,6 +1,6 @@
Syscall param write(buf) points to uninitialised byte(s)
at 0x........: write (in /...libc...)
- by 0x........: main (fwrite.c:7)
+ by 0x........: main (fwrite.c:12)
Address 0x........ is 0 bytes inside a block of size 10 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: main (fwrite.c:6)
+ by 0x........: main (fwrite.c:7)
Deleted: trunk/memcheck/tests/fwrite.stdout.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/tests/fwrite.stdout.exp 2005-11-01 17:15:50 UTC (rev 4=
977)
+++ trunk/memcheck/tests/fwrite.stdout.exp 2005-11-01 17:21:03 UTC (rev 4=
978)
@@ -1 +0,0 @@
-=00=00=00=00=00=00=00=00=00=00
\ No newline at end of file
|
|
From: <sv...@va...> - 2005-11-01 17:15:53
|
Author: njn
Date: 2005-11-01 17:15:50 +0000 (Tue, 01 Nov 2005)
New Revision: 4977
Log:
update
Modified:
trunk/docs/internals/3_0_BUGSTATUS.txt
Modified: trunk/docs/internals/3_0_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-01 12:32:24 UTC (rev 4=
976)
+++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-01 17:15:50 UTC (rev 4=
977)
@@ -195,7 +195,7 @@
n-i-bz Print a more user-friendly message when vex bombs out
with unhandled instruction bytes
=20
-FIXED-TRUNK: is fixed (dunno rev #)
+FIXED-TRUNK: vg:4817,4932
FIXED-30BRANCH: TODO
=20
----------------------------------------------------------------
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 17:08:05
|
On Sun, 30 Oct 2005, Bryan Meredith wrote:
> Title
> =====
> Omega - A Valgrind tool for instant memory leak detection.
> Designed by Bryan "Brain Murders" Meredith with grateful thanks to the
> Valgrind team for making their tool and techniques available under the GPL.
Interesting :)
You should read this paper:
@InProceedings{Mae:precise2004,
author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
title = {Precise detection of memory leaks},
booktitle = {Proceedings of the Second International Workshop on Dynamic
Analysis (WODA 2004)},
pages = {},
address = {Edinburgh, Scotland},
month = may,
year = 2004,
summary = {Dynamic leak detector. Notable in that it detects the
leaks when they happen. Does this by doing reference
counting on each block, and tracking extra information about
each pointer. When a pointer is copied or clobbered, the
counts are updated. Per-pointer-info is stored in a tree,
with one part for stack pointers and the other half for the
rest. Some minor complications are used to avoid false
positives, eg. caused by advancing a pointer past the start
of the block and then later back. Memory values are
shadowed, registers not, but registers are all checked
linearly when necessary (eg. when deciding whether a block
has leaked). Implemented in DIOTA, not surprisingly the
current version runs programs 200--300 times slower.}
}
I haven't completely understood your scheme, but it's unclear to me how it
will work without reference counting.
> What Next?
> ==========
> I have to code it ;P
> I have produced this in order to obtain feedback as soon as possible on
> what will be a very useful tool both to my company and hopefully others.
> Any and all feedback gratefully received. I understand that some parts
> have probably been oversimplified and testing of the first
> implementation will reveal some shortcomings. The main thing is that the
> principle of using the 'V' bits to track pointers to allocated blocks is
> sound - implementation of the internal data structures for the allocated
> blocks, the reverse lookups and handling can be optimised over time as
> required and thus is not detailed here. This is not to say that I don't
> have a solution, it's just that it is one of many possible so not as
> interesting.
It sounds ok. In my experience the journey between the initial idea for a
tool and the resulting implementation can be tortuous (but hopefully not
torturous). The paper above should give you ideas about problems you
haven't thought of, but you won't really know if it's feasible until you
implement it. It looks like you've thought it through and have a good
idea of how Valgrind works which is an excellent start. Good luck :)
Feel free to ask more questions as you go.
Nick
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 16:47:16
|
On Sat, 29 Oct 2005, Greg Parker wrote: > Add this to your .emacs file: > > (add-hook 'c-mode-common-hook > #'(lambda () > ;; Use 3 space indent by default > (setq c-basic-offset 3) > ;; Never insert tab characters when indenting > (setq indent-tabs-mode nil) > ) > ) > > There's also `M-x untabify`, which changes all tab characters to > spaces in the current selection. Or if you use Vim: set tabstop=8 softtabstop=3 shiftwidth=3 expandtab Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 16:44:00
|
On Tue, 1 Nov 2005, Tom Hughes wrote: > Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-11-01 03:30:04 GMT > Results differ from 24 hours ago > > [...] > ================================================= > == Difference between 24 hours ago and now == > ================================================= > > *** old.short Tue Nov 1 03:35:14 2005 > --- new.short Tue Nov 1 03:40:14 2005 > *************** > *** 8,10 **** > > ! == 203 tests, 11 stderr failures, 4 stdout failures ================= > memcheck/tests/leak-tree (stderr) > --- 8,10 ---- > > ! == 203 tests, 13 stderr failures, 6 stdout failures ================= > memcheck/tests/leak-tree (stderr) > *************** > *** 19,20 **** > --- 19,22 ---- > none/tests/mremap2 (stdout) > + none/tests/pth_blockedsig (stdout) > + none/tests/pth_blockedsig (stderr) > none/tests/sigstackgrowth (stdout) > *************** > *** 23,24 **** > --- 25,28 ---- > none/tests/stackgrowth (stderr) > + none/tests/thread-exits (stdout) > + none/tests/thread-exits (stderr) > none/tests/x86/int (stderr) This machine exhibits a lot of test noise -- a number of tests fail and then work again for no apparent reason, and not just the common such ones (ie. 'tls' and 'yield'). Tom, any idea why? Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 16:39:29
|
On Sun, 30 Oct 2005, Jeroen N. Witmond wrote: > I don't like to burden Lackey with this, but I'll keep it in mind for the > next tool I'm working on: Blanket, a basic code coverage tool (mentioned > in '3.2.2. Suggested tools' in file docs/xml/writing-tools.xml). Some work has already gone into coverage tools. Benoit Peccatte was working on one earlier this year. Look for this email to valgrind-developers, and others from around the same time. Date: Fri, 29 Apr 2005 11:33:38 +0200 From: Benoit Peccatte <ben...@en...> To: val...@li... Subject: Re: [Valgrind-developers] Code Coverage I was also working on a coverage tool (VCov) then. I've put a tarball of my working source directory at www.cs.utexas.edu/~njn/vcov.tar.bz2. It is a bit old -- it uses Vex, but if you SVN update you'll have to make some changes to get it to compile again (if you just compile it as is it should work). vcov/vc_main.c is moderately well commented, so hopefully you'll be able to understand what's going on. vcov/vc_annotate.in is the annotation script. The approach taken relies totally on the debug information being present and correct -- I don't see how else to do it -- and I found that one version of GCC (3.3.4? can't remember now) was not producing correct debug info and so it wasn't working well. Anyway, IIRC it basically works, although I haven't tested it thoroughly. It should serve as a useful starting point, or perhaps you can think of a better way of doing things. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-11-01 16:26:48
|
On Sun, 30 Oct 2005, Julian Seward wrote:
>>>> - To count the number of guest instructions, I count the number of
>>>> Ist_IMark statements executed. Is this the correct approach?
>
> Yes, although you can (optionally) use a different strategy which is
> cheaper. Rather than call add_one_guest_instr each time an IMark
> is passed, make the instrumentation loop increment a counter when
> it passes an IMark. Then, either at the end of the BB or when you
> get to an Ist_Exit, call a (new) fn add_N_guest_instrs and pass it
> the counter. Then reset the counter to zero. In other words,
> call the instruction-counting function once for each piece of
> straight-line code. Cachegrind uses a similar strategy.
Why not just increment the real global counter in-line? As opposed to
incrementing a temporary counter, and periodically adding it to global
counter?
> Depending on what Nick thinks, and your hacking enthusiasm, there is
> something that would make Lackey more useful whilst still being a
> nice simple demo of how to make a tool. That is, generate counts
> for all the following events:
>
> guest instructions
> conditional branches (split into: taken, not taken)
> loads (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
> stores (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
> alu ops (split into: integer, FP, 64-bit SIMD, 128-bit SIMD)
>
> Someone on the users list asked for something like this just the
> other day (Christian Stimming, "Fast profiling in valgrind?", 25 Oct).
> Personally I think it'd be a valuable addition.
>
> Not hard to do either: for stores, examine Ist_Store, and use
> typeOfIRExpr(bb->tyenv, st->Ist.Store.data) to get the store type.
> For loads and ALU ops, you only need to look at Ist_Tmp cases
> where the Ist.Tmp.data is either Iex_Load or Iex_{Unop,Binop}.
> All statements you will ever encounter will satisfy isFlatIRStmt
> which essentially constrains them to being flat SSA-style.
I'm happy for Lackey to change. People very often ask how to get the
stream of memory accesses made by a program, I wrote "Dullard" (see
http://www.valgrind.org/downloads/variants.html?njn) to do this, but it's
based on 2.1.2 and so works with UCode.
It would be great if Lackey could give the memory accesses as well as the
info Julian suggested above, so it would serve as a much better example
tool. Ideally the different bits of functionality (getting instruction
counts, getting memory access traces) would be clearly delineated so that
people could chop out the bits they don't need easily... perhaps having
various options like --trace-mem-accesses, --do-instr-counts, etc, would
make this obvious.
As for efficiency, it might be best to keep things simple -- eg. one C
call per IMark -- but have comments that briefly describe how things might
be done more efficiently.
Nick
|