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
(1) |
2
(8) |
3
(7) |
4
(16) |
5
|
|
6
(3) |
7
(4) |
8
(1) |
9
(1) |
10
(4) |
11
(5) |
12
(1) |
|
13
|
14
(4) |
15
(2) |
16
|
17
(2) |
18
(9) |
19
(5) |
|
20
(9) |
21
(7) |
22
(9) |
23
(5) |
24
|
25
(1) |
26
|
|
27
|
28
(1) |
29
(11) |
30
(6) |
31
|
|
|
|
From: Josef W. <Jos...@gm...> - 2002-10-11 21:34:07
|
Hi, I recently updated to Suse8.1 with GCC 3.2 and had a lot of problems with cachegrind regarding DWARF2 debug info. Attached patch is for the Dwarf2 source line info reader; For reading, a state machine is used reconstructing source line info while running and reading (see DWARF2 specification, ch. 6.2). The state machine was correct, but the calls to addLineInfo() were wrong: It reported most of the times too small ranges for source code statements, because it used only the diff of the last state machine command instead of the diff to the last statement boundary. Effect: Around 1/3 of all addresses with source line info got=20 unknown location. The patch adds a "last_address" to the state machine to remember the last= =20 statement boundary. On reset, it#s initialised to the "invalid" address 0= =2E I=20 hope this is OK (or should we use "(Addr)-1" instead?). The patch now uses the "is_stmt" boolean correctly to only call addLineIn= fo() if there's a statement boundary (on x86, is_stmt most probably is always true...). Please apply both to 1.0.x branch and HEAD. Another problem: Symbols like "_GLOBAL__I__ZNK10DirTreeMap9classNameEv" aren't demangled. I need to look at this... Josef |
|
From: Nicholas N. <nj...@ca...> - 2002-10-11 11:20:26
|
On 10 Oct 2002, Jeremy Fitzhardinge wrote: > At the moment, not many skins have client callbacks (only memcheck, I > think). However, if other skins follow memcheck's example of starting > callbacks at VG_USERREQ__FINAL_DUMMY_CLIENT_REQUEST + 1, they will all > end up with overlapping numbers. > > This means that if a particular program under study has callbacks for > different skins, they will end up doing the wrong thing if run with the > wrong skin. It seems to me that there needs to be a systematic way for > skins to distinguish their callback numbers from each other. Yes, good point. > Well, since there seems to be a de-facto standard for each skin to have > a two letter code, I implemented a scheme to use it as a way for skins > to distinguish their client requests. > > I also made it not an error for a callback to be unimplemented, since > Valgrind is getting more capable with more skins, it will be common to > have a program with client requests inserted for multiple skins. As > part of this, I changed the interface to SK_(handle_client_request) so > that a skin can indicate that it did not handle the request, so that the > proper default return value can be returned. > > Patch against CVS head. This seems like a good way to do it, although I think I'll implement it slightly differently using a template function -- that must be defined if the client_requests need is set -- that returns the two letter prefix. Thanks for the good suggestion. N |
|
From: Nicholas N. <nj...@ca...> - 2002-10-11 09:48:08
|
On 10 Oct 2002, Jeremy Fitzhardinge wrote: > My skin needs to register baseblock helpers after parsing its command > line options (so that it knows what it needs to do). Unfortunately the > baseblock is currently being set up before calling SK_(post_clo_init). Hmm, fair enough. I'll fix it in the head. N |
|
From: Jeremy F. <je...@go...> - 2002-10-11 06:17:48
|
On Thu, 2002-10-10 at 22:48, Jeremy Fitzhardinge wrote: > +#define VG_IS_SKIN_USERREQ(a, b, v) (VG_USERREQ_SKIN_BASE(a,b) == ((v) & 0xff00)) Complete with silly bug. This should be: +#define VG_IS_SKIN_USERREQ(a, b, v) (VG_USERREQ_SKIN_BASE(a,b) == ((v) & 0xffff0000)) J |
|
From: Jeremy F. <je...@go...> - 2002-10-11 05:48:59
|
On Thu, 2002-10-10 at 12:25, Jeremy Fitzhardinge wrote: > This means that if a particular program under study has callbacks for > different skins, they will end up doing the wrong thing if run with the > wrong skin. It seems to me that there needs to be a systematic way for > skins to distinguish their callback numbers from each other. Maybe > encode some kind of skin ID into the top 16 bits of the request number? Well, since there seems to be a de-facto standard for each skin to have a two letter code, I implemented a scheme to use it as a way for skins to distinguish their client requests. I also made it not an error for a callback to be unimplemented, since Valgrind is getting more capable with more skins, it will be common to have a program with client requests inserted for multiple skins. As part of this, I changed the interface to SK_(handle_client_request) so that a skin can indicate that it did not handle the request, so that the proper default return value can be returned. Patch against CVS head. J |