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
(23) |
2
(40) |
3
(17) |
4
(10) |
|
5
(14) |
6
(41) |
7
(26) |
8
(23) |
9
(15) |
10
(25) |
11
(14) |
|
12
(23) |
13
(11) |
14
(18) |
15
(21) |
16
(18) |
17
(8) |
18
(14) |
|
19
(16) |
20
(15) |
21
(12) |
22
(11) |
23
(8) |
24
(11) |
25
(12) |
|
26
(9) |
27
(17) |
28
(31) |
29
(16) |
30
(10) |
31
(17) |
|
|
From: Nicholas N. <nj...@cs...> - 2006-03-14 22:48:59
|
On Tue, 14 Mar 2006, Josef Weidendorfer wrote: > With the (to be) 3.2.0/3.1.1 the demangler replaces __libc_start_main with > "(below main)". I am not sure this is a good thing in general, > especially for tools where symbol names in the output are expected > to be as precise as possible (like eg. callgrind :-). > > I just wondered where this symbols is coming from when looking at a profile, > and did some research... > > Can this be done either at another level or only when a flag is given? > Or am I missing something here? It looks like this replacement is > unconditional. There already is the --show-below-main flag, looks like the code in VG_(demangle)() should be made conditional on it. And Callgrind could then set --show-below-main=no at startup. Julian, do you agree? The comparison against __libc_start_main and generic_start_main is also done in m_stacktrace.c:VG_(apply_StackTrace)() -- looks like it should be factored out from those two places into a separate function. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-03-14 22:44:08
|
On Tue, 14 Mar 2006, Libin Varghese wrote: > I am not able to understand the hashing algorithm < static UInt > hash_LockSet_w_wo(const LockSet *ls, const Mutex *with, const Mutex *without) >> used for the Locksets. So could someone please explain it to me. Looks like it just goes through the lockset and, for each entry, if it matches some criteria does some bit fiddling (left rotate and XORing). > Also please tell why is "LOCKSET_HASH_SZ" 1021, I mean why this number. Is > it because it is a prime number or are considering only 1021 locksets as > of now? I think because it's prime. Standard technique for hash tables. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-03-14 22:40:29
|
On Tue, 14 Mar 2006, Julian Seward wrote: >> Thanks for writing documentation about function wrapping. If I >> understand you correctly then wrapped functions run multithreaded ? > > No. > >> Does this imply that if a wrapper function accesses global data, that >> locking is required ? > > No. I was trying to say that wrapping is thread safe - each thread's > wrapping activities are completely independent. If a wrapper function > accesses global data then perhaps it does need locking, but that's > just standard requirements for multithreaded programming. But Valgrind forces programs to run single-threaded, right? So no locking should be necessary in wrapper functions provided by tools? Nick |
|
From: Josef W. <Jos...@gm...> - 2006-03-14 21:02:10
|
Hi, With the (to be) 3.2.0/3.1.1 the demangler replaces __libc_start_main with "(below main)". I am not sure this is a good thing in general, especially for tools where symbol names in the output are expected to be as precise as possible (like eg. callgrind :-). I just wondered where this symbols is coming from when looking at a profile, and did some research... Can this be done either at another level or only when a flag is given? Or am I missing something here? It looks like this replacement is unconditional. Josef |
|
From: <sv...@va...> - 2006-03-14 19:15:10
|
Author: sewardj
Date: 2006-03-14 19:14:59 +0000 (Tue, 14 Mar 2006)
New Revision: 1596
Log:
Merge r1521 (fix amd64 SSE front end causing too much memory to be
read for some SSE comparisons).
Modified:
branches/VEX_3_1_BRANCH/priv/guest-amd64/toIR.c
Modified: branches/VEX_3_1_BRANCH/priv/guest-amd64/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VEX_3_1_BRANCH/priv/guest-amd64/toIR.c 2006-03-14 18:39:29 U=
TC (rev 1595)
+++ branches/VEX_3_1_BRANCH/priv/guest-amd64/toIR.c 2006-03-14 19:14:59 U=
TC (rev 1596)
@@ -7678,7 +7678,7 @@
vpanic("findSSECmpOp(amd64,guest)");
}
=20
-/* Handles SSE 32F comparisons. */
+/* Handles SSE 32F/64F comparisons. */
=20
static ULong dis_SSEcmp_E_to_G ( Prefix pfx, Long delta,=20
HChar* opname, Bool all_lanes, Int sz )
@@ -7706,8 +7706,15 @@
addr =3D disAMode ( &alen, pfx, delta, dis_buf, 1 );
imm8 =3D getUChar(delta+alen);
findSSECmpOp(&needNot, &op, imm8, all_lanes, sz);
- assign( plain, binop(op, getXMMReg(gregOfRexRM(pfx,rm)),=20
- loadLE(Ity_V128, mkexpr(addr))) );
+ assign( plain,=20
+ binop(
+ op,
+ getXMMReg(gregOfRexRM(pfx,rm)),=20
+ all_lanes ? loadLE(Ity_V128, mkexpr(addr))
+ : sz =3D=3D 8 ? unop( Iop_64UtoV128, loadLE(Ity_I64,=
mkexpr(addr)))
+ : /*sz=3D=3D4*/ unop( Iop_32UtoV128, loadLE(Ity_I32,=
mkexpr(addr)))
+ )=20
+ );
delta +=3D alen+1;
DIP("%s $%d,%s,%s\n", opname,
(Int)imm8,
|
|
From: <sv...@va...> - 2006-03-14 18:39:34
|
Author: sewardj
Date: 2006-03-14 18:39:29 +0000 (Tue, 14 Mar 2006)
New Revision: 1595
Log:
Merge r1521 (fix x86 SSE front end causing too much memory to be read
for some SSE comparisons).
Modified:
branches/VEX_3_1_BRANCH/priv/guest-x86/toIR.c
Modified: branches/VEX_3_1_BRANCH/priv/guest-x86/toIR.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VEX_3_1_BRANCH/priv/guest-x86/toIR.c 2006-03-07 01:40:44 UTC=
(rev 1594)
+++ branches/VEX_3_1_BRANCH/priv/guest-x86/toIR.c 2006-03-14 18:39:29 UTC=
(rev 1595)
@@ -6680,7 +6680,7 @@
vpanic("findSSECmpOp(x86,guest)");
}
=20
-/* Handles SSE 32F comparisons. */
+/* Handles SSE 32F/64F comparisons. */
=20
static UInt dis_SSEcmp_E_to_G ( UChar sorb, Int delta,=20
HChar* opname, Bool all_lanes, Int sz )
@@ -6708,8 +6708,15 @@
addr =3D disAMode ( &alen, sorb, delta, dis_buf );
imm8 =3D getIByte(delta+alen);
findSSECmpOp(&needNot, &op, imm8, all_lanes, sz);
- assign( plain, binop(op, getXMMReg(gregOfRM(rm)),=20
- loadLE(Ity_V128, mkexpr(addr))) );
+ assign( plain,=20
+ binop(
+ op,
+ getXMMReg(gregOfRM(rm)),=20
+ all_lanes ? loadLE(Ity_V128, mkexpr(addr))
+ : sz =3D=3D 8 ? unop( Iop_64UtoV128, loadLE(Ity_I64,=
mkexpr(addr)))
+ : /*sz=3D=3D4*/ unop( Iop_32UtoV128, loadLE(Ity_I32,=
mkexpr(addr)))
+ )=20
+ );
delta +=3D alen+1;
DIP("%s $%d,%s,%s\n", opname,
(Int)imm8,
|
|
From: Julian S. <js...@ac...> - 2006-03-14 18:10:41
|
> Thanks for writing documentation about function wrapping. If I > understand you correctly then wrapped functions run multithreaded ? No. > Does this imply that if a wrapper function accesses global data, that > locking is required ? No. I was trying to say that wrapping is thread safe - each thread's wrapping activities are completely independent. If a wrapper function accesses global data then perhaps it does need locking, but that's just standard requirements for multithreaded programming. J |
|
From: Bart V. A. <bar...@gm...> - 2006-03-14 18:03:53
|
Hello Julian,
Thanks for writing documentation about function wrapping. If I
understand you correctly then wrapped functions run multithreaded ?
Does this imply that if a wrapper function accesses global data, that
locking is required ?
On 3/13/06, sv...@va... <sv...@va...> wrote:
> Author: sewardj
> Date: 2006-03-13 13:40:57 +0000 (Mon, 13 Mar 2006)
> New Revision: 5763
>
> Log:
> First pass at documenting how to use the function-wrapping facility.
>
> Modified:
> trunk/docs/xml/manual-core.xml
>
>
> /usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff =
/home/svn/repos/valgrind -r 5763' failed with this output:
> Modified: trunk/docs/xml/manual-core.xml
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- trunk/docs/xml/manual-core.xml 2006-03-12 19:28:34 UTC (rev 5762=
)
> +++ trunk/docs/xml/manual-core.xml 2006-03-13 13:40:57 UTC (rev 5763=
)
> @@ -1557,6 +1557,339 @@
|
|
From: Bart V. A. <bar...@gm...> - 2006-03-14 18:01:20
|
Hello John,
I'm using Valgrind 3.1.0 with MontaVista Linux Professional 3.1
and it works great. Note: I compiled Valgrind natively -- cross
compiling Valgrind does not work.
On 3/7/06, John Sensale <joh...@ya...> wrote:
>
> Hi,
> I have been trying to run my code under valgrind for memory leaks. Have b=
een
> cross compiling on Red Hat Linux with Monta Vista to cross compile for pp=
c32
> target. However I am getting the following error:
> WARNING: unhandled syscallL 72
> You may be able to write your own handler.
> Read the file README_MISSING_SYSCALL_OR_IOCTL
> Tried to read the above file and implement on my own, but got lost on the
> way.
> Can anyone help?
|
|
From: Libin V. <li...@gm...> - 2006-03-14 15:12:22
|
Hi all,
I am not able to understand the hashing algorithm < static UInt
hash_LockSet_w_wo(const LockSet *ls, const Mutex *with, const Mutex
*without) > used for the Locksets. So could someone please explain it to
me. Also please tell why is "LOCKSET_HASH_SZ" 1021, I mean why this
number. Is it because it is a prime number or are considering only 1021
locksets as of now?
--
Regards,
Libin Varghese.
|
|
From: <js...@ac...> - 2006-03-14 10:58:38
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-03-14 02:00:01 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 == 194 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Julian S. <js...@ac...> - 2006-03-14 09:19:48
|
On Monday 13 March 2006 23:07, Bryan Meredith wrote: > Looks OK to me but I have a question and the answer/clarification may > well belong inside: > > I wrap a function, say memcpy for example. > > program on sim cpu calls memcpy > > V > redirected to my memcpy wrapper > > V > wrapper does some stuff, possibly doing a client call or two > > V > wrapper calls original function > > Is this original function instrumented as normal Yes > - i.e. can I still > expect my dirty functions to be called etc or does the call and its > processing take place only on the real cpu? No, both the wrapper and original still run on the simulated CPU. > original function ran, how could I then update my state from the memory > and in particular, the registers that were touched during execution? I > see that there is the shadow stack for PPC The shadow stack is needed to deal with the strange ppc64-linux ABI, but that is purely an internal implementation detail. From the tool writers perspective function wrapping provides identical functionality on all platforms. J |
|
From: <js...@ac...> - 2006-03-14 03:55:40
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-03-14 04:40:00 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 == 199 tests, 6 stderr failures, 2 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/ppc32/mftocrf (stdout) |
|
From: Tom H. <to...@co...> - 2006-03-14 03:44:16
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-03-14 03:30:05 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 == 227 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-14 03:32:30
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-03-14 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 == 226 tests, 21 stderr failures, 1 stdout failure ================= 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-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (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/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-14 03:26:35
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-03-14 03:10:15 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 == 249 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (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 == 249 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Mar 14 03:19:18 2006 --- new.short Tue Mar 14 03:26:24 2006 *************** *** 8,11 **** ! == 249 tests, 6 stderr failures, 1 stdout failure ================= ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) --- 8,10 ---- ! == 249 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2006-03-14 03:20:41
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-03-14 03:05:18 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 == 249 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <sv...@va...> - 2006-03-14 00:56:38
|
Author: sewardj
Date: 2006-03-14 00:56:29 +0000 (Tue, 14 Mar 2006)
New Revision: 5764
Log:
Minor futzing (fontification, etc) of the function-wrappers documentation=
.
Modified:
trunk/docs/xml/manual-core.xml
Modified: trunk/docs/xml/manual-core.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/xml/manual-core.xml 2006-03-13 13:40:57 UTC (rev 5763)
+++ trunk/docs/xml/manual-core.xml 2006-03-14 00:56:29 UTC (rev 5764)
@@ -417,7 +417,7 @@
<programlisting><![CDATA[
tool_name1,tool_name2:suppression_name]]></programlisting>
=20
- <para>Recall that valgrind-2.0.X is a modular system, in which
+ <para>Recall that Valgrind is a modular system, in which
different instrumentation tools can observe your program whilst it
is running. Since different tools detect different kinds of errors,
it is necessary to say which tool(s) the suppression is meaningful
@@ -1586,56 +1586,68 @@
<programlisting><![CDATA[
int foo ( int x, int y ) { return x + y; }]]></programlisting>
=20
-<para>
-A wrapper is a function of identical type, but with a special name
-which identifies it as the wrapper for foo. Wrappers need to include
-supporting macros from valgrind.h. Here is a simple wrapper which
-prints the arguments and return value:</para>
+<para>A wrapper is a function of identical type, but with a special name
+which identifies it as the wrapper for <computeroutput>foo</computeroutp=
ut>.
+Wrappers need to include
+supporting macros from <computeroutput>valgrind.h</computeroutput>.
+Here is a simple wrapper which prints the arguments and return value:</p=
ara>
+
<programlisting><![CDATA[
- #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;
- }
+#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;
+}
]]></programlisting>
=20
<para>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 .o and linking it in, or
-compiling to a .so and LD_PRELOADing it in. The latter is more
+practice, this means either compiling to a=20
+<computeroutput>.o</computeroutput> and linking it in, or
+compiling to a <computeroutput>.so</computeroutput> and=20
+<computeroutput>LD_PRELOAD</computeroutput>ing it in. The latter is mor=
e
convenient in that it doesn't require relinking.</para>
=20
<para>All wrappers have approximately the above form. There are three
crucial macros:</para>
=20
-<para>I_WRAP_SONAME_FNNAME_ZU: this generates the real name of the wrapp=
er.
+<para><computeroutput>I_WRAP_SONAME_FNNAME_ZU</computeroutput>:=20
+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 "foo" which is found in an ELF shared object with an empty
-("NONE") soname field. The specification mechanism is powerful in
-that wildcards are allowed for both sonames and function names. More
-details below.</para>
+named <computeroutput>foo</computeroutput> which is found in=20
+an ELF shared object with an empty
+("<computeroutput>NONE</computeroutput>") soname field. The specificati=
on=20
+mechanism is powerful in
+that wildcards are allowed for both sonames and function names. =20
+The fine details are discussed below.</para>
=20
-<para>VALGRIND_GET_ORIG_FN: once in the the wrapper, the first priority =
is
+<para><computeroutput>VALGRIND_GET_ORIG_FN</computeroutput>:=20
+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 OrigFn.
-The information is acquired using VALGRIND_GET_ORIG_FN. It is crucial
+information needed). This is stored in a value of opaque=20
+type <computeroutput>OrigFn</computeroutput>.
+The information is acquired using=20
+<computeroutput>VALGRIND_GET_ORIG_FN</computeroutput>. It is crucial
to make this macro call before calling any other wrapped function
in the same thread.</para>
=20
-<para>CALL_FN_W_WW: eventually we will want to call the function being
+<para><computeroutput>CALL_FN_W_WW</computeroutput>: 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, OrigFn and arguments are
-handed to one of a family of macros of the form CALL_FN_*. These
+stack overflow. Instead, the result lvalue,=20
+<computeroutput>OrigFn</computeroutput> and arguments are
+handed to one of a family of macros of the form=20
+<computeroutput>CALL_FN_*</computeroutput>. These
cause Valgrind to call the original and avoid recursion back to the
wrapper.</para>
</sect2>
@@ -1659,10 +1671,13 @@
function name or the soname, or alternatively we want to wrap a whole
bunch of functions at once.</para>=20
=20
-<para>For example, pthread_create() in GNU libpthread's is usually a
-versioned symbol - one whose name ends in, eg, "@GLIBC_2.3". Hence we
+<para>For example, <computeroutput>pthread_create</computeroutput>=20
+in GNU libpthread is usually a
+versioned symbol - one whose name ends in, eg,=20
+<computeroutput>@GLIBC_2.3</computeroutput>. Hence we
are not sure what its real name is. We also want to cover any soname
-of the form "libpthread.so*". So the header of the wrapper will be</par=
a>
+of the form <computeroutput>libpthread.so*</computeroutput>.
+So the header of the wrapper will be</para>
=20
<programlisting><![CDATA[
int I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0,pthreadZucreateZAZa)
@@ -1686,25 +1701,32 @@
ZZ Z
]]></programlisting>
=20
-<para>Hence libpthreadZdsoZd0 is an encoding of the soname "libpthread.s=
o.0"
-and "pthreadZucreateZAZa" is an encoding of the function name
-"pthread_create@*".</para>
+<para>Hence <computeroutput>libpthreadZdsoZd0</computeroutput> is an=20
+encoding of the soname <computeroutput>libpthread.so.0</computeroutput>
+and <computeroutput>pthreadZucreateZAZa</computeroutput> is an encoding=20
+of the function name <computeroutput>pthread_create@*</computeroutput>.
+</para>
=20
-<para>The macro I_WRAP_SONAME_FNNAME_ZZ constructs a wrapper name in whi=
ch
+<para>The macro <computeroutput>I_WRAP_SONAME_FNNAME_ZZ</computeroutput>=
=20
+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, I_WRAP_SONAME_FNNAME_ZU, can be
-used instead. The _ZU variant is also useful for writing wrappers for
+often unnecessary, so a second macro,
+<computeroutput>I_WRAP_SONAME_FNNAME_ZU</computeroutput>, can be
+used instead. The <computeroutput>_ZU</computeroutput> variant is=20
+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.</para>
=20
<para>Since the function name field may contain wildcards, it can be
-anything, including just "*". The same is true for the soname.
+anything, including just <computeroutput>*</computeroutput>.
+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 "NONE", which is why the original example above had a name
-I_WRAP_SONAME_FNNAME_ZU(NONE,foo).</para>
+was <computeroutput>NONE</computeroutput>, which is why the original=20
+example above had a name
+<computeroutput>I_WRAP_SONAME_FNNAME_ZU(NONE,foo)</computeroutput>.</par=
a>
</sect2>
=20
<sect2 id=3D"manual-core.wrapping.semantics" xreflabel=3D"Wrapping Seman=
tics">
@@ -1716,20 +1738,27 @@
Valgrind tries to maintain sensible behaviour in such situations.</para>
=20
<para>For example, suppose a process has dlopened (an ELF object with
-soname) object1.so, which contains function1(). It starts to use
-function1() immediately.</para>
+soname) <computeroutput>object1.so</computeroutput>, which contains=20
+<computeroutput>function1</computeroutput>. It starts to use
+<computeroutput>function1</computeroutput> immediately.</para>
=20
-<para>After a while it dlopens wrappers.so, which contains a wrapper
-for function1 in (soname) object1.so. All subsequent calls to=20
-function1() are rerouted to the wrapper.</para>
+<para>After a while it dlopens <computeroutput>wrappers.so</computeroutp=
ut>,
+which contains a wrapper
+for <computeroutput>function1</computeroutput> in (soname)=20
+<computeroutput>object1.so</computeroutput>. All subsequent calls to=20
+<computeroutput>function1</computeroutput> are rerouted to the wrapper.<=
/para>
=20
-<para>If wrappers.so is later dlclose'd, calls to function1() are=20
-naturally rerouted back to the original.</para>
+<para>If <computeroutput>wrappers.so</computeroutput> is=20
+later dlclose'd, calls to <computeroutput>function1</computeroutput> are=
=20
+naturally routed back to the original.</para>
=20
-<para>Alternatively, if object1.so is dlclose'd but wrappers.so remains,
-then the wrapper exported by wrapper.so becomes inactive, since there
+<para>Alternatively, if <computeroutput>object1.so</computeroutput>
+is dlclose'd but wrappers.so remains,
+then the wrapper exported by <computeroutput>wrapper.so</computeroutput>
+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 object1.so
+Valgrind remembers that the wrapper is still present. If=20
+<computeroutput>object1.so</computeroutput> is
eventually dlopen'd again, the wrapper will become active again.</para>
=20
<para>In short, valgrind inspects all code loading/unloading events to
@@ -1746,49 +1775,65 @@
<title>Debugging</title>
=20
<para>Figuring out what's going on given the dynamic nature of wrapping
-can be difficult. The --trace-redir=3Dyes flag makes this possible
+can be difficult. The=20
+<computeroutput>--trace-redir=3Dyes</computeroutput> flag makes=20
+this possible
by showing the complete state of the redirection subsystem after
-every mmap/munmap event affecting code (text).</para>
+every
+<computeroutput>mmap</computeroutput>/<computeroutput>munmap</computerou=
tput>
+event affecting code (text).</para>
=20
<para>There are two central concepts:</para>
=20
-<para>- A "redirection specification" is a binding of=20
+<itemizedlist>
+
+ <listitem><para>A "redirection specification" is a binding of=20
a (soname pattern, fnname pattern) pair to a code address.
These bindings are created by writing functions with names
- made with the I_WRAP_SONAME_FNNAME_{ZZ,_ZU} macros.</para>
+ made with the=20
+ <computeroutput>I_WRAP_SONAME_FNNAME_{ZZ,_ZU}</computeroutput>
+ macros.</para></listitem>
=20
-<para>- An "active redirection" is code-address to code-address binding
- currently in effect.</para>
+ <listitem><para>An "active redirection" is code-address to=20
+ code-address binding currently in effect.</para></listitem>
=20
+</itemizedlist>
+
<para>The state of the wrapping-and-redirection subsystem comprises a se=
t of
specifications and a set of active bindings. The specifications are
-acquired/discarded by watching all mmap/munmap events on code (text)
+acquired/discarded by watching all=20
+<computeroutput>mmap</computeroutput>/<computeroutput>munmap</computerou=
tput>
+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.</para>
=20
-<para>--trace-redir=3Dyes shows the contents of both sets following any =
such
-event.</para>
+<para><computeroutput>--trace-redir=3Dyes</computeroutput> shows the con=
tents=20
+of both sets following any such event.</para>
=20
-<para>-v prints a line of text each time an active specification is=20
-used for the first time.</para>
+<para><computeroutput>-v</computeroutput> prints a line of text each=20
+time an active specification is used for the first time.</para>
=20
<para>Hence for maximum debugging effectiveness you will need to use bot=
h
flags.</para>
=20
<para>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 malloc() to its
+functions, for example to redirect calls to=20
+<computeroutput>malloc</computeroutput> 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.
</para>
=20
-<para>--trace-redir=3Dyes shows specifications and bindings for both
+<para><computeroutput>--trace-redir=3Dyes</computeroutput> shows=20
+specifications and bindings for both
replacement and wrapper functions. To differentiate the=20
-two, replacement bindings are printed using "R->" whereas=20
-wraps are printed using "W->".</para>
+two, replacement bindings are printed using=20
+<computeroutput>R-></computeroutput> whereas=20
+wraps are printed using <computeroutput>W-></computeroutput>.
+</para>
</sect2>
=20
=20
@@ -1797,18 +1842,22 @@
<title>Limitations - control flow</title>
=20
<para>For the most part, the function wrapping implementation is robust.
-The only real caveat is that is is crucial, in a wrapper, get hold of
-the OrigFn information using VALGRIND_GET_ORIG_FN before calling any
-other wrapped function. Once you have the OrigFn, arbitrary
+The only important caveat is: in a wrapper, get hold of
+the <computeroutput>OrigFn</computeroutput> information using=20
+<computeroutput>VALGRIND_GET_ORIG_FN</computeroutput> before calling any
+other wrapped function. Once you have the=20
+<computeroutput>OrigFn</computeroutput>, arbitrary
intercalling, recursion between, and longjumping out of wrappers
should work correctly. There is never any interaction between wrapped
-functions and merely replaced functions (eg malloc), so you can call
-malloc etc safely from within wrappers.</para>
+functions and merely replaced functions=20
+(eg <computeroutput>malloc</computeroutput>), so you can call
+<computeroutput>malloc</computeroutput> etc safely from within wrappers.
+</para>
=20
<para>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 replacment
+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
@@ -1829,31 +1878,33 @@
<title>Limitations - original function signatures</title>
=20
<para>As shown in the above example, to call the original you must use a
-macro of the form CALL_FN_*. For technical reasons it is impossible
+macro of the form <computeroutput>CALL_FN_*</computeroutput>. =20
+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 an
-C 'long'), and 'v' denotes C's "void" type. The currently available
-macros are:</para>
+what follows, 'W' denotes a machine-word-typed value (a pointer or a
+C <computeroutput>long</computeroutput>),=20
+and 'v' denotes C's <computeroutput>void</computeroutput> type.
+The currently available macros are:</para>
=20
<programlisting><![CDATA[
- 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_v -- call an original of type void fn ( void )
+CALL_FN_W_v -- call an original of type long fn ( void )
=20
- CALL_FN_v_W -- void fn ( long )
- CALL_FN_W_W -- long fn ( long )
+CALL_FN_v_W -- void fn ( long )
+CALL_FN_W_W -- long fn ( long )
=20
- CALL_FN_v_WW -- void fn ( long, long )
- CALL_FN_W_WW -- long fn ( long, long )
+CALL_FN_v_WW -- void fn ( long, long )
+CALL_FN_W_WW -- long fn ( long, long )
=20
- CALL_FN_v_WWW -- void fn ( long, long, long )
- CALL_FN_W_WWW -- long fn ( long, long, long )
+CALL_FN_v_WWW -- void fn ( long, long, long )
+CALL_FN_W_WWW -- long fn ( long, long, long )
=20
- 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=20
- CALL_FN_W_12W
+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=20
+CALL_FN_W_12W
]]></programlisting>
=20
<para>The set of supported types can be expanded as needed. It is
@@ -1878,12 +1929,13 @@
<sect2 id=3D"manual-core.wrapping.examples" xreflabel=3D"Examples">
<title>Examples</title>
=20
-<para>In the source tree, memcheck/tests/wrap[1-8].c provide a series of
+<para>In the source tree,=20
+<computeroutput>memcheck/tests/wrap[1-8].c</computeroutput> provide a se=
ries of
examples, ranging from very simple to quite advanced.</para>
=20
-<para>auxprogs/libmpiwrap.c is an example of wrapping a big, complex API
-(the MPI-2 interface). This file defines almost 300 different
-wrappers.</para>
+<para><computeroutput>auxprogs/libmpiwrap.c</computeroutput> is an examp=
le=20
+of wrapping a big, complex API (the MPI-2 interface). This file defines=
=20
+almost 300 different wrappers.</para>
</sect2>
=20
</sect1>
|