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
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2002-12-15 13:25:39
|
Hi Josef
> recently I checked cachegrind in CVS HEAD.
> It gives out its information on BB level.
> E.g. for function foobar(), it gives cost values for
> foobar, foobar+20, foobar+50.
>
> I don't think this is intended, because the results look strange together
> with the usage of source line granularity. And it skrews up efficiency in
> the used hashes (35 BBs per source file ??).
I just checked a fix for this into CVS. The old behaviour should have
returned now. Maybe you can test it if you have a spare minute?
What is the status re making kcachegrind work well with the cvs head,
and therefore the soon-to-arrive 2.0 release?
See the attached message -- it looks like it would be cool if kcg worked
with the cvs head. CVS head contains bug fixes which fix Jody's
problem, and I really don't want to make any further releases of the 1.0.X
series since the head is now so vastly superior to it. Ideally we could
coordinate a little so that when v-2.0 finally ships (end Jan) there
is already good kcachegrind support for it.
Finally ... I think there is an outstanding issue re loading weak symbols
(didn't you mail me about that?) But I see in the cvs head this ...
snaffle_it
= ( (ELF32_ST_BIND(o_symtab[i].st_info) == STB_GLOBAL ||
ELF32_ST_BIND(o_symtab[i].st_info) == STB_LOCAL ||
ELF32_ST_BIND(o_symtab[i].st_info) == STB_WEAK)
&&
(ELF32_ST_TYPE(o_symtab[i].st_info) == STT_FUNC ||
(VG_(needs).data_syms
&& ELF32_ST_TYPE(o_symtab[i].st_info) == STT_OBJECT))
);
(vg_symtab2.c:1650) so that problem only exists in 1.0.X ? Can you
clarify (I'm unsure here).
Thanks,
J
---------------------------------------------------------------------
cachegrind vs GNOME
Date: Wed Dec 11 04:16:09 2002
From: Jody Goldberg <jo...@gn...>
To: js...@ac..., nj...@ca...
valgrind-1.0.x works nicely with GNOME2 applications provided one adds
--alignment=8
Many thanks for your excellent work. It's reduced my dependence on
people with access to purify. Sadly cachegrind-1.0 does not appear
to accept the alignment flag. I tried hand tweaking things to hard
code the parm to 8 to no avail. The 1.1.0 release appears to work
nicely, but does not seem compatible with kcachegrind or its
callgraph patch.
Any suggestions ?
Jody
|
|
From: Jeremy F. <je...@go...> - 2002-12-15 02:16:03
|
On Sat, 2002-12-14 at 17:21, Julian Seward wrote:
> So I don't know; perhaps if you get rid of all mentions of those syms
> in the two abovementioned files, you might get a working arrangement.
> It would break other people tho.
I wonder if there's another way of forcing/tweaking/suppressing package
dependencies from within the .spec file?
> All this total crud is yet another reason why I'd like to rearrange V so
> that is is a standard C application which does all the ELF loading
> itself, as briefly discussed a couple of months ago. Then we wouldn't have
> to play these games.
Hm, I don't think that's how it would pan out. I think the idea would
be that you'd "manually" build the initial address space for the target
application using the ELF file, but let the target app run a completely
standard ld.so running on the emulated CPU. However, to do threading,
you'd still need a special libpthread so V can catch all the thread
stuff and do something about it (unless you want to completely change
the thread model too).
J
|
|
From: Julian S. <js...@ac...> - 2002-12-15 01:39:49
|
On Sunday 15 December 2002 1:30 am, you wrote: > On Sat, 2002-12-14 at 17:03, Julian Seward wrote: > > Running current cvs + 44 + 45: > > > > ==25360== Reading syms from /home/apps/Exp/Inst/lib/libkateinterfaces.so > > > > valgrind: vg_symtab2.c:706 (canonicaliseScopetab): Assertion > > `si->scopetab[i].addr < si->scopetab[i+1].addr' failed. > > > > This .so is part of KDE-3.1-rc3, built by gcc-2.95.3, fwiw. > > Can you send me the .so? Yes, I'll send it in a seperate msg. It's more than a megabyte even bzip'd. It should show up shortly. J |
|
From: Jeremy F. <je...@go...> - 2002-12-15 01:30:41
|
On Sat, 2002-12-14 at 17:03, Julian Seward wrote:
> Running current cvs + 44 + 45:
>
> ==25360== Reading syms from /home/apps/Exp/Inst/lib/libkateinterfaces.so
>
> valgrind: vg_symtab2.c:706 (canonicaliseScopetab): Assertion
> `si->scopetab[i].addr < si->scopetab[i+1].addr' failed.
>
> This .so is part of KDE-3.1-rc3, built by gcc-2.95.3, fwiw.
Can you send me the .so?
J
|
|
From: Julian S. <js...@ac...> - 2002-12-15 01:13:39
|
> I'm having trouble making RH8.0's buildrpm happy. There was a complaint > about an installed file not listed in the list of files (vg_regtest - I > just added it, but that doesn't seem like the right solution). Once I'd > fixed that, it generates an RPM, but it won't install it because it says > there's a dependency on glibc(GLIBC_PRIVATE). I presume it has > something to do with the __pthread_clock_(get|set)time stuff, but I > don't know what the fix is. > > Any ideas? Blech. This is a swamp which I never really understood but managed to kludge a "fix" to a while back. My understanding, which could well be wrong, is as follows. __pthread_clock_gettime and __pthread_clock_settime are syms private to glibc (or is it libpthread), and correct programs shouldn't refer to them. So not exporting them from our libpthread.so is mostly OK. Problem is that some programs do refer to them -- IIRC /lib/librt.so on RH 7.3 sometimes needs them, and so I added the relevant kludges in coregrind/vg_libpthread.vs (linker script) and coregrind/vg_libpthread_unimp.c. Note that these people never actually needed to execute these functions [it seems]. They merely needed some definition of the syms in order that ld.so didn't barf at startup. So far so good. This _finally_ solved the problem for R H 7.3 folks and possible a few others. Meanwhile, Ulrich Drepper et al were (rightly) getting annoyed at people using unofficial interfaces in libc, and so have taken actions to make such private symbols invisible outside libc (or something like that, possibly including making RPM refuse to install libraries containing any such references, as you've seen). So I don't know; perhaps if you get rid of all mentions of those syms in the two abovementioned files, you might get a working arrangement. It would break other people tho. All this total crud is yet another reason why I'd like to rearrange V so that is is a standard C application which does all the ELF loading itself, as briefly discussed a couple of months ago. Then we wouldn't have to play these games. J |
|
From: Julian S. <js...@ac...> - 2002-12-15 00:55:50
|
Running current cvs + 44 + 45: ==25360== Reading syms from /home/apps/Exp/Inst/lib/libkateinterfaces.so valgrind: vg_symtab2.c:706 (canonicaliseScopetab): Assertion `si->scopetab[i].addr < si->scopetab[i+1].addr' failed. This .so is part of KDE-3.1-rc3, built by gcc-2.95.3, fwiw. J |
|
From: Jeremy F. <je...@go...> - 2002-12-15 00:23:35
|
I'm having trouble making RH8.0's buildrpm happy. There was a complaint
about an installed file not listed in the list of files (vg_regtest - I
just added it, but that doesn't seem like the right solution). Once I'd
fixed that, it generates an RPM, but it won't install it because it says
there's a dependency on glibc(GLIBC_PRIVATE). I presume it has
something to do with the __pthread_clock_(get|set)time stuff, but I
don't know what the fix is.
Any ideas?
Also, I think there should be valgrind and valgrind-devel packages, with
the latter containing the valgrind/*.h files.
J
|