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
(9) |
|
2
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: Dirk M. <dm...@gm...> - 2007-12-11 23:52:49
|
On Monday 10 December 2007, Dan Kegel wrote:
> > it is unfortunately a known problem that -Wstrict-overflow
> > does not warn about everything that it exploits for optimisation.
> Got a gcc bugzilla number for that?
Not really. I have plenty of testcases though. example:
void table_init(int* value)
{
int val = 0x03020100;
for (int i = 0; i < 256/4; i++) {
value[i] = val;
val += 0x04040404;
}
}
Greetings,
Dirk
|
|
From: Nicholas N. <nj...@cs...> - 2007-12-11 22:24:05
|
On Tue, 11 Dec 2007, Julian Seward wrote: > We are pleased to announce a new release of Valgrind, version 3.3.0, > available from http://www.valgrind.org. > [...] > Our thanks to all those who contribute to Valgrind's development. > This release represents a great deal of time, energy and effort on the > part of many people. But much of it is due to Julian :) Many thanks, especially for doing the huge amount of work required to create the release. Nick ps: the release tarball works well on my FC4 box. |
|
From: Julian S. <js...@ac...> - 2007-12-11 21:47:23
|
We are pleased to announce a new release of Valgrind, version 3.3.0, available from http://www.valgrind.org. Valgrind is an open-source suite of simulation based debugging and profiling tools. With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, which avoids hours of frustrating bug-hunting, and makes your code more stable. You can also perform detailed time and space profiling to help speed up and slim down your programs. 3.3.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. See the release notes below for details. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.3.0 (7 December 2007) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.3.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. Support for recent distros (using gcc 4.3, glibc 2.6 and 2.7) has been added. The main excitement in 3.3.0 is new and improved tools. Helgrind works again, Massif has been completely overhauled and much improved, Cachegrind now does branch-misprediction profiling, and a new category of experimental tools has been created, containing two new tools: Omega and DRD. There are many other smaller improvements. In detail: - Helgrind has been completely overhauled and works for the first time since Valgrind 2.2.0. Supported functionality is: detection of misuses of the POSIX PThreads API, detection of potential deadlocks resulting from cyclic lock dependencies, and detection of data races. Compared to the 2.2.0 Helgrind, the race detection algorithm has some significant improvements aimed at reducing the false error rate. Handling of various kinds of corner cases has been improved. Efforts have been made to make the error messages easier to understand. Extensive documentation is provided. - Massif has been completely overhauled. Instead of measuring space-time usage -- which wasn't always useful and many people found confusing -- it now measures space usage at various points in the execution, including the point of peak memory allocation. Its output format has also changed: instead of producing PostScript graphs and HTML text, it produces a single text output (via the new 'ms_print' script) that contains both a graph and the old textual information, but in a more compact and readable form. Finally, the new version should be more reliable than the old one, as it has been tested more thoroughly. - Cachegrind has been extended to do branch-misprediction profiling. Both conditional and indirect branches are profiled. The default behaviour of Cachegrind is unchanged. To use the new functionality, give the option --branch-sim=yes. - A new category of "experimental tools" has been created. Such tools may not work as well as the standard tools, but are included because some people will find them useful, and because exposure to a wider user group provides tool authors with more end-user feedback. These tools have a "exp-" prefix attached to their names to indicate their experimental nature. Currently there are two experimental tools: * exp-Omega: an instantaneous leak detector. See exp-omega/docs/omega_introduction.txt. * exp-DRD: a data race detector based on the happens-before relation. See exp-drd/docs/README.txt. - Scalability improvements for very large programs, particularly those which have a million or more malloc'd blocks in use at once. These improvements mostly affect Memcheck. Memcheck is also up to 10% faster for all programs, with x86-linux seeing the largest improvement. - Works well on the latest Linux distros. Has been tested on Fedora Core 8 (x86, amd64, ppc32, ppc64) and openSUSE 10.3. glibc 2.6 and 2.7 are supported. gcc-4.3 (in its current pre-release state) is supported. At the same time, 3.3.0 retains support for older distros. - The documentation has been modestly reorganised with the aim of making it easier to find information on common-usage scenarios. Some advanced material has been moved into a new chapter in the main manual, so as to unclutter the main flow, and other tidying up has been done. - There is experimental support for AIX 5.3, both 32-bit and 64-bit processes. You need to be running a 64-bit kernel to use Valgrind on a 64-bit executable. - There have been some changes to command line options, which may affect you: * --log-file-exactly and --log-file-qualifier options have been removed. To make up for this --log-file option has been made more powerful. It now accepts a %p format specifier, which is replaced with the process ID, and a %q{FOO} format specifier, which is replaced with the contents of the environment variable FOO. * --child-silent-after-fork=yes|no [no] Causes Valgrind to not show any debugging or logging output for the child process resulting from a fork() call. This can make the output less confusing (although more misleading) when dealing with processes that create children. * --cachegrind-out-file, --callgrind-out-file and --massif-out-file These control the names of the output files produced by Cachegrind, Callgrind and Massif. They accept the same %p and %q format specifiers that --log-file accepts. --callgrind-out-file replaces Callgrind's old --base option. * Cachegrind's 'cg_annotate' script no longer uses the --<pid> option to specify the output file. Instead, the first non-option argument is taken to be the name of the output file, and any subsequent non-option arguments are taken to be the names of source files to be annotated. * Cachegrind and Callgrind now use directory names where possible in their output files. This means that the -I option to 'cg_annotate' and 'callgrind_annotate' should not be needed in most cases. It also means they can correctly handle the case where two source files in different directories have the same name. - Memcheck offers a new suppression kind: "Jump". This is for suppressing jump-to-invalid-address errors. Previously you had to use an "Addr1" suppression, which didn't make much sense. - Memcheck has new flags --malloc-fill=<hexnum> and --free-fill=<hexnum> which free malloc'd / free'd areas with the specified byte. This can help shake out obscure memory corruption problems. The definedness and addressibility of these areas is unchanged -- only the contents are affected. - The behaviour of Memcheck's client requests VALGRIND_GET_VBITS and VALGRIND_SET_VBITS have changed slightly. They no longer issue addressability errors -- if either array is partially unaddressable, they just return 3 (as before). Also, SET_VBITS doesn't report definedness errors if any of the V bits are undefined. - The following Memcheck client requests have been removed: VALGRIND_MAKE_NOACCESS VALGRIND_MAKE_WRITABLE VALGRIND_MAKE_READABLE VALGRIND_CHECK_WRITABLE VALGRIND_CHECK_READABLE VALGRIND_CHECK_DEFINED They were deprecated in 3.2.0, when equivalent but better-named client requests were added. See the 3.2.0 release notes for more details. - The behaviour of the tool Lackey has changed slightly. First, the output from --trace-mem has been made more compact, to reduce the size of the traces. Second, a new option --trace-superblocks has been added, which shows the addresses of superblocks (code blocks) as they are executed. - The following bugs have been fixed. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than mailing the developers (or mailing lists) directly. n-i-bz x86_linux_REDIR_FOR_index() broken n-i-bz guest-amd64/toIR.c:2512 (dis_op2_E_G): Assertion `0' failed. n-i-bz Support x86 INT insn (INT (0xCD) 0x40 - 0x43) n-i-bz Add sys_utimensat system call for Linux x86 platform 79844 Helgrind complains about race condition which does not exist 82871 Massif output function names too short 89061 Massif: ms_main.c:485 (get_XCon): Assertion `xpt->max_chi...' 92615 Write output from Massif at crash 95483 massif feature request: include peak allocation in report 112163 MASSIF crashed with signal 7 (SIGBUS) after running 2 days 119404 problems running setuid executables (partial fix) 121629 add instruction-counting mode for timing 127371 java vm giving unhandled instruction bytes: 0x26 0x2E 0x64 0x65 129937 ==150380 129576 Massif loses track of memory, incorrect graphs 132132 massif --format=html output does not do html entity escaping 132950 Heap alloc/usage summary 133962 unhandled instruction bytes: 0xF2 0x4C 0xF 0x10 134990 use -fno-stack-protector if possible 136382 ==134990 137396 I would really like helgrind to work again... 137714 x86/amd64->IR: 0x66 0xF 0xF7 0xC6 (maskmovq, maskmovdq) 141631 Massif: percentages don't add up correctly 142706 massif numbers don't seem to add up 143062 massif crashes on app exit with signal 8 SIGFPE 144453 (get_XCon): Assertion 'xpt->max_children != 0' failed. 145559 valgrind aborts when malloc_stats is called 145609 valgrind aborts all runs with 'repeated section!' 145622 --db-attach broken again on x86-64 145837 ==149519 145887 PPC32: getitimer() system call is not supported 146252 ==150678 146456 (update_XCon): Assertion 'xpt->curr_space >= -space_delta'... 146701 ==134990 146781 Adding support for private futexes 147325 valgrind internal error on syscall (SYS_io_destroy, 0) 147498 amd64->IR: 0xF0 0xF 0xB0 0xF (lock cmpxchg %cl,(%rdi)) 147545 Memcheck: mc_main.c:817 (get_sec_vbits8): Assertion 'n' failed. 147628 SALC opcode 0xd6 unimplemented 147825 crash on amd64-linux with gcc 4.2 and glibc 2.6 (CFI) 148174 Incorrect type of freed_list_volume causes assertion [...] 148447 x86_64 : new NOP codes: 66 66 66 66 2e 0f 1f 149182 PPC Trap instructions not implemented in valgrind 149504 Assertion hit on alloc_xpt->curr_space >= -space_delta 149519 ppc32: V aborts with SIGSEGV on execution of a signal handler 149892 ==137714 150044 SEGV during stack deregister 150380 dwarf/gcc interoperation (dwarf3 read problems) 150408 ==148447 150678 guest-amd64/toIR.c:3741 (dis_Grp5): Assertion `sz == 4' failed 151209 V unable to execute programs for users with UID > 2^16 151938 help on --db-command= misleading 152022 subw $0x28, %%sp causes assertion failure in memcheck 152357 inb and outb not recognized in 64-bit mode 152501 vex x86->IR: 0x27 0x66 0x89 0x45 (daa) 152818 vex x86->IR: 0xF3 0xAC 0xFC 0x9C (rep lodsb) Developer-visible changes: - The names of some functions and types within the Vex IR have changed. Run 'svn log -r1689 VEX/pub/libvex_ir.h' for full details. Any existing standalone tools will have to be updated to reflect these changes. The new names should be clearer. The file VEX/pub/libvex_ir.h is also much better commented. - A number of new debugging command line options have been added. These are mostly of use for debugging the symbol table and line number readers: --trace-symtab-patt=<patt> limit debuginfo tracing to obj name <patt> --trace-cfi=no|yes show call-frame-info details? [no] --debug-dump=syms mimic /usr/bin/readelf --syms --debug-dump=line mimic /usr/bin/readelf --debug-dump=line --debug-dump=frames mimic /usr/bin/readelf --debug-dump=frames --sym-offsets=yes|no show syms in form 'name+offset' ? [no] - Internally, the code base has been further factorised and abstractified, particularly with respect to support for non-Linux OSs. (3.3.0.RC1: 2 Dec 2007, vex r1803, valgrind r7268). (3.3.0.RC2: 5 Dec 2007, vex r1804, valgrind r7282). (3.3.0.RC3: 9 Dec 2007, vex r1804, valgrind r7288). (3.3.0: 10 Dec 2007, vex r1804, valgrind r7290). |
|
From: Joseph M L. <val...@jo...> - 2007-12-11 14:20:13
|
Hello, has there been any discussion on implementing something like what is suggested in this article for valgrind? http://www.ddj.com/cpp/204800654 Seems like it wouldn't be too difficult to add something like the following: vallgrind_control --start-leak-check --pid=xxxx vallgrind_control --stop-leak-check --pid=xxxx vallgrind_control --dump-leak-check --pid=xxxx Joe |
|
From: Tom H. <th...@cy...> - 2007-12-11 03:59:42
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-11 03:15:03 GMT 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 == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-11 03:36:28
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-11 03:05:12 GMT 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 == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-11 03:27:46
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-11 03:10:05 GMT 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 == 355 tests, 9 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (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 == 355 tests, 8 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Dec 11 03:19:32 2007 --- new.short Tue Dec 11 03:27:47 2007 *************** *** 8,10 **** ! == 355 tests, 8 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 355 tests, 9 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 17,18 **** --- 17,19 ---- none/tests/pth_detached (stdout) + helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) |
|
From: <sv...@va...> - 2007-12-11 03:20:39
|
Author: sewardj
Date: 2007-12-11 03:10:44 +0000 (Tue, 11 Dec 2007)
New Revision: 342
Log:
Add new chapter.
Added:
trunk/docs/manual/manual-core-adv.html
Added: trunk/docs/manual/manual-core-adv.html
===================================================================
--- trunk/docs/manual/manual-core-adv.html (rev 0)
+++ trunk/docs/manual/manual-core-adv.html 2007-12-11 03:10:44 UTC (rev 342)
@@ -0,0 +1,569 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>3.Using and understanding the Valgrind core: Advanced Topics</title>
+<link rel="stylesheet" href="vg_basic.css" type="text/css">
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="index.html" title="Valgrind Documentation">
+<link rel="up" href="manual.html" title="Valgrind User Manual">
+<link rel="prev" href="manual-core.html" title="2.Using and understanding the Valgrind core">
+<link rel="next" href="mc-manual.html" title="4.Memcheck: a heavyweight memory checker">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr>
+<td width="22px" align="center" valign="middle"><a accesskey="p" href="manual-core.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td>
+<td width="25px" align="center" valign="middle"><a accesskey="u" href="manual.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td>
+<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td>
+<th align="center" valign="middle">Valgrind User Manual</th>
+<td width="22px" align="center" valign="middle"><a accesskey="n" href="mc-manual.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td>
+</tr></table></div>
+<div class="chapter" lang="en">
+<div class="titlepage"><div><div><h2 class="title">
+<a name="manual-core-adv"></a>3.Using and understanding the Valgrind core: Advanced Topics</h2></div></div></div>
+<div class="toc">
+<p><b>Table of Contents</b></p>
+<dl>
+<dt><span class="sect1"><a href="manual-core-adv.html#manual-core-adv.clientreq">3.1. The Client Request mechanism</a></span></dt>
+<dt><span class="sect1"><a href="manual-core-adv.html#manual-core-adv.wrapping">3.2. Function wrapping</a></span></dt>
+<dd><dl>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.example">3.2.1. A Simple Example</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.specs">3.2.2. Wrapping Specifications</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.semantics">3.2.3. Wrapping Semantics</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.debugging">3.2.4. Debugging</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.limitations-cf">3.2.5. Limitations - control flow</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.limitations-sigs">3.2.6. Limitations - original function signatures</a></span></dt>
+<dt><span class="sect2"><a href="manual-core-adv.html#manual-core-adv.wrapping.examples">3.2.7. Examples</a></span></dt>
+</dl></dd>
+</dl>
+</div>
+<p>This chapter describes advanced aspects of the Valgrind core
+services, which are mostly of interest to power users who wish to
+customise and modify Valgrind's default behaviours in certain useful
+ways. The subjects covered are:</p>
+<div class="itemizedlist"><ul type="disc">
+<li><p>The "Client Request" mechanism</p></li>
+<li><p>Function Wrapping</p></li>
+</ul></div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="manual-core-adv.clientreq"></a>3.1.The Client Request mechanism</h2></div></div></div>
+<p>Valgrind has a trapdoor mechanism via which the client
+program can pass all manner of requests and queries to Valgrind
+and the current tool. Internally, this is used extensively to
+make malloc, free, etc, work, although you don't see that.</p>
+<p>For your convenience, a subset of these so-called client
+requests is provided to allow you to tell Valgrind facts about
+the behaviour of your program, and also to make queries.
+In particular, your program can tell Valgrind about changes in
+memory range permissions that Valgrind would not otherwise know
+about, and so allows clients to get Valgrind to do arbitrary
+custom checks.</p>
+<p>Clients need to include a header file to make this work.
+Which header file depends on which client requests you use. Some
+client requests are handled by the core, and are defined in the
+header file <code class="filename">valgrind/valgrind.h</code>. Tool-specific
+header files are named after the tool, e.g.
+<code class="filename">valgrind/memcheck.h</code>. All header files can be found
+in the <code class="literal">include/valgrind</code> directory of wherever Valgrind
+was installed.</p>
+<p>The macros in these header files have the magical property
+that they generate code in-line which Valgrind can spot.
+However, the code does nothing when not run on Valgrind, so you
+are not forced to run your program under Valgrind just because you
+use the macros in this file. Also, you are not required to link your
+program with any extra supporting libraries.</p>
+<p>The code added to your binary has negligible performance impact:
+on x86, amd64, ppc32 and ppc64, the overhead is 6 simple integer instructions
+and is probably undetectable except in tight loops.
+However, if you really wish to compile out the client requests, you can
+compile with <code class="computeroutput">-DNVALGRIND</code> (analogous to
+<code class="computeroutput">-DNDEBUG</code>'s effect on
+<code class="computeroutput">assert()</code>).
+</p>
+<p>You are encouraged to copy the <code class="filename">valgrind/*.h</code> headers
+into your project's include directory, so your program doesn't have a
+compile-time dependency on Valgrind being installed. The Valgrind headers,
+unlike most of the rest of the code, are under a BSD-style license so you may
+include them without worrying about license incompatibility.</p>
+<p>Here is a brief description of the macros available in
+<code class="filename">valgrind.h</code>, which work with more than one
+tool (see the tool-specific documentation for explanations of the
+tool-specific macros).</p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">RUNNING_ON_VALGRIND</code></strong></span>:</span></dt>
+<dd><p>Returns 1 if running on Valgrind, 0 if running on the
+ real CPU. If you are running Valgrind on itself, returns the
+ number of layers of Valgrind emulation you're running on.
+ </p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_DISCARD_TRANSLATIONS</code>:</strong></span></span></dt>
+<dd>
+<p>Discards translations of code in the specified address
+ range. Useful if you are debugging a JIT compiler or some other
+ dynamic code generation system. After this call, attempts to
+ execute code in the invalidated address range will cause
+ Valgrind to make new translations of that code, which is
+ probably the semantics you want. Note that code invalidations
+ are expensive because finding all the relevant translations
+ quickly is very difficult. So try not to call it often.
+ Note that you can be clever about
+ this: you only need to call it when an area which previously
+ contained code is overwritten with new code. You can choose
+ to write code into fresh memory, and just call this
+ occasionally to discard large chunks of old code all at
+ once.</p>
+<p>
+ Alternatively, for transparent self-modifying-code support,
+ use<code class="computeroutput">--smc-check=all</code>, or run
+ on ppc32/Linux or ppc64/Linux.
+ </p>
+</dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_COUNT_ERRORS</code>:</strong></span></span></dt>
+<dd><p>Returns the number of errors found so far by Valgrind. Can be
+ useful in test harness code when combined with the
+ <code class="option">--log-fd=-1</code> option; this runs Valgrind silently,
+ but the client program can detect when errors occur. Only useful
+ for tools that report errors, e.g. it's useful for Memcheck, but for
+ Cachegrind it will always return zero because Cachegrind doesn't
+ report errors.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_MALLOCLIKE_BLOCK</code>:</strong></span></span></dt>
+<dd><p>If your program manages its own memory instead of using
+ the standard <code class="computeroutput">malloc()</code> /
+ <code class="computeroutput">new</code> /
+ <code class="computeroutput">new[]</code>, tools that track
+ information about heap blocks will not do nearly as good a
+ job. For example, Memcheck won't detect nearly as many
+ errors, and the error messages won't be as informative. To
+ improve this situation, use this macro just after your custom
+ allocator allocates some new memory. See the comments in
+ <code class="filename">valgrind.h</code> for information on how to use
+ it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_FREELIKE_BLOCK</code>:</strong></span></span></dt>
+<dd><p>This should be used in conjunction with
+ <code class="computeroutput">VALGRIND_MALLOCLIKE_BLOCK</code>.
+ Again, see <code class="filename">memcheck/memcheck.h</code> for
+ information on how to use it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_CREATE_MEMPOOL</code>:</strong></span></span></dt>
+<dd><p>This is similar to
+ <code class="computeroutput">VALGRIND_MALLOCLIKE_BLOCK</code>,
+ but is tailored towards code that uses memory pools. See the
+ comments in <code class="filename">valgrind.h</code> for information
+ on how to use it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_DESTROY_MEMPOOL</code>:</strong></span></span></dt>
+<dd><p>This should be used in conjunction with
+ <code class="computeroutput">VALGRIND_CREATE_MEMPOOL</code>.
+ Again, see the comments in <code class="filename">valgrind.h</code> for
+ information on how to use it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_MEMPOOL_ALLOC</code>:</strong></span></span></dt>
+<dd><p>This should be used in conjunction with
+ <code class="computeroutput">VALGRIND_CREATE_MEMPOOL</code>.
+ Again, see the comments in <code class="filename">valgrind.h</code> for
+ information on how to use it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_MEMPOOL_FREE</code>:</strong></span></span></dt>
+<dd><p>This should be used in conjunction with
+ <code class="computeroutput">VALGRIND_CREATE_MEMPOOL</code>.
+ Again, see the comments in <code class="filename">valgrind.h</code> for
+ information on how to use it.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_NON_SIMD_CALL[0123]</code>:</strong></span></span></dt>
+<dd>
+<p>Executes a function of 0, 1, 2 or 3 args in the client
+ program on the <span class="emphasis"><em>real</em></span> CPU, not the virtual
+ CPU that Valgrind normally runs code on. These are used in
+ various ways internally to Valgrind. They might be useful to
+ client programs.</p>
+<p><span><strong class="command">Warning:</strong></span> Only use these if you
+ <span class="emphasis"><em>really</em></span> know what you are doing. They aren't
+ entirely reliable, and can cause Valgrind to crash.
+ Generally, your prospects of these working are made higher if the called
+ function does not refer to any global variables, and does not refer to any
+ libc or other functions (printf et al). Any kind of entanglement with libc
+ or dynamic linking is likely to have a bad outcome, for tricky reasons
+ which we've grappled with a lot in the past.
+ </p>
+</dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_PRINTF(format, ...)</code>:</strong></span></span></dt>
+<dd><p>printf a message to the log file when running under
+ Valgrind. Nothing is output if not running under Valgrind.
+ Returns the number of characters output.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_PRINTF_BACKTRACE(format, ...)</code>:</strong></span></span></dt>
+<dd><p>printf a message to the log file along with a stack
+ backtrace when running under Valgrind. Nothing is output if
+ not running under Valgrind. Returns the number of characters
+ output.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_STACK_REGISTER(start, end)</code>:</strong></span></span></dt>
+<dd>
+<p>Registers a new stack. Informs Valgrind that the memory range
+ between start and end is a unique stack. Returns a stack identifier
+ that can be used with other
+ <code class="computeroutput">VALGRIND_STACK_*</code> calls.</p>
+<p>Valgrind will use this information to determine if a change to
+ the stack pointer is an item pushed onto the stack or a change over
+ to a new stack. Use this if you're using a user-level thread package
+ and are noticing spurious errors from Valgrind about uninitialized
+ memory reads.</p>
+</dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_STACK_DEREGISTER(id)</code>:</strong></span></span></dt>
+<dd><p>Deregisters a previously registered stack. Informs
+ Valgrind that previously registered memory range with stack id
+ <code class="computeroutput">id</code> is no longer a stack.</p></dd>
+<dt><span class="term"><span><strong class="command"><code class="computeroutput">VALGRIND_STACK_CHANGE(id, start, end)</code>:</strong></span></span></dt>
+<dd><p>Changes a previously registered stack. Informs
+ Valgrind that the previously registered stack with stack id
+ <code class="computeroutput">id</code> has changed its start and end
+ values. Use this if your user-level thread package implements
+ stack growth.</p></dd>
+</dl></div>
+<p>Note that <code class="filename">valgrind.h</code> is included by
+all the tool-specific header files (such as
+<code class="filename">memcheck.h</code>), so you don't need to include it
+in your client if you include a tool-specific header.</p>
+</div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="manual-core-adv.wrapping"></a>3.2.Function wrapping</h2></div></div></div>
+<p>
+Valgrind versions 3.2.0 and above can do function wrapping on all
+supported targets. In function wrapping, calls to some specified
+function are intercepted and rerouted to a different, user-supplied
+function. This can do whatever it likes, typically examining the
+arguments, calling onwards to the original, and possibly examining the
+result. Any number of functions may be wrapped.</p>
+<p>
+Function wrapping is useful for instrumenting an API in some way. For
+example, wrapping functions in the POSIX pthreads API makes it
+possible to notify Valgrind of thread status changes, and wrapping
+functions in the MPI (message-passing) API allows notifying Valgrind
+of memory status changes associated with message arrival/departure.
+Such information is usually passed to Valgrind by using client
+requests in the wrapper functions, although that is not of relevance
+here.</p>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.example"></a>3.2.1.A Simple Example</h3></div></div></div>
+<p>Supposing we want to wrap some function</p>
+<pre class="programlisting">
+int foo ( int x, int y ) { return x + y; }</pre>
+<p>A wrapper is a function of identical type, but with a special name
+which identifies it as the wrapper for <code class="computeroutput">foo</code>.
+Wrappers need to include
+supporting macros from <code class="computeroutput">valgrind.h</code>.
+Here is a simple wrapper which prints the arguments and return value:</p>
+<pre class="programlisting">
+#include <stdio.h>
+#include "valgrind.h"
+int I_WRAP_SONAME_FNNAME_ZU(NONE,foo)( int x, int y )
+{
+ int result;
+ OrigFn fn;
+ VALGRIND_GET_ORIG_FN(fn);
+ printf("foo's wrapper: args %d %d\n", x, y);
+ CALL_FN_W_WW(result, fn, x,y);
+ printf("foo's wrapper: result %d\n", result);
+ return result;
+}
+</pre>
+<p>To become active, the wrapper merely needs to be present in a text
+section somewhere in the same process' address space as the function
+it wraps, and for its ELF symbol name to be visible to Valgrind. In
+practice, this means either compiling to a
+<code class="computeroutput">.o</code> and linking it in, or
+compiling to a <code class="computeroutput">.so</code> and
+<code class="computeroutput">LD_PRELOAD</code>ing it in. The latter is more
+convenient in that it doesn't require relinking.</p>
+<p>All wrappers have approximately the above form. There are three
+crucial macros:</p>
+<p><code class="computeroutput">I_WRAP_SONAME_FNNAME_ZU</code>:
+this generates the real name of the wrapper.
+This is an encoded name which Valgrind notices when reading symbol
+table information. What it says is: I am the wrapper for any function
+named <code class="computeroutput">foo</code> which is found in
+an ELF shared object with an empty
+("<code class="computeroutput">NONE</code>") soname field. The specification
+mechanism is powerful in
+that wildcards are allowed for both sonames and function names.
+The details are discussed below.</p>
+<p><code class="computeroutput">VALGRIND_GET_ORIG_FN</code>:
+once in the the wrapper, the first priority is
+to get hold of the address of the original (and any other supporting
+information needed). This is stored in a value of opaque
+type <code class="computeroutput">OrigFn</code>.
+The information is acquired using
+<code class="computeroutput">VALGRIND_GET_ORIG_FN</code>. It is crucial
+to make this macro call before calling any other wrapped function
+in the same thread.</p>
+<p><code class="computeroutput">CALL_FN_W_WW</code>: eventually we will
+want to call the function being
+wrapped. Calling it directly does not work, since that just gets us
+back to the wrapper and tends to kill the program in short order by
+stack overflow. Instead, the result lvalue,
+<code class="computeroutput">OrigFn</code> and arguments are
+handed to one of a family of macros of the form
+<code class="computeroutput">CALL_FN_*</code>. These
+cause Valgrind to call the original and avoid recursion back to the
+wrapper.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.specs"></a>3.2.2.Wrapping Specifications</h3></div></div></div>
+<p>This scheme has the advantage of being self-contained. A library of
+wrappers can be compiled to object code in the normal way, and does
+not rely on an external script telling Valgrind which wrappers pertain
+to which originals.</p>
+<p>Each wrapper has a name which, in the most general case says: I am the
+wrapper for any function whose name matches FNPATT and whose ELF
+"soname" matches SOPATT. Both FNPATT and SOPATT may contain wildcards
+(asterisks) and other characters (spaces, dots, @, etc) which are not
+generally regarded as valid C identifier names.</p>
+<p>This flexibility is needed to write robust wrappers for POSIX pthread
+functions, where typically we are not completely sure of either the
+function name or the soname, or alternatively we want to wrap a whole
+set of functions at once.</p>
+<p>For example, <code class="computeroutput">pthread_create</code>
+in GNU libpthread is usually a
+versioned symbol - one whose name ends in, eg,
+<code class="computeroutput">@GLIBC_2.3</code>. Hence we
+are not sure what its real name is. We also want to cover any soname
+of the form <code class="computeroutput">libpthread.so*</code>.
+So the header of the wrapper will be</p>
+<pre class="programlisting">
+int I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0,pthreadZucreateZAZa)
+ ( ... formals ... )
+ { ... body ... }
+</pre>
+<p>In order to write unusual characters as valid C function names, a
+Z-encoding scheme is used. Names are written literally, except that
+a capital Z acts as an escape character, with the following encoding:</p>
+<pre class="programlisting">
+ Za encodes *
+ Zp +
+ Zc :
+ Zd .
+ Zu _
+ Zh -
+ Zs (space)
+ ZA @
+ ZZ Z
+ ZL ( # only in valgrind 3.3.0 and later
+ ZR ) # only in valgrind 3.3.0 and later
+</pre>
+<p>Hence <code class="computeroutput">libpthreadZdsoZd0</code> is an
+encoding of the soname <code class="computeroutput">libpthread.so.0</code>
+and <code class="computeroutput">pthreadZucreateZAZa</code> is an encoding
+of the function name <code class="computeroutput">pthread_create@*</code>.
+</p>
+<p>The macro <code class="computeroutput">I_WRAP_SONAME_FNNAME_ZZ</code>
+constructs a wrapper name in which
+both the soname (first component) and function name (second component)
+are Z-encoded. Encoding the function name can be tiresome and is
+often unnecessary, so a second macro,
+<code class="computeroutput">I_WRAP_SONAME_FNNAME_ZU</code>, can be
+used instead. The <code class="computeroutput">_ZU</code> variant is
+also useful for writing wrappers for
+C++ functions, in which the function name is usually already mangled
+using some other convention in which Z plays an important role. Having
+to encode a second time quickly becomes confusing.</p>
+<p>Since the function name field may contain wildcards, it can be
+anything, including just <code class="computeroutput">*</code>.
+The same is true for the soname.
+However, some ELF objects - specifically, main executables - do not
+have sonames. Any object lacking a soname is treated as if its soname
+was <code class="computeroutput">NONE</code>, which is why the original
+example above had a name
+<code class="computeroutput">I_WRAP_SONAME_FNNAME_ZU(NONE,foo)</code>.</p>
+<p>Note that the soname of an ELF object is not the same as its
+file name, although it is often similar. You can find the soname of
+an object <code class="computeroutput">libfoo.so</code> using the command
+<code class="computeroutput">readelf -a libfoo.so | grep soname</code>.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.semantics"></a>3.2.3.Wrapping Semantics</h3></div></div></div>
+<p>The ability for a wrapper to replace an infinite family of functions
+is powerful but brings complications in situations where ELF objects
+appear and disappear (are dlopen'd and dlclose'd) on the fly.
+Valgrind tries to maintain sensible behaviour in such situations.</p>
+<p>For example, suppose a process has dlopened (an ELF object with
+soname) <code class="computeroutput">object1.so</code>, which contains
+<code class="computeroutput">function1</code>. It starts to use
+<code class="computeroutput">function1</code> immediately.</p>
+<p>After a while it dlopens <code class="computeroutput">wrappers.so</code>,
+which contains a wrapper
+for <code class="computeroutput">function1</code> in (soname)
+<code class="computeroutput">object1.so</code>. All subsequent calls to
+<code class="computeroutput">function1</code> are rerouted to the wrapper.</p>
+<p>If <code class="computeroutput">wrappers.so</code> is
+later dlclose'd, calls to <code class="computeroutput">function1</code> are
+naturally routed back to the original.</p>
+<p>Alternatively, if <code class="computeroutput">object1.so</code>
+is dlclose'd but wrappers.so remains,
+then the wrapper exported by <code class="computeroutput">wrapper.so</code>
+becomes inactive, since there
+is no way to get to it - there is no original to call any more. However,
+Valgrind remembers that the wrapper is still present. If
+<code class="computeroutput">object1.so</code> is
+eventually dlopen'd again, the wrapper will become active again.</p>
+<p>In short, valgrind inspects all code loading/unloading events to
+ensure that the set of currently active wrappers remains consistent.</p>
+<p>A second possible problem is that of conflicting wrappers. It is
+easily possible to load two or more wrappers, both of which claim
+to be wrappers for some third function. In such cases Valgrind will
+complain about conflicting wrappers when the second one appears, and
+will honour only the first one.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.debugging"></a>3.2.4.Debugging</h3></div></div></div>
+<p>Figuring out what's going on given the dynamic nature of wrapping
+can be difficult. The
+<code class="computeroutput">--trace-redir=yes</code> flag makes
+this possible
+by showing the complete state of the redirection subsystem after
+every
+<code class="computeroutput">mmap</code>/<code class="computeroutput">munmap</code>
+event affecting code (text).</p>
+<p>There are two central concepts:</p>
+<div class="itemizedlist"><ul type="disc">
+<li><p>A "redirection specification" is a binding of
+ a (soname pattern, fnname pattern) pair to a code address.
+ These bindings are created by writing functions with names
+ made with the
+ <code class="computeroutput">I_WRAP_SONAME_FNNAME_{ZZ,_ZU}</code>
+ macros.</p></li>
+<li><p>An "active redirection" is code-address to
+ code-address binding currently in effect.</p></li>
+</ul></div>
+<p>The state of the wrapping-and-redirection subsystem comprises a set of
+specifications and a set of active bindings. The specifications are
+acquired/discarded by watching all
+<code class="computeroutput">mmap</code>/<code class="computeroutput">munmap</code>
+events on code (text)
+sections. The active binding set is (conceptually) recomputed from
+the specifications, and all known symbol names, following any change
+to the specification set.</p>
+<p><code class="computeroutput">--trace-redir=yes</code> shows the contents
+of both sets following any such event.</p>
+<p><code class="computeroutput">-v</code> prints a line of text each
+time an active specification is used for the first time.</p>
+<p>Hence for maximum debugging effectiveness you will need to use both
+flags.</p>
+<p>One final comment. The function-wrapping facility is closely
+tied to Valgrind's ability to replace (redirect) specified
+functions, for example to redirect calls to
+<code class="computeroutput">malloc</code> to its
+own implementation. Indeed, a replacement function can be
+regarded as a wrapper function which does not call the original.
+However, to make the implementation more robust, the two kinds
+of interception (wrapping vs replacement) are treated differently.
+</p>
+<p><code class="computeroutput">--trace-redir=yes</code> shows
+specifications and bindings for both
+replacement and wrapper functions. To differentiate the
+two, replacement bindings are printed using
+<code class="computeroutput">R-></code> whereas
+wraps are printed using <code class="computeroutput">W-></code>.
+</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.limitations-cf"></a>3.2.5.Limitations - control flow</h3></div></div></div>
+<p>For the most part, the function wrapping implementation is robust.
+The only important caveat is: in a wrapper, get hold of
+the <code class="computeroutput">OrigFn</code> information using
+<code class="computeroutput">VALGRIND_GET_ORIG_FN</code> before calling any
+other wrapped function. Once you have the
+<code class="computeroutput">OrigFn</code>, arbitrary
+calls between, recursion between, and longjumps out of wrappers
+should work correctly. There is never any interaction between wrapped
+functions and merely replaced functions
+(eg <code class="computeroutput">malloc</code>), so you can call
+<code class="computeroutput">malloc</code> etc safely from within wrappers.
+</p>
+<p>The above comments are true for {x86,amd64,ppc32}-linux. On
+ppc64-linux function wrapping is more fragile due to the (arguably
+poorly designed) ppc64-linux ABI. This mandates the use of a shadow
+stack which tracks entries/exits of both wrapper and replacement
+functions. This gives two limitations: firstly, longjumping out of
+wrappers will rapidly lead to disaster, since the shadow stack will
+not get correctly cleared. Secondly, since the shadow stack has
+finite size, recursion between wrapper/replacement functions is only
+possible to a limited depth, beyond which Valgrind has to abort the
+run. This depth is currently 16 calls.</p>
+<p>For all platforms ({x86,amd64,ppc32,ppc64}-linux) all the above
+comments apply on a per-thread basis. In other words, wrapping is
+thread-safe: each thread must individually observe the above
+restrictions, but there is no need for any kind of inter-thread
+cooperation.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.limitations-sigs"></a>3.2.6.Limitations - original function signatures</h3></div></div></div>
+<p>As shown in the above example, to call the original you must use a
+macro of the form <code class="computeroutput">CALL_FN_*</code>.
+For technical reasons it is impossible
+to create a single macro to deal with all argument types and numbers,
+so a family of macros covering the most common cases is supplied. In
+what follows, 'W' denotes a machine-word-typed value (a pointer or a
+C <code class="computeroutput">long</code>),
+and 'v' denotes C's <code class="computeroutput">void</code> type.
+The currently available macros are:</p>
+<pre class="programlisting">
+CALL_FN_v_v -- call an original of type void fn ( void )
+CALL_FN_W_v -- call an original of type long fn ( void )
+
+CALL_FN_v_W -- void fn ( long )
+CALL_FN_W_W -- long fn ( long )
+
+CALL_FN_v_WW -- void fn ( long, long )
+CALL_FN_W_WW -- long fn ( long, long )
+
+CALL_FN_v_WWW -- void fn ( long, long, long )
+CALL_FN_W_WWW -- long fn ( long, long, long )
+
+CALL_FN_W_WWWW -- long fn ( long, long, long, long )
+CALL_FN_W_5W -- long fn ( long, long, long, long, long )
+CALL_FN_W_6W -- long fn ( long, long, long, long, long, long )
+and so on, up to
+CALL_FN_W_12W
+</pre>
+<p>The set of supported types can be expanded as needed. It is
+regrettable that this limitation exists. Function wrapping has proven
+difficult to implement, with a certain apparently unavoidable level of
+ickyness. After several implementation attempts, the present
+arrangement appears to be the least-worst tradeoff. At least it works
+reliably in the presence of dynamic linking and dynamic code
+loading/unloading.</p>
+<p>You should not attempt to wrap a function of one type signature with a
+wrapper of a different type signature. Such trickery will surely lead
+to crashes or strange behaviour. This is not of course a limitation
+of the function wrapping implementation, merely a reflection of the
+fact that it gives you sweeping powers to shoot yourself in the foot
+if you are not careful. Imagine the instant havoc you could wreak by
+writing a wrapper which matched any function name in any soname - in
+effect, one which claimed to be a wrapper for all functions in the
+process.</p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="manual-core-adv.wrapping.examples"></a>3.2.7.Examples</h3></div></div></div>
+<p>In the source tree,
+<code class="computeroutput">memcheck/tests/wrap[1-8].c</code> provide a series of
+examples, ranging from very simple to quite advanced.</p>
+<p><code class="computeroutput">auxprogs/libmpiwrap.c</code> is an example
+of wrapping a big, complex API (the MPI-2 interface). This file defines
+almost 300 different wrappers.</p>
+</div>
+</div>
+</div>
+<div>
+<br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer">
+<tr>
+<td rowspan="2" width="40%" align="left">
+<a accesskey="p" href="manual-core.html"><<2.Using and understanding the Valgrind core</a></td>
+<td width="20%" align="center"><a accesskey="u" href="manual.html">Up</a></td>
+<td rowspan="2" width="40%" align="right"><a accesskey="n" href="mc-manual.html">4.Memcheck: a heavyweight memory checker>></a>
+</td>
+</tr>
+<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr>
+</table>
+</div>
+</body>
+</html>
|
|
From: Tom H. <th...@cy...> - 2007-12-11 03:14:53
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-11 03:00:03 GMT 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 == 357 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2007-12-11 03:07:41
|
Author: sewardj
Date: 2007-12-11 03:07:29 +0000 (Tue, 11 Dec 2007)
New Revision: 341
Log:
Connect to 3.3.0 stuff.
Modified:
trunk/docs/index.html
Modified: trunk/docs/index.html
===================================================================
--- trunk/docs/index.html 2007-12-11 02:58:35 UTC (rev 340)
+++ trunk/docs/index.html 2007-12-11 03:07:29 UTC (rev 341)
@@ -3,17 +3,25 @@
<div>
<div align="center"><h1 class="title">
<a name="set-index"></a>Valgrind Documentation</h1></div>
-<div align="center"><p class="releaseinfo">Release 3.1.0 November 25 2005</p></div>
-<div align="center"><p class="copyright">Copyright 2000-2005
+<div align="center"><p class="releaseinfo">Release 3.3.0 7 December 2007</p></div>
+<div align="center"><p class="copyright">Copyright 2000-2007
<a href="manual/dist.authors.html" title="2.AUTHORS">AUTHORS</a>
</p></div>
<div align="center"><div class="legalnotice">
-<a name="id2479086"></a><p>Permission is granted to copy, distribute and/or
- modify this document under the terms of the GNU Free Documentation License,
- Version 1.2 or any later version published by the Free Software Foundation;
- with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
- Texts. A copy of the license is included in the section entitled
- <a href="manual/license.gfdl.html">The GNU Free Documentation License</a>.</p>
+<a name="id2480019"></a><p>Permission is granted to copy, distribute and/or modify
+ this document under the terms of the GNU Free Documentation
+ License, Version 1.2 or any later version published by the
+ Free Software Foundation; with no Invariant Sections, with no
+ Front-Cover Texts, and with no Back-Cover Texts. A copy of
+ the license is included in the section entitled
+ <a href="manual/license.gfdl.html">The GNU Free Documentation License</a>.
+ </p>
+<p>This is the top level of Valgrind's documentation tree.
+ The documentation is contained in six logically separate
+ documents, as listed in the following Table of Contents. To
+ get started quickly, read the Valgrind Quick Start Guide. For
+ full documentation on Valgrind, read the Valgrind User Manual.
+ </p>
</div></div>
</div>
<hr>
|
|
From: <sv...@va...> - 2007-12-11 02:58:48
|
Author: sewardj
Date: 2007-12-11 02:58:35 +0000 (Tue, 11 Dec 2007)
New Revision: 340
Log:
Move 3.2.3 to the old-releases area.
Modified:
trunk/downloads/current.html
trunk/downloads/old.html
Modified: trunk/downloads/current.html
===================================================================
--- trunk/downloads/current.html 2007-12-11 02:45:52 UTC (rev 339)
+++ trunk/downloads/current.html 2007-12-11 02:58:35 UTC (rev 340)
@@ -39,29 +39,7 @@
AIX5.3, and many minor refinements.</p>
-<!--
-<div id="release">
-<a name="current"><h3>Release 3.2.3</h3></a>
-
-<p><a href="/downloads/valgrind-3.2.3.tar.bz2">valgrind 3.2.3 (tar.bz2)</a>
-[4016Kb] - 29 January 2007.<br />
-For {x86,amd64,ppc32,ppc64}-linux.<br />
-<span class="md5sum">md5: 978847992b136c8d8cb5c6559a91df1c</span></p>
-
-<p>You may want to look at the
-<a href="/docs/manual/dist.news.html">3.2.3 release notes</a>.
-</p>
-
-<p>3.2.3 is almost identical to 3.2.2, but fixes a regression that
-unfortunately crept into 3.2.2. The regression causes an assertion
-failure in Valgrind when running certain obscure SSE code fragments
-on x86-linux and amd64-linux. Please do not use (or package) 3.2.2;
-instead use 3.2.3.</p>
--->
-
-
-
<div class="hr_brown"><hr/></div>
<h3>Valkyrie 1.2.0</h3>
Modified: trunk/downloads/old.html
===================================================================
--- trunk/downloads/old.html 2007-12-11 02:45:52 UTC (rev 339)
+++ trunk/downloads/old.html 2007-12-11 02:58:35 UTC (rev 340)
@@ -12,7 +12,25 @@
<div id="release">
+
<div class="hr_brown"><hr/></div>
+<h3>valgrind-3.2.3</h3>
+
+<p>valgrind 3.2.3 (tar.bz2)</a>
+[4016Kb] - 29 January 2007.<br />
+For {x86,amd64,ppc32,ppc64}-linux.<br />
+<span class="md5sum">md5: 978847992b136c8d8cb5c6559a91df1c</span></p>
+
+
+<p>3.2.3 is almost identical to 3.2.2, but fixes a regression that
+unfortunately crept into 3.2.2. The regression causes an assertion
+failure in Valgrind when running certain obscure SSE code fragments
+on x86-linux and amd64-linux. Please do not use (or package) 3.2.2;
+instead use 3.2.3.</p>
+
+
+
+<div class="hr_brown"><hr/></div>
<h3>valgrind-3.2.2</h3>
<p>valgrind 3.2.2 (tar.bz2)</a>
|
|
From: <sv...@va...> - 2007-12-11 02:45:50
|
Author: sewardj Date: 2007-12-11 02:45:52 +0000 (Tue, 11 Dec 2007) New Revision: 339 Log: Update for 3.3.0, including putting the manual on-line. Modified: trunk/docs/manual/FAQ.html trunk/docs/manual/QuickStart.html trunk/docs/manual/cg-manual.html trunk/docs/manual/cl-format.html trunk/docs/manual/cl-manual.html trunk/docs/manual/dist.acknowledge.html trunk/docs/manual/dist.authors.html trunk/docs/manual/dist.html trunk/docs/manual/dist.install.html trunk/docs/manual/dist.news.html trunk/docs/manual/dist.readme-developers.html trunk/docs/manual/dist.readme-missing.html trunk/docs/manual/dist.readme-packagers.html trunk/docs/manual/dist.readme.html trunk/docs/manual/faq.html trunk/docs/manual/hg-manual.html trunk/docs/manual/index.html trunk/docs/manual/license.gfdl.html trunk/docs/manual/license.gpl.html trunk/docs/manual/licenses.html trunk/docs/manual/lk-manual.html trunk/docs/manual/manual-core.html trunk/docs/manual/manual-intro.html trunk/docs/manual/manual.html trunk/docs/manual/mc-manual.html trunk/docs/manual/ms-manual.html trunk/docs/manual/nl-manual.html trunk/docs/manual/quick-start.html trunk/docs/manual/tech-docs.html trunk/docs/manual/valgrind_manual.html.tar.bz2 trunk/docs/manual/valgrind_manual.pdf trunk/docs/manual/valgrind_manual.ps.bz2 trunk/docs/manual/writing-tools.html trunk/downloads/current.html trunk/index.html trunk/php/.htconfx [... diff too large to include ...] |
|
From: <js...@ac...> - 2007-12-11 01:22:10
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-11 02:00:01 CET 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 == 288 tests, 27 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: <sv...@va...> - 2007-12-11 01:03:22
|
Author: sewardj Date: 2007-12-11 01:03:22 +0000 (Tue, 11 Dec 2007) New Revision: 7297 Log: Bop version. Modified: branches/VALGRIND_3_3_BRANCH/configure.in Modified: branches/VALGRIND_3_3_BRANCH/configure.in =================================================================== --- branches/VALGRIND_3_3_BRANCH/configure.in 2007-12-11 00:50:54 UTC (rev 7296) +++ branches/VALGRIND_3_3_BRANCH/configure.in 2007-12-11 01:03:22 UTC (rev 7297) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.3.0, val...@li...) +AC_INIT(Valgrind, 3.3.1.SVN, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE |
|
From: <sv...@va...> - 2007-12-11 00:50:51
|
Author: sewardj Date: 2007-12-11 00:50:54 +0000 (Tue, 11 Dec 2007) New Revision: 7296 Log: Bop version. Modified: trunk/configure.in Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2007-12-11 00:49:33 UTC (rev 7295) +++ trunk/configure.in 2007-12-11 00:50:54 UTC (rev 7296) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.3.0, val...@li...) +AC_INIT(Valgrind, 3.4.0.SVN, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE |
|
From: <sv...@va...> - 2007-12-11 00:49:30
|
Author: sewardj
Date: 2007-12-11 00:49:33 +0000 (Tue, 11 Dec 2007)
New Revision: 7295
Log:
Update notes on repo-mangling.
Modified:
trunk/docs/internals/release-HOWTO.txt
Modified: trunk/docs/internals/release-HOWTO.txt
===================================================================
--- trunk/docs/internals/release-HOWTO.txt 2007-12-11 00:47:48 UTC (rev 7294)
+++ trunk/docs/internals/release-HOWTO.txt 2007-12-11 00:49:33 UTC (rev 7295)
@@ -134,20 +134,20 @@
branches too. Useful examples:
cd valgrind
- svn copy trunk tags/VALGRIND_3_1_0
- svn copy trunk branches/VALGRIND_3_1_BRANCH
+ svn copy trunk tags/VALGRIND_3_3_0
+ svn copy trunk branches/VALGRIND_3_3_BRANCH
cd vex
- svn copy trunk tags/VEX_3_1_0
- svn copy trunk branches/VEX_3_1_BRANCH
+ svn copy trunk tags/VEX_3_3_0
+ svn copy trunk branches/VEX_3_3_BRANCH
cd valgrind
- cd VALGRIND_3_1_0
+ cd tags/VALGRIND_3_3_0
svn propset svn:externals \
- "VEX svn://svn.valgrind.org/vex/tags/VEX_3_1_0" .
- cd VALGRIND_3_1_BRANCH
+ "VEX svn://svn.valgrind.org/vex/tags/VEX_3_3_0" .
+ cd branches/VALGRIND_3_3_BRANCH
svn propset svn:externals \
- "VEX svn://svn.valgrind.org/vex/branches/VEX_3_1_BRANCH" .
+ "VEX svn://svn.valgrind.org/vex/branches/VEX_3_3_BRANCH" .
- Update website:
- Put the tarball up.
|
|
From: <sv...@va...> - 2007-12-11 00:47:45
|
Author: sewardj Date: 2007-12-11 00:47:48 +0000 (Tue, 11 Dec 2007) New Revision: 7294 Log: Swizzle external. Modified: branches/VALGRIND_3_3_BRANCH/ Property changes on: branches/VALGRIND_3_3_BRANCH ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX svn://svn.valgrind.org/vex/branches/VEX_3_3_BRANCH |
|
From: <sv...@va...> - 2007-12-11 00:46:18
|
Author: sewardj Date: 2007-12-11 00:46:20 +0000 (Tue, 11 Dec 2007) New Revision: 7293 Log: Swizzle external. Modified: tags/VALGRIND_3_3_0/ Property changes on: tags/VALGRIND_3_3_0 ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX svn://svn.valgrind.org/vex/tags/VEX_3_3_0 |
|
From: <sv...@va...> - 2007-12-11 00:41:55
|
Author: sewardj Date: 2007-12-11 00:41:57 +0000 (Tue, 11 Dec 2007) New Revision: 1806 Log: Create stable branch associated with Valgrind 3.3.X (copy of trunk r1804) --This line, and those below, will be ignored-- A VEX_3_3_BRANCH Added: branches/VEX_3_3_BRANCH/ Copied: branches/VEX_3_3_BRANCH (from rev 1804, trunk) |
|
From: <sv...@va...> - 2007-12-11 00:40:17
|
Author: sewardj Date: 2007-12-11 00:40:20 +0000 (Tue, 11 Dec 2007) New Revision: 1805 Log: Tag for Valgrind 3.3.0 (copy of trunk r1804) Added: tags/VEX_3_3_0/ Copied: tags/VEX_3_3_0 (from rev 1804, trunk) |
|
From: <sv...@va...> - 2007-12-11 00:37:43
|
Author: sewardj Date: 2007-12-11 00:37:47 +0000 (Tue, 11 Dec 2007) New Revision: 7292 Log: Create the 3.3.X stable branch (copy of trunk r7290) Added: branches/VALGRIND_3_3_BRANCH/ Copied: branches/VALGRIND_3_3_BRANCH (from rev 7290, trunk) |
|
From: <sv...@va...> - 2007-12-11 00:34:26
|
Author: sewardj Date: 2007-12-11 00:34:27 +0000 (Tue, 11 Dec 2007) New Revision: 7291 Log: Tag 3.3.0 (copy of trunk r7290) Added: tags/VALGRIND_3_3_0/ Copied: tags/VALGRIND_3_3_0 (from rev 7290, trunk) |