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: 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);
|
|
From: Tom H. <th...@cy...> - 2003-11-20 10:20:00
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote:
>
>> OK, I've had even more of a look into what's happening here. The quick
>> answer is that is can probably be done without too much nastiness,
>> though our libpthread will need to know some of glibc's secret
>> knowledge.
>
> 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?
It should do, yes. We would just need to track the calls being made
to set_pthread_area and clone with the TLS option.
I'm working on trying to get things going with those functions Jeremy
found anyway...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:44:53
|
CVS commit by nethercote: Link to the Valgrind RV'03 paper. M +3 -2 docs.html 1.4 --- devel-home/valgrind/docs.html #1.3:1.4 @@ -14,6 +14,7 @@ The overly-curious may want to read <a href="http://developer.kde.org/~sewardj/docs-2.0.0/mc_techdocs.html"> -detailed tech docs</a> about how -Valgrind is implemented. +detailed tech docs</a> about how Valgrind is implemented. Alternatively, you +may want to read this broader, more formal +<a href="http://www.cl.cam.ac.uk/~njn25/pubs/valgrind2003.ps.gz">overview</a>. <?php |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:40:55
|
On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote: > OK, I've had even more of a look into what's happening here. The quick > answer is that is can probably be done without too much nastiness, > though our libpthread will need to know some of glibc's secret > knowledge. 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. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:35:33
|
CVS commit by nethercote:
We have Hungarian users
M +5 -4 overview.html 1.3
--- devel-home/valgrind/overview.html #1.2:1.3
@@ -70,8 +70,9 @@
<li><b>Valgrind is widely used.</b> Valgrind has been used by thousands
of programmers across the world. We have received feedback from
- users in over 20 countries, including: Belgium, Czech Republic,
- Denmark, Finland, France, Germany, Greece, Italy, The Netherlands,
- Norway, Poland, Russia, Sweden, Switzerland, UK, Argentina, Brazil,
- Canada, USA, Australia, Japan, New Zealand, South Africa and Israel.
+ users in over 25 countries, including: Belgium, Czech Republic,
+ 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.
<p>
<li><b>Valgrind works with programs written in any language.</b>
|