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
|
|
2
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-24 13:19:32
|
On Mon, 24 Mar 2003, Josef Weidendorfer wrote: > > Hmm, one problem is that it requires glibc to not be stripped, since > > spotting function entries relies on symbol information being present. > > I'm not sure whether this is likely or not. > > Symbol information for exported symbols in shared libraries can't be stripped, > as the runtime linker has to know about it. This isn't debug information, and > thus no problem. Ah, good, so no problem there. > I still think that wrapping malloc() is a skin issue, and the core only should > provide convenience functions for doing this in a simply way... I agree. N |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:17
|
On Sunday 23 March 2003 16:57, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > > An alternative solution for function wrapping would be not to use the > > > runtime linker (symbol overwriding, hack with __libc_malloc), but to > > > change instrumentation of the first BB of the given function, and do a > > > "jmp" into the valgrind wrapper version if the skin would like to use > > > it. > > > > Hey, good idea. I'll have to think about that some more... > > Hmm, one problem is that it requires glibc to not be stripped, since > spotting function entries relies on symbol information being present. > I'm not sure whether this is likely or not. Symbol information for exported symbols in shared libraries can't be stripped, as the runtime linker has to know about it. This isn't debug information, and thus no problem. Static linking with glibc is another issue - but valgrind doesn't work with static binaries at all. > Also, there's the issue of whether malloc() gets called before Valgrind > gains control, possibly because of static C++ constructors. I've > discussed this with Julian before but I cannot remember what the outcome > was, so maybe I'm wrong. Hmm. malloc() is passing requests to arena_malloc() if not running on the simulated CPU. I still think that wrapping malloc() is a skin issue, and the core only should provide convenience functions for doing this in a simply way... Josef |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:16
|
On Sunday 23 March 2003 17:03, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > In my latest calltree version, I introduced an infrastruction to specify > > instrumentation parameters on the basis of a function symbol name. > > [snip] > > Does it make sense to merge this in some way with the error suppression > > stuff? > > By this, I'm guessing you mean: after reading suppressions, if Valgrind > translates a function that is mentioned in a suppression, don't instrument > it because any errors from it will be suppressed anyway? No, I didn't thought about any concrete use cases for other skins. It's more about generalizing the idea of suppressions. I think I first have to work it out in my skin and perhaps propose a patch for the core later on. > Two problems with that: (a, minor) you don't get counts of the number of > errors suppressed, and (b, major) suppressions rely on calling context, so Oh. I have to look at the suppression code more deeply :-) Josef > just considering a function by itself wouldn't work -- errors from it > might need to be suppressed if called from function f(), but not if called > from function g(). > > Or maybe I misinterpreted your question... > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |