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
(1) |
|
2
(28) |
3
(21) |
4
(27) |
5
(22) |
6
(24) |
7
(25) |
8
(21) |
|
9
(18) |
10
(20) |
11
(10) |
12
(36) |
13
(18) |
14
(18) |
15
(29) |
|
16
(17) |
17
(7) |
18
(11) |
19
(17) |
20
(18) |
21
(12) |
22
(13) |
|
23
(9) |
24
(8) |
25
(7) |
26
(22) |
27
(18) |
28
(9) |
29
(15) |
|
30
(13) |
31
(7) |
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-10-08 23:50:05
|
On Sat, 8 Oct 2005, Josef Weidendorfer wrote: > Hmmm... this leads to a further question: Could a persistant translation cache > speed up Valgrind, by simply executing the "pre-translated" code chunks from > an earlier run? > In multiple runs, shared objects can be mapped to different addresses. So > the translation cache should be separated by shared objects. But this would > need a (object/offset) tuple as lookup key instead of a simple code address. See this paper from the recent WBIA workshop: http://rogue.colorado.edu/draco/papers/wbia05-persistence.pdf It's quite complicated to get it to work. Nick |
|
From: Josef W. <Jos...@gm...> - 2005-10-08 22:22:23
|
On Saturday 08 October 2005 23:25, Stephen McCamant wrote: > Current versions of Valgrind work less-than-perfectly with the latest > version of glibc in Debian unstable (Debian version 2.3.5-6). Part of > the problem seems to be that this build of libc6 manages to include > even less symbol information for /lib/ld-linux.so.2 than the 2.3.2 > build from sarge did (or it's in a format that Valgrind can't > handle). One of the relevant symbols is _dl_relocate_object, > ... AFAIK, this only happens if the runtime linker (/lib/ld-2.3.5.so) is stripped. Valgrind reads both the normal symbol table and the dynamic symbol table. The symbols disappeared from the dynamic table; and stripping gets rid of the normal symbol table. Actually, I do not understand why on earth a distribution ships a stripped runtime linker. Note that this has nothing to do with debug information (!). I fiddled around with this before the callgrind release, as I need to detect "_dl_runtime_resolve". After a bug report for a callgrind alpha, I suspected Suse 10.0 to be shipped with such a stripped runtime linker, but obviously they decided against. > Conditional jump or move depends on uninitialised value(s) > at 0x1B8ECB13: (within /lib/ld-2.3.5.so) > by 0x1B8E631C: (within /lib/ld-2.3.5.so) > by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) > by 0x1B8E7675: (within /lib/ld-2.3.5.so) > by 0x1B8E47C6: (within /lib/ld-2.3.5.so) There is a nice tool, the fenris debugger, see http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/fenris_index.cfm which includes a tool to regenerate the symbol table of a stripped lib or binary (by using fingerprints of function codes). Perhaps this way, you are able to "revive" the runtime linker? > where I got the first stack trace above). Unfortunately, I don't > believe there's any standard way (equivalent to LD_LIBRARY_PATH) to > tell programs to use a different dynamic linker: "/lib/ld-linux.so.2" > is hardcoded in binaries. There is: try "/lib/ld-linux.so.2 /bin/ls" You can start the runtime linker directly with the executables name as argument. This will run the executable with the specified runtime linker. > Since Valgrind loads ld-linux.so.2 for its guests, it would be helpful > if there was a way it could be told to switch in a different version. But only if there is one... Josef |
|
From: Stephen M.
|
Current versions of Valgrind work less-than-perfectly with the latest version of glibc in Debian unstable (Debian version 2.3.5-6). Part of the problem seems to be that this build of libc6 manages to include even less symbol information for /lib/ld-linux.so.2 than the 2.3.2 build from sarge did (or it's in a format that Valgrind can't handle). One of the relevant symbols is _dl_relocate_object, so this may just be a result of the gratuitous "sanitizing" that John Reiser was complaining about a few weeks ago (http://sourceforge.net/mailarchive/message.php?msg_id=12915644); the new libc is also compiled with a newer GCC ("Debian 4.0.1-3 / pre-4.0.2 20050725", instead of 3.3.5). One obvious symptom of this is that suppressions don't work. For instance, there's a longstanding problem whose correct stack trace is: Conditional jump or move depends on uninitialised value(s) at 0x40086B6: _dl_relocate_object (do-rel.h:65) by 0x4002376: dl_main (rtld.c:1916) by 0x400EBDD: _dl_sysdep_start (dl-sysdep.c:237) by 0x4003675: _dl_start (rtld.c:307) by 0x40007C6: (within /usr/lib/debug/ld-2.3.5.so) With the sarge libc, Valgrind can at least see the name of the function on top of the stack: Conditional jump or move depends on uninitialised value(s) at 0x4009620: _dl_relocate_object (in /lib/ld-2.3.2.so) by 0x400211C: (within /lib/ld-2.3.2.so) by 0x400F1F6: (within /lib/ld-2.3.2.so) by 0x4000F3A: (within /lib/ld-2.3.2.so) by 0x4000C26: (within /lib/ld-2.3.2.so) With the latest libc version, no symbol information shows up at all: Conditional jump or move depends on uninitialised value(s) at 0x1B8ECB13: (within /lib/ld-2.3.5.so) by 0x1B8E631C: (within /lib/ld-2.3.5.so) by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) by 0x1B8E7675: (within /lib/ld-2.3.5.so) by 0x1B8E47C6: (within /lib/ld-2.3.5.so) A similar problem seems to affect the {strlen,index}-not-intercepted-early-enough-HACK-* suppressions. These unsuppressed errors are the subject of Debian bug #326823, I believe. One potential fix for this problem is to use the debugging version of the dynamic linker, which has full static symbols (you can see it's where I got the first stack trace above). Unfortunately, I don't believe there's any standard way (equivalent to LD_LIBRARY_PATH) to tell programs to use a different dynamic linker: "/lib/ld-linux.so.2" is hardcoded in binaries. (This is especially annoying because the dynamic linkers from different versions of glibc are generally neither forward nor backward compatible with other versions of libc.so, so you can't have more than one glibc version installed at once. But that's a different rant.) It's possible to start a program with a different linker by saying something like "/usr/lib/debug/ld-linux.so.2 /bin/cat /proc/self/maps", but that isn't inherited by child processes, and it makes Valgrind report even more errors (I haven't investigated why). Since Valgrind loads ld-linux.so.2 for its guests, it would be helpful if there was a way it could be told to switch in a different version. I've appended a proof-of-concept patch that hard-codes the standard location of the debugging version. In brief testing, this change allows the suppressions to work correctly for me, and also seems to help Valgrind run better on a large program (XEmacs), perhaps because it makes some redirects work. By the way, are any of the Debian valgrind maintainers regular readers of this list? If not, I'll forward this information to the BTS. -- Stephen Index: coregrind/m_ume.c =================================================================== --- coregrind/m_ume.c (revision 4894) +++ coregrind/m_ume.c (working copy) @@ -530,19 +530,26 @@ case PT_INTERP: { char *buf = VG_(malloc)(ph->p_filesz+1); int j; - int intfd; + int intfd = -1; int baseaddr_set; vg_assert(buf); VG_(pread)(fd, buf, ph->p_filesz, ph->p_offset); buf[ph->p_filesz] = '\0'; - sres = VG_(open)(buf, VKI_O_RDONLY, 0); - if (sres.isError) { - VG_(printf)("valgrind: m_ume.c: can't open interpreter\n"); - VG_(exit)(1); + if (!VG_(strcmp)(buf, "/lib/ld-linux.so.2")) { + sres = VG_(open)("/usr/lib/debug/ld-linux.so.2", VKI_O_RDONLY, 0); + if (!sres.isError) + intfd = sres.val; } - intfd = sres.val; + if (intfd == -1) { + sres = VG_(open)(buf, VKI_O_RDONLY, 0); + if (sres.isError) { + VG_(printf)("valgrind: m_ume.c: can't open interpreter\n"); + VG_(exit)(1); + } + intfd = sres.val; + } interp = readelf(intfd, buf); if (interp == NULL) { |
|
From: Julian S. <js...@ac...> - 2005-10-08 21:20:53
|
> > Handle the out-of-range shift cases for slw/srw in a different way
> > which creates less IR and fewer insns at the back end. Worth about 2%
> > running bzip2 -d with --tool=none.
>
> how did you find out about optimizing this?
The new JIT does continuous low-overhead profiling of the bbs being
executed, on all architectures. I simply ran
valgrind --tool=none --profile-flags=10001000 bzip2 -tvv bigfile.bz2
and then read the immensely detailed result. The 1000.. stuff is the
same as for --trace-flags. This shows the initial code and the IR after
instrumentation and optimisation, for the most popular 100 translations.
To profile V more generally you can now do self-hosting and use cachegrind
(or calltree presumably). We had some fun with that a couple of weekends
ago -- I managed to run Qt designer running on valgrind --tool=none running
on valgrind --tool=cachegrind.
Before you ask ..
(1) Check out 2 trees, "inner" and "outer". "inner" runs the app
directly and is what you will be profiling. "outer" does the
profiling.
(2) Configure inner with --enable-inner and build/install as
usual.
(3) Configure outer normally and build/install as usual.
(4) Choose a very simple program (date) and try
outer/.../bin/valgrind --weird-hacks=enable-outer \
--tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog
It's fragile, confusing and slow, but it does work well enough for
you to get some useful performance data.
> Hmmm... this leads to a further question: Could a persistant translation
> cache speed up Valgrind
Very likely. Nobody has ever tried it afaik though.
J
|
|
From: Josef W. <Jos...@gm...> - 2005-10-08 20:45:12
|
On Saturday 08 October 2005 21:58, sv...@va... wrote: > Author: sewardj > Date: 2005-10-08 20:58:48 +0100 (Sat, 08 Oct 2005) > New Revision: 1418 > > Log: > Handle the out-of-range shift cases for slw/srw in a different way > which creates less IR and fewer insns at the back end. Worth about 2% > running bzip2 -d with --tool=none. Hi Julian, how did you find out about optimizing this? Obviously there doesn't exist any profiling tool which allows annotation of code in anonymous mappings, i.e. generated code by a VM or Valgrind. A while ago I had the idea to make Valgrinds translation cache persistant (backed up by a file with mmap). This way, a profile tool can annotate generated code (as the code relates to an existing file). Do you think this is possible? If yes, it would be even better if the TC could optionally loose its "cache character" and simply grow (if VM space allows this). If we additionally generate debug info, it should be possible to relate the generated code back to original client code. Hmmm... this leads to a further question: Could a persistant translation cache speed up Valgrind, by simply executing the "pre-translated" code chunks from an earlier run? In multiple runs, shared objects can be mapped to different addresses. So the translation cache should be separated by shared objects. But this would need a (object/offset) tuple as lookup key instead of a simple code address. Just ideas ;-) Josef |
|
From: <sv...@va...> - 2005-10-08 19:58:51
|
Author: sewardj
Date: 2005-10-08 20:58:48 +0100 (Sat, 08 Oct 2005)
New Revision: 1418
Log:
Handle the out-of-range shift cases for slw/srw in a different way
which creates less IR and fewer insns at the back end. Worth about 2%
running bzip2 -d with --tool=3Dnone.
Modified:
trunk/priv/guest-ppc32/toIR.c
Modified: trunk/priv/guest-ppc32/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-ppc32/toIR.c 2005-10-08 11:28:16 UTC (rev 1417)
+++ trunk/priv/guest-ppc32/toIR.c 2005-10-08 19:58:48 UTC (rev 1418)
@@ -3290,12 +3290,24 @@
case 0x018: // slw (Shift Left Word, PPC32 p505)
DIP("slw%s r%d,r%d,r%d\n", flag_Rc ? "." : "",
Ra_addr, Rs_addr, Rb_addr);
- assign( sh_amt, binop(Iop_And8, mkU8(0x1F),
- unop(Iop_32to8, mkexpr(Rb))) );
- assign( Rs_sh, binop(Iop_Shl32, mkexpr(Rs), mkexpr(sh_amt)) );
- assign( rb_b5, binop(Iop_And32, mkexpr(Rb), mkU32(1<<5)) );
- assign( Ra, IRExpr_Mux0X( unop(Iop_32to8, mkexpr(rb_b5)),
- mkexpr(Rs_sh), mkU32(0) ));
+ /* Ra =3D Rs << Rb */
+ /* ppc32 semantics are:=20
+ slw(x,y) =3D (x << (y & 31)) -- primary result
+ & ~((y << 26) >>s 31) -- make result 0=20
+ for y in 32 .. 63
+ */
+ assign(Ra,
+ binop(
+ Iop_And32,
+ binop( Iop_Shl32,=20
+ mkexpr(Rs),=20
+ unop( Iop_32to8,=20
+ binop(Iop_And32, mkexpr(Rb), mkU32(31)))),
+ unop( Iop_Not32,=20
+ binop( Iop_Sar32,=20
+ binop(Iop_Shl32, mkexpr(Rb), mkU8(26)),=20
+ mkU8(31))))
+ );
break;
=20
case 0x318: // sraw (Shift Right Algebraic Word, PPC32 p506)
@@ -3338,12 +3350,24 @@
case 0x218: // srw (Shift Right Word, PPC32 p508)
DIP("srw%s r%d,r%d,r%d\n", flag_Rc ? "." : "",
Ra_addr, Rs_addr, Rb_addr);
- assign( sh_amt, binop(Iop_And8, mkU8(0x1F),
- unop(Iop_32to8, mkexpr(Rb))) );
- assign( Rs_sh, binop(Iop_Shr32, mkexpr(Rs), mkexpr(sh_amt)) );
- assign( rb_b5, binop(Iop_And32, mkexpr(Rb), mkU32(1<<5)) );
- assign( Ra, IRExpr_Mux0X( unop(Iop_32to8, mkexpr(rb_b5)),
- mkexpr(Rs_sh), mkU32(0) ));
+ /* Ra =3D Rs >>u Rb */
+ /* ppc32 semantics are:=20
+ slw(x,y) =3D (x >>u (y & 31)) -- primary result
+ & ~((y << 26) >>s 31) -- make result 0=20
+ for y in 32 .. 63
+ */
+ assign(Ra,
+ binop(
+ Iop_And32,
+ binop( Iop_Shr32,=20
+ mkexpr(Rs),=20
+ unop( Iop_32to8,=20
+ binop(Iop_And32, mkexpr(Rb), mkU32(31)))),
+ unop( Iop_Not32,=20
+ binop( Iop_Sar32,=20
+ binop(Iop_Shl32, mkexpr(Rb), mkU8(26)),=20
+ mkU8(31))))
+ );
break;
=20
default:
|
|
From: <sv...@va...> - 2005-10-08 18:07:13
|
Author: njn Date: 2005-10-08 19:07:01 +0100 (Sat, 08 Oct 2005) New Revision: 214 Log: Close the survey. Modified: trunk/gallery/surveys.html trunk/index.html trunk/info/news.html Modified: trunk/gallery/surveys.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/gallery/surveys.html 2005-10-07 04:30:54 UTC (rev 213) +++ trunk/gallery/surveys.html 2005-10-08 18:07:01 UTC (rev 214) @@ -1,25 +1,22 @@ <h1>Surveys</h1> =20 <a name=3D"survey_05"></a> -<h3><a href=3D"/gallery/survey_current/survey.html">Survey 2 :=20 - September 2005</a></h3> +<h3>Survey 2 : September 2005</h3> =20 -<p>Beginning Thursday, September 22, we are running our=20 -<a href=3D"/gallery/survey_current/survey.html">second official survey</= a>. +<p>From September 22 to October 08 we ran our second official survey=20 +and received 180 responses. Thanks to all those who participated. +An analysis of the responses will be posted soon.</p> Even if you completed a prior survey, we'd like your response to this survey, because the questions have probably changed since you last responded.</p> =20 +<!-- <p>Survey responses tell us what is good and bad about Valgrind, sate our curiosity about how it is used, and encourage us to continue our efforts. By completing the survey, you are supporting Valgrind, and helping us to improve it.</p> +--> =20 -<p>We will close the survey in a week or so, depending on the response -rate. We will collate the responses and post an analysis some time afte= r -that. Thank you for your participation.</p> - - <a name=3D"surveys_03_05"></a> <h3>Ongoing Surveys : December 2003--August 2005</h3> =20 Modified: trunk/index.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/index.html 2005-10-07 04:30:54 UTC (rev 213) +++ trunk/index.html 2005-10-08 18:07:01 UTC (rev 214) @@ -36,15 +36,9 @@ <h2 align=3D"center">Recent News</h2> =20 <ul> + <li><p>October 8 2005: Our survey is over. Thanks to all those who + participated. An analysis will be posted soon.</p></li> =20 - <li><p>September 22 2005: Please fill out our=20 - <a href=3D"/gallery/surveys.html">survey</a>. We will close - the survey in about one week's time, depending on the response rate. - <b>Update:</b> We are extending the survey by one week because we - are still getting a good number of responses each day. Please fill - out a survey if you have not already. - </p></li> - <li><p>August 29 2005: Valgrind 3.0.1, for x86-linux and amd64-linux,=20 is available (<a href=3D"/info/release-notes-3.0.1.txt">release notes</a>).</p></li> Modified: trunk/info/news.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/info/news.html 2005-10-07 04:30:54 UTC (rev 213) +++ trunk/info/news.html 2005-10-08 18:07:01 UTC (rev 214) @@ -7,6 +7,9 @@ =20 <ul> =20 + <li><p>October 8 2005: Our survey is over. Thanks to all those who + participated. An analysis will be posted soon.</p></li> + <li><p>September 22 2005: Please fill out our=20 <a href=3D"/gallery/surveys.html">survey</a>. We will close the survey in about one week's time, depending on the response rate. |
|
From: <sv...@va...> - 2005-10-08 18:01:59
|
Author: njn Date: 2005-10-08 19:01:54 +0100 (Sat, 08 Oct 2005) New Revision: 4895 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-10-07 23:06:13 UTC (rev 4= 894) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-10-08 18:01:54 UTC (rev 4= 895) @@ -16,6 +16,7 @@ 109744 memcheck loses track of mmap from direct ld-linux.so.2 110183 tail of page with _end 82301 FV memory layout too rigid + 98278 Infinite recursion possible when allocating memory =20 Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel not liking large mmap/munmap requests. Other bugs also look like |
|
From: <sv...@va...> - 2005-10-08 11:28:24
|
Author: sewardj
Date: 2005-10-08 12:28:16 +0100 (Sat, 08 Oct 2005)
New Revision: 1417
Log:
Enable chasing of unconditional branches and calls.
Modified:
trunk/priv/guest-ppc32/toIR.c
Modified: trunk/priv/guest-ppc32/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-ppc32/toIR.c 2005-10-07 09:45:16 UTC (rev 1416)
+++ trunk/priv/guest-ppc32/toIR.c 2005-10-08 11:28:16 UTC (rev 1417)
@@ -2846,7 +2846,9 @@
/*
Integer Branch Instructions
*/
-static Bool dis_branch ( UInt theInstr, DisResult* dres )
+static Bool dis_branch ( UInt theInstr,=20
+ /*OUT*/DisResult* dres,
+ Bool (*resteerOkFn)(Addr64) )
{
UChar opc1 =3D toUChar((theInstr >> 26) & 0x3F); /* theInstr[2=
6:31] */
UChar BO =3D toUChar((theInstr >> 21) & 0x1F); /* theInstr[2=
1:25] */
@@ -2863,22 +2865,21 @@
=20
Addr32 nia =3D 0;
=20
- // IRTemp ctr =3D newTemp(Ity_I32);
- // IRTemp lr =3D newTemp(Ity_I32);
IRTemp ir_nia =3D newTemp(Ity_I32);
IRTemp do_branch =3D newTemp(Ity_I32);
IRTemp ctr_ok =3D newTemp(Ity_I32);
IRTemp cond_ok =3D newTemp(Ity_I32);
=20
-// assign( ctr, getSPR( PPC32_SPR_CTR ) );
-
/* Hack to pass through code that just wants to read the PC */
if (theInstr =3D=3D 0x429F0005) {
DIP("bcl 0x%x, 0x%x (a.k.a mr lr,cia+4)\n", BO, BI);
putSPR( PPC32_SPR_LR, mkU32(guest_CIA_curr_instr + 4) );
return True;
}
- =20
+
+ /* The default what-next. Individual cases can override it. */ =20
+ dres->whatNext =3D Dis_StopHere;
+
switch (opc1) {
case 0x12: // b (Branch, PPC32 p360)
if (flag_AA) {
@@ -2890,9 +2891,15 @@
=20
if (flag_LK) {
putSPR( PPC32_SPR_LR, mkU32(guest_CIA_curr_instr + 4) );
- } =20
- irbb->jumpkind =3D flag_LK ? Ijk_Call : Ijk_Boring;
- irbb->next =3D mkU32(nia);
+ }
+
+ if (resteerOkFn((Addr64)nia)) {
+ dres->whatNext =3D Dis_Resteer;
+ dres->continueAt =3D (Addr64)nia;
+ } else {
+ irbb->jumpkind =3D flag_LK ? Ijk_Call : Ijk_Boring;
+ irbb->next =3D mkU32(nia);
+ }
break;
=20
case 0x10: // bc (Branch Conditional, PPC32 p361)
@@ -3006,12 +3013,12 @@
return False;
}
break;
+
default:
vex_printf("dis_int_branch(PPC32)(opc1)\n");
return False;
}
=20
- dres->whatNext =3D Dis_StopHere;
return True;
}
=20
@@ -6659,7 +6666,7 @@
=20
/* Branch Instructions */
case 0x12: case 0x10: // b, bc
- if (dis_branch(theInstr, &dres)) goto decode_success;
+ if (dis_branch(theInstr, &dres, resteerOkFn)) goto decode_success;
goto decode_failure;
=20
/* System Linkage Instructions */
@@ -6776,7 +6783,7 @@
=20
/* Branch Instructions */
case 0x210: case 0x010: // bcctr, bclr
- if (dis_branch(theInstr, &dres)) goto decode_success;
+ if (dis_branch(theInstr, &dres, resteerOkFn)) goto decode_su=
ccess;
goto decode_failure;
=20
/* Memory Synchronization Instructions */
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-08 11:00:53
|
> >> Ah that's right. I new there was something wierd about it. Julian >> and I discussed it and decided it wasn't worth trying to make it >> work so I think he disabled the test. > > We did discuss it and concluded it was too unrepresentative > of any real program to be worth catering specially for. But the > strange thing is I didn't disable it in the regtest system: > > sewardj@phoenix:~/VgTRUNK/trunk$ perl tests/vg_regtest none/tests/execve > execve: valgrind ./execve > > == 1 test, 0 stderr failures, 0 stdout failures ================= > > Maybe its loopfulness depends on which directory it is run from. > The loopfulness is caused by option --trace-children=yes, which is not used in the regression test. Jeroen. |
|
From: Julian S. <js...@ac...> - 2005-10-08 09:55:29
|
> Ah that's right. I new there was something wierd about it. Julian > and I discussed it and decided it wasn't worth trying to make it > work so I think he disabled the test. We did discuss it and concluded it was too unrepresentative of any real program to be worth catering specially for. But the strange thing is I didn't disable it in the regtest system: sewardj@phoenix:~/VgTRUNK/trunk$ perl tests/vg_regtest none/tests/execve execve: valgrind ./execve == 1 test, 0 stderr failures, 0 stdout failures ================= Maybe its loopfulness depends on which directory it is run from. J |
|
From: Tom H. <to...@co...> - 2005-10-08 07:06:43
|
In message <4880.194.109.230.85.1128754833.squirrel@194.109.230.85>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> > none/tests/execve.c is weird. It just calls execve() on itself. Running
> > under Valgrind with --trace-children=yes I get an endless recursion.
> > Running it normally from the shell I don't get that. Any ideas what is
> > going on?
>
> This is a feature of execve that probably cannot be similated by Valgrind,
> see coregrind/m_syswrap/syswrap-generic.c from line 2419. The name of the
> exe actually executed is in ARG1, the name to be shown to the user in
> ARG2[0]. execve.c passes NULL in ARG2[0], preventing recursion. There
> seems to be no way to tell Valgrind with --trace-children=yes to do the
> same.
Ah that's right. I new there was something wierd about it. Julian
and I discussed it and decided it wasn't worth trying to make it
work so I think he disabled the test.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-08 07:00:42
|
Hi, > none/tests/execve.c is weird. It just calls execve() on itself. Running > under Valgrind with --trace-children=yes I get an endless recursion. > Running it normally from the shell I don't get that. Any ideas what is > going on? This is a feature of execve that probably cannot be similated by Valgrind, see coregrind/m_syswrap/syswrap-generic.c from line 2419. The name of the exe actually executed is in ARG1, the name to be shown to the user in ARG2[0]. execve.c passes NULL in ARG2[0], preventing recursion. There seems to be no way to tell Valgrind with --trace-children=yes to do the same. Jeroen. |
|
From: Tom H. <to...@co...> - 2005-10-08 06:41:03
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> none/tests/execve.c is weird. It just calls execve() on itself. Running
> under Valgrind with --trace-children=yes I get an endless recursion.
> Running it normally from the shell I don't get that. Any ideas what is
> going on?
It passes an argument to itself though which is supposed to stop
the recursion.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2005-10-08 02:56:49
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-08 03:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 190 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2005-10-08 02:40:10
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-08 03:30:07 BST 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 == 192 tests, 12 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/int (stderr) none/tests/x86/sigcontext (stdout) none/tests/x86/sigcontext (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 == 192 tests, 13 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_pipe (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 8 03:35:09 2005 --- new.short Sat Oct 8 03:40:05 2005 *************** *** 8,10 **** ! == 192 tests, 13 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) --- 8,10 ---- ! == 192 tests, 12 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) *************** *** 12,14 **** memcheck/tests/pointer-trace (stderr) - memcheck/tests/realloc2 (stderr) memcheck/tests/weirdioctl (stderr) --- 12,13 ---- *************** *** 17,19 **** none/tests/faultstatus (stderr) - none/tests/fdleak_pipe (stderr) none/tests/map_unmap (stdout) --- 16,17 ---- *************** *** 26,27 **** --- 24,27 ---- none/tests/x86/int (stderr) + none/tests/x86/sigcontext (stdout) + none/tests/x86/sigcontext (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-08 02:27:45
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-08 03:15:02 BST 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 == 191 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-08 02:25:34
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-10-08 03:10:07 BST 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 == 191 tests, 4 stderr failures, 0 stdout failures ================= memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-08 02:22:30
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-08 03:00:04 BST 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 == 166 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) ================================================= == 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 == 166 tests, 9 stderr failures, 2 stdout failures ================= memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 8 03:09:32 2005 --- new.short Sat Oct 8 03:22:16 2005 *************** *** 8,11 **** ! == 166 tests, 9 stderr failures, 2 stdout failures ================= ! memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 166 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-08 02:21:28
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-08 03:10:07 BST 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 == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 166 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 8 03:17:20 2005 --- new.short Sat Oct 8 03:21:19 2005 *************** *** 8,11 **** ! == 166 tests, 8 stderr failures, 2 stdout failures ================= ! memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-08 02:19:11
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-08 03:05:12 BST 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 == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 166 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 8 03:13:46 2005 --- new.short Sat Oct 8 03:19:00 2005 *************** *** 8,11 **** ! == 166 tests, 8 stderr failures, 2 stdout failures ================= ! memcheck/tests/mempool (stderr) memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) |