You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Dirk M. <mu...@kd...> - 2003-11-27 09:08:21
|
CVS commit by mueller:
reverting last commit, which broke all of valgrind.
M +4 -3 vg_proxylwp.c 1.8
--- valgrind/coregrind/vg_proxylwp.c #1.7:1.8
@@ -895,6 +895,4 @@ static Int proxy_clone(ProxyLWP *proxy)
Int ret = -1;
- proxy->lwp = -1;
-
if (have_settid != 0) {
ret = VG_(clone)(proxylwp,
@@ -921,9 +919,11 @@ static Int proxy_clone(ProxyLWP *proxy)
}
}
+ else
+ have_settid = 1;
}
if (ret < 0) {
vg_assert(have_settid == 0);
- vg_assert(proxy->lwp == -1);
+ vg_assert(proxy->lwp == 0);
ret = VG_(clone)(proxylwp,
|
|
From: Jeremy F. <je...@go...> - 2003-11-27 08:11:49
|
CVS commit by fitzhardinge:
Fix up the have_settid test so it works on both plain 2.4 and 2.6 kernels.
I think this will also work on SuSE kernels.
M +26 -12 vg_proxylwp.c 1.7
--- valgrind/coregrind/vg_proxylwp.c #1.6:1.7
@@ -893,5 +893,7 @@ static Int have_settid = -1; /* -1 -> un
static Int proxy_clone(ProxyLWP *proxy)
{
- Int ret;
+ Int ret = -1;
+
+ proxy->lwp = -1;
if (have_settid != 0) {
@@ -899,18 +901,30 @@ static Int proxy_clone(ProxyLWP *proxy)
LWP_stack(proxy),
VKI_CLONE_FS | VKI_CLONE_FILES | VKI_CLONE_VM |
- VKI_CLONE_SIGHAND | VKI_CLONE_THREAD /*|
- VKI_CLONE_PARENT_SETTID
- VKI_CLONE_CHILD_CLEARTID | VKI_CLONE_DETACHED*/,
+ VKI_CLONE_SIGHAND | VKI_CLONE_THREAD |
+ VKI_CLONE_PARENT_SETTID |
+ VKI_CLONE_CHILD_CLEARTID | VKI_CLONE_DETACHED,
proxy, &proxy->lwp, &proxy->lwp);
- if ( have_settid < 0 && !proxy->lwp ) {
+
+ if ( have_settid == -1 && (ret < 0 || proxy->lwp == 0) ) {
have_settid = 0;
+
+ /* Assume that not having parent_settid also means that we've
+ got 2.4-style signal handling, which means we need to do
+ more work. */
+ VG_(do_signal_routing) = True;
+
+ if (ret > 0) {
+ /* If clone actually succeeded and just ignored the
+ CLONE_PARENT_SETTID flag, then use the LWP it created
+ for us. */
proxy->lwp = ret;
- VG_(do_signal_routing) = True; /* XXX True, it seems kernels
- which have futex also have
- sensible signal handling, but
- it would be nice to test it
- directly. */
}
- } else {
+ }
+ }
+
+ if (ret < 0) {
+ vg_assert(have_settid == 0);
+ vg_assert(proxy->lwp == -1);
+
ret = VG_(clone)(proxylwp,
LWP_stack(proxy),
|
|
From: Dirk M. <mu...@kd...> - 2003-11-27 02:17:16
|
CVS commit by mueller:
test for PARENT_SETTID support in clone() of the kernel instead
of testing for presence of NPTL by assuming that sys_futex is only
implemented when its a NPTL patched kernel.
M +0 -2 vg_include.h 1.157
M +0 -9 vg_main.c 1.126
M +20 -21 vg_proxylwp.c 1.6
--- valgrind/coregrind/vg_include.h #1.156:1.157
@@ -244,6 +244,4 @@ extern Char* VG_(clo_weird_hacks);
signals. */
extern Int VG_(clo_signal_polltime);
-/* Assume we're running on a plain 2.4 kernel */
-extern Bool VG_(clo_assume_24);
/* Low latency syscalls and signals */
--- valgrind/coregrind/vg_main.c #1.125:1.126
@@ -570,7 +570,4 @@ static Bool VG_(clo_wait_for_gdb) =
Int VG_(clo_signal_polltime) = 50;
-/* If true, assume we're running on a plain 2.4 kernel */
-Bool VG_(clo_assume_24) = False;
-
/* These flags reduce thread wakeup latency on syscall completion and
signal delivery, respectively. The downside is possible unfairness. */
@@ -678,5 +675,4 @@ static void usage ( void )
" --lowlat-syscalls=no|yes improve wake-up latency when a thread's\n"
" syscall completes [no]\n"
-" --assume-2.4=no|yes assume we're running on a 2.4 kernel [no]\n"
"\n"
" %s tool user options:\n";
@@ -1126,9 +1122,4 @@ static void process_cmd_line_options ( v
else if (VG_CLO_STREQ(argv[i], "--lowlat-syscalls=no"))
VG_(clo_lowlat_syscalls) = False;
-
- else if (VG_CLO_STREQ(argv[i], "--assume-2.4=yes"))
- VG_(clo_assume_24) = True;
- else if (VG_CLO_STREQ(argv[i], "--assume-2.4=no"))
- VG_(clo_assume_24) = False;
else if (VG_CLO_STREQN(13, argv[i], "--stop-after="))
--- valgrind/coregrind/vg_proxylwp.c #1.5:1.6
@@ -883,5 +883,5 @@ static Int do_futex(void *addr, Int op,
#define VKI_FUTEX_REQUEUE 3
-static Int have_futex = -1; /* -1 -> unknown */
+static Int have_settid = -1; /* -1 -> unknown */
/*
@@ -895,19 +895,15 @@ static Int proxy_clone(ProxyLWP *proxy)
Int ret;
- if (VG_(clo_assume_24))
- have_futex = 0;
-
- if (have_futex == -1)
- have_futex = do_futex(NULL, VKI_FUTEX_WAKE, 0, NULL, NULL) != -VKI_ENOSYS;
-
- if (have_futex) {
+ if (have_settid != 0) {
ret = VG_(clone)(proxylwp,
LWP_stack(proxy),
VKI_CLONE_FS | VKI_CLONE_FILES | VKI_CLONE_VM |
- VKI_CLONE_SIGHAND | VKI_CLONE_THREAD |
- VKI_CLONE_PARENT_SETTID |
- VKI_CLONE_CHILD_CLEARTID | VKI_CLONE_DETACHED,
+ VKI_CLONE_SIGHAND | VKI_CLONE_THREAD /*|
+ VKI_CLONE_PARENT_SETTID
+ VKI_CLONE_CHILD_CLEARTID | VKI_CLONE_DETACHED*/,
proxy, &proxy->lwp, &proxy->lwp);
- } else {
+ if ( have_settid < 0 && !proxy->lwp ) {
+ have_settid = 0;
+ proxy->lwp = ret;
VG_(do_signal_routing) = True; /* XXX True, it seems kernels
which have futex also have
@@ -915,5 +911,6 @@ static Int proxy_clone(ProxyLWP *proxy)
it would be nice to test it
directly. */
-
+ }
+ } else {
ret = VG_(clone)(proxylwp,
LWP_stack(proxy),
@@ -932,12 +929,12 @@ static Bool proxy_wait(ProxyLWP *proxy,
Bool ret = False;
- if (have_futex == -1)
+ if (have_settid == -1)
return False;
- if (have_futex) {
+ if (have_settid) {
if (block) {
Int lwp = proxy->lwp;
- while(proxy->lwp != 0)
+ if(proxy->lwp != 0)
do_futex(&proxy->lwp, VKI_FUTEX_WAIT, lwp, NULL, NULL);
@@ -985,4 +982,6 @@ void VG_(proxy_create)(ThreadId tid)
proxy->tid = tid;
proxy->tst = tst;
+ proxy->exitcode = 0;
+ proxy->lwp = 0;
proxy->siginfo.si_signo = 0;
proxy->frommain = VG_(safe_fd)(p[0]);
@@ -1313,5 +1312,5 @@ void VG_(proxy_sanity)(void)
ThreadState *tst = &VG_(threads)[tid];
ProxyLWP *px;
- Int status;
+ Int status = 0;
Int ret;
|
|
From: dave t. <da...@co...> - 2003-11-26 10:01:09
|
Apologies for the direct email. I have a current need for debugging a memory leak in an application based on solaris. Back luck for me, that I only have access to some solaris compiled libraries (src is not available to me). I did try and download and install valgrind 2.0.0 but see configure confirm it's ix86 specific. Is a solaris version of valgrind ever likely ? -Dave Dave Tilley Staff Customer Applications Engineer CoWare Europe Ltd, United Kingdom |
|
From: Dirk M. <mu...@kd...> - 2003-11-24 21:26:09
|
CVS commit by mueller: add missing include files to spec file listing M +3 -0 valgrind.spec.in 1.9 --- valgrind/valgrind.spec.in #1.8:1.9 @@ -42,4 +42,7 @@ /usr/include/valgrind/memcheck.h /usr/include/valgrind/helgrind.h +/usr/include/valgrind/vg_constants_skin.h +/usr/include/valgrind/vg_kerneliface.h +/usr/include/valgrind/vg_skin.h /usr/bin/valgrind /usr/bin/cg_annotate |
|
From: Dirk M. <mu...@kd...> - 2003-11-24 21:25:30
|
CVS commit by mueller: fix spec file error M +3 -0 valgrind.spec.in 1.8.2.1 --- valgrind/valgrind.spec.in #1.8:1.8.2.1 @@ -42,4 +42,7 @@ /usr/include/valgrind/memcheck.h /usr/include/valgrind/helgrind.h +/usr/include/valgrind/vg_constants_skin.h +/usr/include/valgrind/vg_kerneliface.h +/usr/include/valgrind/vg_skin.h /usr/bin/valgrind /usr/bin/cg_annotate |
|
From: Nicholas N. <nj...@ca...> - 2003-11-24 14:54:29
|
CVS commit by nethercote:
User in Singapore
M +2 -2 overview.html 1.5
--- devel-home/valgrind/overview.html #1.4:1.5
@@ -73,6 +73,6 @@
Denmark, Finland, France, Germany, Greece, Hungary, Italy, The
Netherlands, Norway, Poland, Russia, Sweden, Switzerland, UK,
- Argentina, Brazil, Canada, USA, Australia, Japan, New Zealand, South
- Africa and Israel.
+ Argentina, Brazil, Canada, USA, Australia, Japan, New Zealand, Singapore,
+ South Africa and Israel.
<p>
<li><b>Valgrind works with programs written in any language.</b>
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-24 12:11:26
|
CVS commit by nethercote: Minor fixes, inc. slightly more detail about NASA's use of Valgrind. M +1 -1 features.html 1.4 M +1 -1 index.html 1.9 M +4 -3 overview.html 1.4 M +2 -2 tools.html 1.3 --- devel-home/valgrind/features.html #1.3:1.4 @@ -9,5 +9,5 @@ <center><h2>Feature Requests</h2></center> -If that fails, please use our +To request a feature, please use our <a href="http://bugs.kde.org/enter_valgrind_bug.cgi">Bugzilla page</a>; make an entry with the severity "wishlist". Please note that this --- devel-home/valgrind/index.html #1.8:1.9 @@ -19,5 +19,5 @@ detailed profiling to help speed up your programs. <p> -The Valgrind distribution include four tools: two memory error +The Valgrind distribution includes four tools: two memory error detectors, a thread error detector, and a cache profiler. Several other tools have been built with Valgrind. --- devel-home/valgrind/overview.html #1.3:1.4 @@ -64,7 +64,7 @@ transaction servers, compilers, interpreters, virtual machines, telecom applications, embedded software, medical imaging, scientific - programming, signal processing, video/audio programs, NASA - simulations, business intelligence software, financial/banking - software, operating system daemons, etc, etc. + programming, signal processing, video/audio programs, NASA Mars lander + vision and rover navigation systems, business intelligence software, + financial/banking software, operating system daemons, etc, etc. <p> <li><b>Valgrind is widely used.</b> Valgrind has been used by thousands @@ -151,4 +151,5 @@ information about how your program is spending its time, or you want to speed it up. +<p> <?php --- devel-home/valgrind/tools.html #1.2:1.3 @@ -74,5 +74,5 @@ purposes. <p> -<hr> +<!--<hr> <center><h2>Examples of Use</h2></center> @@ -83,5 +83,5 @@ TODO: add examples of use - +--> <?php include "footer.inc" |
|
From: Jeremy F. <je...@go...> - 2003-11-21 09:22:36
|
CVS commit by fitzhardinge:
*8 is probably overkill
M +1 -1 sigaltstack.c 1.5
--- valgrind/memcheck/tests/sigaltstack.c #1.4:1.5
@@ -15,5 +15,5 @@ int main(int argv, char** argc) {
stack_t sigstk;
struct sigaction act;
- static const int size = SIGSTKSZ*8;
+ static const int size = SIGSTKSZ*2;
char *stk = (char *)mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
sigstk.ss_sp = stk;
|
|
From: Jeremy F. <je...@go...> - 2003-11-21 09:07:23
|
CVS commit by fitzhardinge:
fprintf needs more than 8k of stack, so boost the sigaltstack size.
M +1 -1 sigaltstack.c 1.4
--- valgrind/memcheck/tests/sigaltstack.c #1.3:1.4
@@ -15,5 +15,5 @@ int main(int argv, char** argc) {
stack_t sigstk;
struct sigaction act;
- static const int size = SIGSTKSZ;
+ static const int size = SIGSTKSZ*8;
char *stk = (char *)mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
sigstk.ss_sp = stk;
|
|
From: Jeremy F. <je...@go...> - 2003-11-21 00:19:05
|
On Thu, 2003-11-20 at 16:27, Julian Seward wrote: > > Ideally, we want a cheap way of detecting s-m-c that can be on all the > > time (then we could get rid of the INVALIDATE_TRANSLATIONS macro). I have > > an extremely vague idea about tracking things at the page level, and > > possibly throwing out all translations that come from code within a page > > in certain circumstances. Or something. Hmm. > > Well, there are some options, but none are good. > > One is (or might be, depending on Jeremy's views) to mess with page level > permissions, so as to remove write permission for any page from which we've > taken a translation. Then V takes a page fault whenever writes to that page > happen; we catch the fault, note the page as dirty and throw away translations > from it as soon as possible. So we freeload on the host's memory protection > hardware and have zero run-time overhead. Well, taking an exception is fairly expensive, and this scheme won't work well at all with this case, since there are probably going to be lots of writes to the same page as the code itself, because it's the stack (which is something the P4 hates anyway...). But as I mentioned, we can somewhat special case this because we can see that we're fetching instructions from near the ESP, which means that 1) they're probably dynamically generated, and 2) have a fairly short lifespan. In fact, if we had one, they'd be a good candidate for interpretation rather than generating code at all. (A UCode interpreter might be pretty useful in other places too, and would be interesting to write.) Also, in the new memory management I've written as part of FV, I explicitly keep track of a CODE flag per segment, so we can easily tell which mapped parts of the address space have code in them. So that alone would be enough to tell if a segment suddenly grows some code. > Another is the pure-software approach in very old valgrinds. I think what I > had was an array of char indexed by addr>>12 or some such (that would be > 2^20 bytes on a 32-bit machine); and there was some kind of check or > something at each write. Not cheap, but you could drastically reduce the > cost by only testing some writes -- for example, writes from the FPU are > most unlikely to generate code, and writes happening as part of a > read-op-write operation x86 insn are also unlikely to. Also I think I > excluded writes of sizes > 1 since it doesn't make much sense to write > x86 code on a word-by-word basis, since it's really a byte stream. Unless someone memcpys some code onto the stack in word-sized chunks. Another not-fully-formed idea: If we're translating a piece of code where we think the code may get overwritten in the near future (ie, stack thunks), how about we generate some code into the BB itself, to check it's own validity. If it decides that the translated code is out of date, it would drop back into the scheduler asking for a re-translation. The tricky bit is deciding on a predicate which would allow it to determine if it is out of date or not. Looking at %esp is one (if its above the code, then its dead), and in memcheck, it could look at the V bits of its own orig_addr. Hm, but neither of these would work in this case... I guess a checksum of the orig code would do it - slow, but for this case it wouldn't matter much. > Personally I prefer the portability/system independence of the pure-sw > approach. IIRC the optimised version didn't give much overhead, but I > can't really remember any more, and I don't think I have a copy of the > code base that still has that stuff in it. Well, the FV stuff pretty much depends on virtual memory with demand paging and page protections anyway, so using it to do code invalidates doesn't require any more anyway - but I don't think it's all that useful anyway. > I wonder if the frequent %esp changes will give a performance problem for > stack writes. Let's see: if code is written into the stack and then > executed, the first time, we make a correct translation, and we mark that > stack page as dirty. The next write to that page gets the overhead of > discarding translations from that page. So it looks like, apart from the > cost of checking every write (subject to above filtering criteria), the cost > of supporting s-m-c is proportional to the number of translation discards > to be done, and the stack doesn't cause special problems. Stack writes seem to already be a problem for maintaining A and V bits in memcheck and addrcheck anyway, so I think we may end up special casing either stack writes or at least stack movement. But we'll see. > If it should ever come to pass that the vcpu stuff gets completely redesigned, > we could translate multiple bbs at once and find where the loops are. It may > then be possible to identify writes to memory locations in which we can see > that a subsequent write happens to the same location, before we lose track > of the control flow. In that case we know that the first write cannot be > generating code (since it's overwritten later, and we know all the places > where the program will execute in between the two writes) and so the s-m-c > check for the first write is redundant. So, the use of a cleverer > translation/analysis engine, originally intended to do better liveness > analysis, may also help here. Well, my first instinct is that you have to be careful about racing with other CPUs in this case - but of course there aren't any other CPUs, and we control thread scheduling. So that's OK. There's still some risk if we're sharing memory containing code with another process, and that other process changes the code, but I think that's really pathological... J |
|
From: Julian S. <js...@ac...> - 2003-11-20 23:18:57
|
> Ideally, we want a cheap way of detecting s-m-c that can be on all the > time (then we could get rid of the INVALIDATE_TRANSLATIONS macro). I have > an extremely vague idea about tracking things at the page level, and > possibly throwing out all translations that come from code within a page > in certain circumstances. Or something. Hmm. Well, there are some options, but none are good. One is (or might be, depending on Jeremy's views) to mess with page level permissions, so as to remove write permission for any page from which we've taken a translation. Then V takes a page fault whenever writes to that page happen; we catch the fault, note the page as dirty and throw away translations from it as soon as possible. So we freeload on the host's memory protection hardware and have zero run-time overhead. Another is the pure-software approach in very old valgrinds. I think what I had was an array of char indexed by addr>>12 or some such (that would be 2^20 bytes on a 32-bit machine); and there was some kind of check or something at each write. Not cheap, but you could drastically reduce the cost by only testing some writes -- for example, writes from the FPU are most unlikely to generate code, and writes happening as part of a read-op-write operation x86 insn are also unlikely to. Also I think I excluded writes of sizes > 1 since it doesn't make much sense to write x86 code on a word-by-word basis, since it's really a byte stream. Personally I prefer the portability/system independence of the pure-sw approach. IIRC the optimised version didn't give much overhead, but I can't really remember any more, and I don't think I have a copy of the code base that still has that stuff in it. I wonder if the frequent %esp changes will give a performance problem for stack writes. Let's see: if code is written into the stack and then executed, the first time, we make a correct translation, and we mark that stack page as dirty. The next write to that page gets the overhead of discarding translations from that page. So it looks like, apart from the cost of checking every write (subject to above filtering criteria), the cost of supporting s-m-c is proportional to the number of translation discards to be done, and the stack doesn't cause special problems. I think in the long term we'd need to be able to support s-m-c, preferably in a self-contained way. On uncooperative platforms like x86 we could use the pure-software approach. Many risc machines have a flush insn or some such which you have to do before running code you just made; that makes our life really easy, since we don't then have to check any writes. If it should ever come to pass that the vcpu stuff gets completely redesigned, we could translate multiple bbs at once and find where the loops are. It may then be possible to identify writes to memory locations in which we can see that a subsequent write happens to the same location, before we lose track of the control flow. In that case we know that the first write cannot be generating code (since it's overwritten later, and we know all the places where the program will execute in between the two writes) and so the s-m-c check for the first write is redundant. So, the use of a cleverer translation/analysis engine, originally intended to do better liveness analysis, may also help here. J |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 22:08:14
|
On Thu, 20 Nov 2003, Julian Seward wrote: > > Note that VG would be quite slow if it had to check if a write instruction > > is about to change already instrumented code (Wasn't this the > > case in the first days of VG?). > > Urk, uncooperative self-modifying code. That's horrible. I guess we _could_ > reinstate the old-days check-every-write thing that Josef mentions, by default > off but controlled by a command line flag. That way, normal runs are not > slowed down but you can ask for s-m-c support if you really want. Can you remember what kind of slowdown this caused? Checking every write sounds expensive. > Or perhaps we can merge this with Jeremy's need to have precise exceptions > to support full virtualisation, in a single flag --paranoid-vcpu=yes|no [no] ? The nasty thing is that most users won't even realise they're using run-time generated code with nested functions (hell, I didn't) so they won't know to turn on whatever option is required to handle it properly. And a lot of the time it will work, but occasionally things will go subtly wrong when two nested functions put code at the same address. Ideally, we want a cheap way of detecting s-m-c that can be on all the time (then we could get rid of the INVALIDATE_TRANSLATIONS macro). I have an extremely vague idea about tracking things at the page level, and possibly throwing out all translations that come from code within a page in certain circumstances. Or something. Hmm. Or maybe we can convince the GCC folks to remove support for nested functions :) N |
|
From: Julian S. <js...@ac...> - 2003-11-20 21:17:49
|
> Or perhaps we can merge this with Jeremy's need to have precise exceptions > to support full virtualisation, in a single flag --paranoid-vcpu=yes|no s/full virtualisation/self-hosting/g J |
|
From: Dirk M. <mu...@kd...> - 2003-11-20 20:46:24
|
CVS commit by mueller:
add prefetch(w) support - the 3dnow! version of it. doesn't hurt
supporting and its very easy.
MERGE TO STABLE
M +17 -6 vg_to_ucode.c 1.110
--- valgrind/coregrind/vg_to_ucode.c #1.109:1.110
@@ -6364,5 +6364,7 @@ static Addr disInstr ( UCodeBlock* cb, A
/* =-=-=-=-=-=-=-=-=- MMXery =-=-=-=-=-=-=-=-=-=-= */
+ case 0x0D: /* PREFETCH / PREFETCHW - 3Dnow!ery*/
case 0x18: /* PREFETCHT0/PREFETCHT1/PREFETCHT2/PREFETCHNTA */
+
vg_assert(sz == 4);
modrm = getUChar(eip);
@@ -6376,4 +6378,12 @@ static Addr disInstr ( UCodeBlock* cb, A
if (dis) {
UChar* hintstr;
+ if(opc == 0x0D) {
+ switch (gregOfRM(modrm)) {
+ case 0: hintstr = ""; break;
+ case 1: hintstr = "w"; break;
+ default: goto decode_failure;
+ }
+ }
+ else {
switch (gregOfRM(modrm)) {
case 0: hintstr = "nta"; break;
@@ -6382,4 +6392,5 @@ static Addr disInstr ( UCodeBlock* cb, A
case 3: hintstr = "t2"; break;
default: goto decode_failure;
+ }
}
VG_(printf)("prefetch%s ...\n", hintstr);
|
|
From: Julian S. <js...@ac...> - 2003-11-20 20:43:13
|
> Note that VG would be quite slow if it had to check if a write instruction > is about to change already instrumented code (Wasn't this the > case in the first days of VG?). Urk, uncooperative self-modifying code. That's horrible. I guess we _could_ reinstate the old-days check-every-write thing that Josef mentions, by default off but controlled by a command line flag. That way, normal runs are not slowed down but you can ask for s-m-c support if you really want. Or perhaps we can merge this with Jeremy's need to have precise exceptions to support full virtualisation, in a single flag --paranoid-vcpu=yes|no [no] ? J |
|
From: Jeremy F. <je...@go...> - 2003-11-20 17:33:48
|
On Thu, 2003-11-20 at 01:40, Nicholas Nethercote wrote: > We've mentioned before the idea of dropping Valgrind's libpthread.so, and > just doing some low-level clone() interception... would that get around > any/all this NPTL/TLS nastiness? > > That option does have some other downsides, though, particularly it makes > it harder to tell tools when interesting pthread events (eg. mutex_lock) > occur. Yes it would solve the TLS problem, but you'd lose all the other benefits of having our own libpthread. I don't think its a good trade-off. J |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 16:31:12
|
On Tue, 18 Nov 2003, Josef Weidendorfer wrote: > to let KCachegrind act as code coverage tool, I need a cachegrind.out file > covering all instructions with source line debug info of an ELF object (say > event type "DIr" for "distinct instruction fetches"). Together with real > cachegrind data (i.e. type "Ir"), this can be combined to show the percentage > of executed code to all code > by specifying a derived cost type "(Ir>0 @Instr) / DIr". > > For this, I use profile data granularity at instruction level (this is an > extension of the original cachegrind format). Thus, "Ir>0 @ Instr" is a > threshold operator acting at instruction level, i.e. this cost metric is 1 > (=true) for every instruction executed at least once. The "/" (ratio > operator) is always applied last, i.e. for a file/object/function/line you > get this way the ratio of all distinct instructions executed at least once to > all distinct instructions of that file/... . This should be the correct > notion for code coverage, shouldn't it? > BTW, to get a coverage metric on line granularity, I would use > "(Ir>0 @ Line) / (DIr>0 @ Line)". > > I just wrote a skin to get data covering the full code of an ELF object, see > attached file. It is working quite fine with VG 2.0.0, but it's a little ugly > as e.g. VG_(disBB) isn't exported to skins (and the structure UCodeBlock) ;-( > Doing this with objdump and a small script is unfortunately not possible, as > objdump can't cope with DWARF-2 debug line info (?). > The file can be loaded in KCachegrind 0.4.x, but derived metrics with above > operators is currently not possible. > > Can you comment on my approach? I would if I understood it! Am I right in thinking that you want KCachegrind to give a code coverage figure, ie. percentage of code exercised? Apart from that I'm confused: - this "(Ir>0 @Instr) / DIr" stuff is confusing me, I don't understand your notation - what is a "distinct instruction fetch", how does it differ from an "instruction fetch"? - er, just generally not understanding Maybe you could try re-explaining using shorter words and sentences? I'm feeling dim today :) N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 16:21:29
|
CVS commit by nethercote: Updated all "report bugs to..." messages to point to valgrind.kde.org; also updated the docs to refer to valgrind.kde.org instead of the old website. M +1 -1 addrcheck/ac_main.c 1.55 M +3 -3 auxprogs/valgrind-listener.c 1.11 M +1 -1 cachegrind/cg_main.c 1.57 M +1 -1 cachegrind/docs/cg_techdocs.html 1.4 M +1 -1 corecheck/cc_main.c 1.17 M +0 -7 coregrind/vg_include.h 1.156 M +1 -3 coregrind/vg_intercept.c 1.25 [POSSIBLY UNSAFE: printf] M +4 -2 coregrind/vg_libpthread.c 1.140 [POSSIBLY UNSAFE: printf] M +3 -3 coregrind/vg_main.c 1.125 M +2 -2 coregrind/vg_mylibc.c 1.58 M +1 -1 coregrind/docs/coregrind_core.html 1.18 M +1 -1 helgrind/hg_main.c 1.67 M +7 -0 include/vg_skin.h 1.101 M +1 -1 lackey/lk_main.c 1.21 M +1 -1 memcheck/mc_main.c 1.42 M +1 -1 memcheck/docs/mc_techdocs.html 1.7 M +1 -1 none/nl_main.c 1.16 --- valgrind/addrcheck/ac_main.c #1.54:1.55 @@ -1279,5 +1279,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward."); - VG_(details_bug_reports_to) ("js...@ac..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(details_avg_translation_sizeB) ( 135 ); --- valgrind/auxprogs/valgrind-listener.c #1.10:1.11 @@ -46,5 +46,5 @@ -/* For VG_CLO_DEFAULT_LOGPORT and VG_EMAIL_ADDR. */ +/* For VG_CLO_DEFAULT_LOGPORT and VG_BUGS_TO. */ #include "vg_include.h" @@ -65,5 +65,5 @@ static void panic ( Char* str ) "`impossible' happened:\n %s\n", str); fprintf(stderr, - "Please report this bug to: %s\n\n", VG_EMAIL_ADDR); + "Please report this bug at: %s\n\n", VG_BUGS_TO); exit(1); } @@ -76,5 +76,5 @@ static void my_assert_fail ( const Char* file, line, fn, expr ); fprintf(stderr, - "Please report this bug to: %s\n\n", VG_EMAIL_ADDR); + "Please report this bug at: %s\n\n", VG_BUGS_TO); exit(1); } --- valgrind/cachegrind/cg_main.c #1.56:1.57 @@ -2025,5 +2025,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote."); - VG_(details_bug_reports_to) ("nj...@ca..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(details_avg_translation_sizeB) ( 155 ); --- valgrind/cachegrind/docs/cg_techdocs.html #1.3:1.4 @@ -34,5 +34,5 @@ <a href="mailto:nj...@ca...">nj...@ca...</a><br> <a -href="http://developer.kde.org/~sewardj">http://developer.kde.org/~sewardj</a><br> +href="http://valgrind.kde.org">http://valgrind.kde.org</a><br> <p> Copyright © 2001-2003 Nick Nethercote --- valgrind/corecheck/cc_main.c #1.16:1.17 @@ -41,5 +41,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote."); - VG_(details_bug_reports_to) ("nj...@ca..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(needs_core_errors)(); --- valgrind/coregrind/vg_include.h #1.155:1.156 @@ -35,11 +35,4 @@ /* --------------------------------------------------------------------- - Where to send bug reports to. - ------------------------------------------------------------------ */ - -#define VG_EMAIL_ADDR "js...@ac..." - - -/* --------------------------------------------------------------------- Build options and table sizes. You should be able to change these options or sizes, recompile, and still have a working system. --- valgrind/coregrind/vg_intercept.c #1.24:1.25 @@ -135,7 +135,5 @@ void my_assert_fail ( const Char* expr, "valgrind", file, line, fn, expr ); cat_n_send ( "", buf ); - sprintf(buf, "Please report this bug to me at: %s\n\n", - VG_EMAIL_ADDR); - cat_n_send ( "", buf ); + sprintf(buf, "Please report this bug at: %s\n\n", VG_BUGS_TO); my_exit(1); } --- valgrind/coregrind/vg_libpthread.c #1.139:1.140 @@ -171,4 +171,6 @@ void barf ( const char* str ) strcpy(buf, "\nvalgrind's libpthread.so: "); strcat(buf, str); + strcat(buf, "\nPlease report this bug at: "); + strcat(buf, VG_BUGS_TO); strcat(buf, "\n\n"); VALGRIND_NON_SIMD_CALL2(VG_(message), Vg_UserMsg, buf); @@ -212,5 +214,5 @@ void vgPlain_unimp ( char* fn ) { cat_n_send ( "valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: ", fn, "" ); - barf("Please report this bug to me at: js...@ac..."); + barf("unimplemented function"); } @@ -227,5 +229,5 @@ void my_assert_fail ( const Char* expr, "valgrind", file, line, fn, expr ); cat_n_send ( "", buf, "" ); - sprintf(buf, "Please report this bug to me at: %s\n\n", VG_EMAIL_ADDR); + sprintf(buf, "Please report this bug at: %s\n\n", VG_BUGS_TO); my_exit(1); } --- valgrind/coregrind/vg_main.c #1.124:1.125 @@ -729,5 +729,5 @@ static void usage ( void ) else VG_(printf)(" (none)\n"); - VG_(printf)(usage3, VG_EMAIL_ADDR); + VG_(printf)(usage3, VG_BUGS_TO); VG_(shutdown_logging)(); @@ -1991,7 +1991,7 @@ void VG_(unimplemented) ( Char* msg ) "or because no reasonable program would behave this way,"); VG_(message)(Vg_UserMsg, - "or because nobody has yet needed it. In any case, let me know"); + "or because nobody has yet needed it. In any case, let us know at"); VG_(message)(Vg_UserMsg, - "(js...@ac...) and/or try to work around the problem, if you can."); + "%s and/or try to work around the problem, if you can.", VG_BUGS_TO); VG_(message)(Vg_UserMsg, ""); --- valgrind/coregrind/vg_mylibc.c #1.57:1.58 @@ -1107,5 +1107,5 @@ void VG_(skin_assert_fail) ( const Char* void VG_(core_assert_fail) ( const Char* expr, const Char* file, Int line, const Char* fn ) { - assert_fail(expr, "valgrind", VG_EMAIL_ADDR, file, line, fn); + assert_fail(expr, "valgrind", VG_BUGS_TO, file, line, fn); } @@ -1120,5 +1120,5 @@ static void panic ( Char* name, Char* re void VG_(core_panic) ( Char* str ) { - panic("valgrind", VG_EMAIL_ADDR, str); + panic("valgrind", VG_BUGS_TO, str); } --- valgrind/coregrind/docs/coregrind_core.html #1.17:1.18 @@ -1161,5 +1161,5 @@ <a name="problems"></a> <h3>2.11 If you have problems</h3> -Mail me (<a href="mailto:js...@ac...">js...@ac...</a>). +Contact us at <a href="http://valgrind.kde.org">valgrind.kde.org</a>. <p>See <a href="#limits">this section</a> for the known limitations of --- valgrind/helgrind/hg_main.c #1.66:1.67 @@ -3239,5 +3239,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote."); - VG_(details_bug_reports_to) ("je...@go..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(details_avg_translation_sizeB) ( 115 ); --- valgrind/include/vg_skin.h #1.100:1.101 @@ -39,4 +39,11 @@ +/* --------------------------------------------------------------------- + Where to send bug reports to. + ------------------------------------------------------------------ */ + +#define VG_BUGS_TO "valgrind.kde.org" + + /*====================================================================*/ /*=== Build options and table sizes. ===*/ --- valgrind/lackey/lk_main.c #1.20:1.21 @@ -82,5 +82,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote."); - VG_(details_bug_reports_to) ("nj...@ca..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(details_avg_translation_sizeB) ( 175 ); --- valgrind/memcheck/mc_main.c #1.41:1.42 @@ -1660,5 +1660,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward."); - VG_(details_bug_reports_to) ("js...@ac..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); VG_(details_avg_translation_sizeB) ( 228 ); --- valgrind/memcheck/docs/mc_techdocs.html #1.6:1.7 @@ -34,5 +34,5 @@ <p> <a href="mailto:js...@ac...">js...@ac...</a><br> -<a href="http://developer.kde.org/~sewardj">http://developer.kde.org/~sewardj</a><br> +<a href="http://valgrind.kde.org">http://valgrind.kde.org</a><br> Copyright © 2000-2003 Julian Seward <p> --- valgrind/none/nl_main.c #1.15:1.16 @@ -40,5 +40,5 @@ void SK_(pre_clo_init)(void) VG_(details_copyright_author)( "Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote."); - VG_(details_bug_reports_to) ("nj...@ca..."); + VG_(details_bug_reports_to) (VG_BUGS_TO); /* No needs, no core events to track */ |
|
From: Dirk M. <dm...@gm...> - 2003-11-20 12:10:46
|
On Thursday 20 November 2003 13:02, Nicholas Nethercote wrote: > So if I watch Julian I'll see them all? That sounds good. You'll see changes to every bug assigned to Julian, reported by Julian or commented by Julian. Unless you configure your email settings under: http://bugs.kde.org/userprefs.cgi?tab=email different from the default. Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 12:03:20
|
On Thu, 20 Nov 2003, Dirk Mueller wrote: > well, by default bugs are assigned to the "owner" of the selected component. > you can reassign them to other components or to yourself by choosing the > reassign to xxxx or reassign to owner of selected component fields. So if I watch Julian I'll see them all? That sounds good. Better than sending to vg-dev, because (a) not everyone might want to hear about every bug, but more importantly (b) it's probably best to avoid partly discussing bugs within Bugzilla and partly on the mailing list; better to keep it all within Bugzilla. N |
|
From: Dirk M. <dm...@gm...> - 2003-11-20 11:28:27
|
On Thursday 20 November 2003 11:56, Nicholas Nethercote wrote: > But I'm not sure about the human processes involved, ie. how people should > actually use it. All bugs are going to Julian, it seems... does anyone > else get told about them? well, kde...@kd..., but you don't want to read that. > Dirk, you seem to know about them, is that > because you checked the list manually, or have you setup auto-notification > somehow? you can watch another user in your preferences: http://bugs.kde.org/userprefs.cgi?tab=email > Valgrind's still small enough that I'd like to know about every > bug, I think. How do bugs get assigned... we need some kind of > guidelines or something? well, by default bugs are assigned to the "owner" of the selected component. you can reassign them to other components or to yourself by choosing the reassign to xxxx or reassign to owner of selected component fields. we can change the intial owner to be the mailinglist here, but then somebody would need to fix the setup to allow any poster (since the mails look like being posted by the people adding/modifying a bug). |
|
From: Tom H. <th...@cy...> - 2003-11-20 11:09:15
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> But I'm not sure about the human processes involved, ie. how people should
> actually use it. All bugs are going to Julian, it seems... does anyone
> else get told about them? Dirk, you seem to know about them, is that
> because you checked the list manually, or have you setup auto-notification
> somehow? Valgrind's still small enough that I'd like to know about every
> bug, I think. How do bugs get assigned... we need some kind of
> guidelines or something?
Might it be better for new bugs to come to the developer list rather
than Julian given how busy he tends to be?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 10:57:10
|
On Thu, 20 Nov 2003, Dirk Mueller wrote: > > Are there instructions somewhere? How's it all work? > > There is the web interface, which has mostly a self-containing documentation > hidden behind all the knobs on the bug forms, see > > http://bugs.kde.org/queryhelp.cgi > > > There is also a mail interface which is mostly undocumented and a xml query > interface (used by offline tools like kbugbuster). > > Anyway, if there is a more specific question, just ask. Ok, playing around, I think I understand the mechanics ok. But I'm not sure about the human processes involved, ie. how people should actually use it. All bugs are going to Julian, it seems... does anyone else get told about them? Dirk, you seem to know about them, is that because you checked the list manually, or have you setup auto-notification somehow? Valgrind's still small enough that I'd like to know about every bug, I think. How do bugs get assigned... we need some kind of guidelines or something? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 10:39:14
|
CVS commit by nethercote:
Printing usage message to stdout instead of stderr, which seems to be the
standard thing to do.
M +8 -5 vg_main.c 1.124
--- valgrind/coregrind/vg_main.c #1.123:1.124
@@ -536,7 +536,9 @@ Bool VG_(clo_demangle) = True;
Bool VG_(clo_trace_children) = False;
-/* See big comment in vg_include.h for meaning of these three. */
+/* See big comment in vg_include.h for meaning of these three.
+ fd is initially stdout, for --help, but gets moved to stderr by default
+ immediately afterwards. */
VgLogTo VG_(clo_log_to) = VgLogTo_Fd;
-Int VG_(clo_logfile_fd) = 2;
+Int VG_(clo_logfile_fd) = 1;
Char* VG_(clo_logfile_name) = NULL;
@@ -770,5 +772,6 @@ static void process_cmd_line_options ( v
# define ISSPACE(cc) ((cc) == ' ' || (cc) == '\t' || (cc) == '\n')
- eventually_logfile_fd = VG_(clo_logfile_fd);
+ /* log to stderr by default, but usage message goes to stdout */
+ eventually_logfile_fd = 2;
/* Once logging is started, we can safely send messages pertaining
@@ -1177,8 +1180,8 @@ static void process_cmd_line_options ( v
nature of it is. Oh the wonder of Unix streams. */
- /* So far we should be still attached to stderr, so we can show on
+ /* So far we should be still attached to stdout, so we can show on
the terminal any problems to do with processing command line
opts. */
- vg_assert(VG_(clo_logfile_fd) == 2 /* stderr */);
+ vg_assert(VG_(clo_logfile_fd) == 1 /* stdout */);
vg_assert(VG_(logging_to_filedes) == True);
|