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: H. J. L. <hj...@lu...> - 2002-10-18 23:58:17
|
On Fri, Oct 18, 2002 at 04:32:53PM -0700, Jeremy Fitzhardinge wrote: > Hi HJ, > > Oops. I guess lucon.com is dead to you. Let's see if this works. Is lucon.com available? I may switch to that. In the meantime, please email me at hj...@lu... :-). Jeremy, drop me a line if you want to make autofs 4.0. Content-Description: Forwarded message - Overriding glibc functions > Subject: Overriding glibc functions > From: Jeremy Fitzhardinge <je...@go...> > To: hj...@lu... > X-Mailer: Ximian Evolution 1.0.8 > Date: 18 Oct 2002 16:12:56 -0700 > > On Fri, 2002-10-18 at 13:53, Julian Seward wrote: > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgsnd > > 000e76c8 T msgsnd > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgrcv > > 000e771c T msgrcv > > > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgsnd > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgrcv > > > > IOW, msgsnd/msgrcv are exported as strong text symbols from libc, and not > > at all from libpthread. Your patch adds them to valgrind's libpthread.so. > > So any threaded program running on V will have two definitions of > > them to choose from, and it is unclear which it will get. If the libc > > version was defined as a weak symbol, then V's implementation would > > definitely overrride it (and many libc things are indeed exported weakly) > > but that is not the case. > > > > Does that make sense? Is there some other behaviour of the dynamic > > linker which might save the day and avoid this issue? I don't know much > > about ld.so; perhaps you understand more about all this? > > Hm, no, but I know who does. > > Hey, HJ: > > We have the problem that Valgrind's implementation of libpthread.so > needs to intercept various libc functions (in this instance > msgsnd/msgrcv) so it can make sure they only block the thread rather > than the whole process (since Valgrind completely re-implements the > thread library without using kernel threads). The question is which > definition will be picked up when glibc's function definition is not a > weak reference? How can we make sure that our libpthread version is > preferred over the glibc version? > > One thing occurs to me: the main Valgrind shared object, valgrind.so, is > always LD_PRELOADED, and is linked with -Wl,-z -Wl,initfirst. I wonder > if the solution is to put the intercept stub functions in valgrind.so, > and have them call either glibc or libpthread, depending on the context. > There are 2 things you should know: 1. There are supposed to be no differences between weak and strong symbols in DSOs. I submitted a patch to glibc: http://sources.redhat.com/ml/libc-alpha/2001-09/msg00109.html 2. Glibc will make sure libpthread.so will override libc.so, weak or strong. Please file a bug if it doesn't do so. But please make sure your libpthread has: # readelf -d /lib/libpthread.so.0 ... 0x6ffffffb (FLAGS_1) Flags: NODELETE INITFIRST ... by passing "-z nodelete -z initfirst" to ld. H.J. |
|
From: Jeremy F. <je...@go...> - 2002-10-18 23:34:52
|
Here's a small fix for helgrind as it currently stands in CVS head. I've got a number of other changes to improve reporting, but they're still too messy. This is the condensed bugfix patch. J |
|
From: Jeremy F. <je...@go...> - 2002-10-18 23:12:58
|
On Fri, 2002-10-18 at 13:53, Julian Seward wrote: > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgsnd > 000e76c8 T msgsnd > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgrcv > 000e771c T msgrcv > > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgsnd > sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgrcv > > IOW, msgsnd/msgrcv are exported as strong text symbols from libc, and not > at all from libpthread. Your patch adds them to valgrind's libpthread.so. > So any threaded program running on V will have two definitions of > them to choose from, and it is unclear which it will get. If the libc > version was defined as a weak symbol, then V's implementation would > definitely overrride it (and many libc things are indeed exported weakly) > but that is not the case. > > Does that make sense? Is there some other behaviour of the dynamic > linker which might save the day and avoid this issue? I don't know much > about ld.so; perhaps you understand more about all this? Hm, no, but I know who does. Hey, HJ: We have the problem that Valgrind's implementation of libpthread.so needs to intercept various libc functions (in this instance msgsnd/msgrcv) so it can make sure they only block the thread rather than the whole process (since Valgrind completely re-implements the thread library without using kernel threads). The question is which definition will be picked up when glibc's function definition is not a weak reference? How can we make sure that our libpthread version is preferred over the glibc version? One thing occurs to me: the main Valgrind shared object, valgrind.so, is always LD_PRELOADED, and is linked with -Wl,-z -Wl,initfirst. I wonder if the solution is to put the intercept stub functions in valgrind.so, and have them call either glibc or libpthread, depending on the context. Thanks, J |
|
From: Julian S. <js...@ac...> - 2002-10-18 20:46:22
|
> I already put 03-poll-select and 04-lax-ioctls into 1.0.4 and will > merge the result to the head shortly. I considered 02-sysv-msg but > concluded it too risky for the stable branch > > Why? Clearly nobody is using SYSV messaging in threaded programs > because it is currently completely broken. That patch makes it much > better (and might even be problem-free). Ah, I remember now. This is the situation on my R H 7.2 box; YMMV. sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgsnd 000e76c8 T msgsnd sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libc-2.2.4.so | grep msgrcv 000e771c T msgrcv sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgsnd sewardj@phoenix:~/VgHEAD/valgrind$ nm /lib/libpthread-0.9.so | grep msgrcv IOW, msgsnd/msgrcv are exported as strong text symbols from libc, and not at all from libpthread. Your patch adds them to valgrind's libpthread.so. So any threaded program running on V will have two definitions of them to choose from, and it is unclear which it will get. If the libc version was defined as a weak symbol, then V's implementation would definitely overrride it (and many libc things are indeed exported weakly) but that is not the case. Does that make sense? Is there some other behaviour of the dynamic linker which might save the day and avoid this issue? I don't know much about ld.so; perhaps you understand more about all this? > My current plans for it are: > - beef up reporting (starting by stealing chunks of memcheck) > - suppress duplicate errors > - investigate the state of the stack on thread startup > - make the memory granularity a compile-time setting for experiments > - implement the thread lifetime segment stuff (which may help with the > thread stack state problem; not sure yet) > > I hope to make some substantial progress in the next week or so. That's great. You have my encouragement :) J |
|
From: Jeremy F. <je...@go...> - 2002-10-18 18:15:34
|
On Fri, 2002-10-18 at 02:13, Josef Weidendorfer wrote: > I'm not so sure about this. Cachegrind does instrumentation for EVERY original > x86 instruction. > > > The alternative would be to regenerate the code, but I think that would > > be much more expensive. > > Yes. Well, if you really have that much instrumentation it might be cheaper to invalidate the cache and regenerate with instrumentation. Another possibility is to run on the real CPU for a while, and then make a breakpoint trap (or something) drop into the Valgrind virtual machine. No idea how easy that would be to do, but my immediate impression is that it isn't all that hard (though this stuff always has those devil-in-the-details gotchas). J |
|
From: Nicholas N. <nj...@ca...> - 2002-10-18 09:35:09
|
On Fri, 18 Oct 2002, Josef Weidendorfer wrote: > > if (!active) > > return; > > I'm not so sure about this. Cachegrind does instrumentation for EVERY original > x86 instruction. Even the overhead of calling a C function can make a > difference, I suppose. Switching helper functions would be nice, but the C > calling overhead (saving/restoring registers on the stack) is still there. > OK, only benchmarking will help here. It's easy to do -- make the log functions empty, time it, then remove the calls to the log functions, time it again. I've done this before and found the overhead of the C calls alone (argument passing, register saving, etc) to be significant for Cachegrind, eg. something like 20%. C calls have been optimised since then with liveness analysis, the use of ((regparm(n))) attribute, etc, so I would be interested in seeing it re-measured. N |
|
From: Josef W. <Jos...@gm...> - 2002-10-18 09:26:42
|
On Friday 18 October 2002 08:31, Jeremy Fitzhardinge wrote: > On Thu, 2002-10-17 at 13:40, Josef Weidendorfer wrote: > > Reason: When a user want's to profile only a short part of a run, but > > this part is 10 CPU min. from the program start, it would be nice to = go > > on to that place with no tracing at all... > > I know this will kill the cache simulation somehow... but that's the = same > > problem with the traced data at the very beginning of a profile run. > > > > Alternative approach: A new CCALL only jumping to the helper when a f= lag > > is set... > > Well, one option would be to add an API for skins so that they can > change their helper function pointers in the baseblock. That way you > could point it to a simple no-op until you want it to do something. On > the other hand, putting a: > =09if (!active) > =09=09return; > at the top would get the same effect with very little additional > performance hit. I'm not so sure about this. Cachegrind does instrumentation for EVERY ori= ginal x86 instruction. Even the overhead of calling a C function can make a=20 difference, I suppose. Switching helper functions would be nice, but the = C=20 calling overhead (saving/restoring registers on the stack) is still there= =2E OK, only benchmarking will help here. > The alternative would be to regenerate the code, but I think that would > be much more expensive. Yes. Josef |
|
From: Jeremy F. <je...@go...> - 2002-10-18 06:31:00
|
On Thu, 2002-10-17 at 13:40, Josef Weidendorfer wrote: > Reason: When a user want's to profile only a short part of a run, but this > part is 10 CPU min. from the program start, it would be nice to go on to that > place with no tracing at all... > I know this will kill the cache simulation somehow... but that's the same > problem with the traced data at the very beginning of a profile run. > > Alternative approach: A new CCALL only jumping to the helper when a flag is > set... Well, one option would be to add an API for skins so that they can change their helper function pointers in the baseblock. That way you could point it to a simple no-op until you want it to do something. On the other hand, putting a: if (!active) return; at the top would get the same effect with very little additional performance hit. The alternative would be to regenerate the code, but I think that would be much more expensive. J |
|
From: Jeremy F. <je...@go...> - 2002-10-18 01:54:52
|
On Thu, 2002-10-17 at 16:47, Julian Seward wrote:
I haven't said much lately -- been v. busy having started a new job.
But thanks for your hacking (lest you think I don't appreciate it).
Some of this stuff may well diffuse into the code base when we have
time to do so.
Good. I was going to start pushing the smaller patches to you in chunks
to encourage merging.
I've been updating them as the CVS tree changes; the current snapshot is
always at http://www.goop.org/~jeremy/valgrind (its a couple of days
behind at the moment, but nothing major has happened since then).
I already put 03-poll-select and 04-lax-ioctls into 1.0.4 and will
merge the result to the head shortly. I considered 02-sysv-msg but
concluded it too risky for the stable branch
Why? Clearly nobody is using SYSV messaging in threaded programs
because it is currently completely broken. That patch makes it much
better (and might even be problem-free).
I'm also working on a patch to deal with open() blocking in the open of
a FIFO file. It is very ugly (attached for your amusement).
; I'll put it in the head.
That's fine.
I think 05 is already in the head (N put it in). I've looked at 00
and 01 and they seem possibilities for the head too.
I've been running them for a while without any problems (though I think
wider testing would do them good).
What does 06 do? I haven't heard talk of it.
They're just dead simple implementations of VG_(memset) and VG_(memcpy)
for vg_mylibc.c because I was missing them.
I also think vgprof is useful enough to put into the source as well.
There's the slight complexity of needing a modified gprof program to
interpret the results, but I'm looking into how to get my changes back
into binutils (or simply use kcachegrind as the display tool).
I'd like to branch off a 1.2.X (stable) branch from the head in the
near future (< 1 month, possibly less than that). It would be nice
to ship a half-decent Helgrind (race detector) in that, but I'm not
sure what the prospects for this are; do you have any views on that?
Not sure yet. I've been hacking on it a fair bit, but nothing I want to
show off yet. Mostly I've been working on making the reports more
useful so it is easier to tell what's real, what's noise and what's
completely spurious. At the moment the _dl_num_relocations update is
the most obvious source of noise; I think I'm getting spurious stuff
caused by thread stacks being in a strange state when they start up, but
I haven't confirmed that yet.
My current plans for it are:
- beef up reporting (starting by stealing chunks of memcheck)
- suppress duplicate errors
- investigate the state of the stack on thread startup
- make the memory granularity a compile-time setting for experiments
- implement the thread lifetime segment stuff (which may help with the
thread stack state problem; not sure yet)
I hope to make some substantial progress in the next week or so.
J
|