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
|
|
3
|
4
|
5
(2) |
6
(3) |
7
|
8
(2) |
9
(3) |
|
10
(3) |
11
(5) |
12
(1) |
13
|
14
(21) |
15
(6) |
16
(4) |
|
17
(9) |
18
(13) |
19
(15) |
20
(15) |
21
(11) |
22
(16) |
23
(4) |
|
24
|
25
(8) |
26
(4) |
27
(3) |
28
(1) |
29
|
30
(2) |
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 23:27:26
|
Hi, I committed a large change earlier today which affects all skins. Basically, I removed all exposed structs (except one, UInstr) from the interface, and replaced them with get/set functions. This affects details, needs, tracked events, errors suppressions, and some other bits and pieces. In short, Jeremy and Josef, you will have to update your VGProf and Cachegrind skins (as will any lurkers out there writing other skins and not telling us about them :). I changed all the "official" skins (inc. Helgrind) in the repository myself, though. Hopefully the changes will be pretty straightforward. Let me know if you have any problems. Apologies for forcing this on you, but hopefully changes like this won't happen again -- the interface is (hopefully) much better future-proofed now. N |
|
From: Jeremy F. <je...@go...> - 2002-11-14 23:19:57
|
On Thu, 2002-11-14 at 15:00, Robert Walsh wrote:
> > For vgprof, I added a
> > Long VG_(get_tsc_ticks_per_millisecond)(void)
> > to core, and then used the tsc for measuring time.
>
> How do you convert tsc -> microseconds?
Valgrind calibrates the tsc against gettimeofday at startup.
J
|
|
From: Robert W. <rj...@s8...> - 2002-11-14 23:00:43
|
> For vgprof, I added a > Long VG_(get_tsc_ticks_per_millisecond)(void) > to core, and then used the tsc for measuring time. How do you convert tsc -> microseconds? Regards, Robert. |
|
From: Jeremy F. <je...@go...> - 2002-11-14 22:52:38
|
On Thu, 2002-11-14 at 10:22, Josef Weidendorfer wrote:
> Hi,
>
> how can I get the wall clock time spent in system calls in Valgrind 2.x?
> Instrumenting around a syscall and calling gettimeofday in according helpers?
>
> Nick: What do you think of adding a new event type "Time spent in a system
> call" for instructions doing a system call?
>
> I got a wish item to allow for meassuring time for system calls in
> cachegrind...
> Is this idea feasable?
>
> With the MHz of the processor, we could estimate cycles for the system calls
> to relate it to the syntetic cycle estimation (all to be done in
> KCachegrind).
>
> Or does anybody have a better idea?
For vgprof, I added a
Long VG_(get_tsc_ticks_per_millisecond)(void)
to core, and then used the tsc for measuring time. I also exported
VG_(read_millisecond_timer)(), since it seemed to be a useful thing to
have around (though far too coarse for the sorts of timescale you're
talking about).
It doesn't help you directly with mesuring system calls, but you can see
all the syscalls in your instrument pass because they look like a JMP
with jmpkind=JmpSyscall.
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 22:20:53
|
On Thu, 14 Nov 2002, Josef Weidendorfer wrote: > how can I get the wall clock time spent in system calls in Valgrind 2.x? > Instrumenting around a syscall and calling gettimeofday in according helpers? Sounds reasonable. How accurate is gettimeofday? I don't know much about measuring times in programs, other than it's a lot harder and less accurate than you'd first expect. > Nick: What do you think of adding a new event type "Time spent in a system > call" for instructions doing a system call? Do you mean have a new event in VgTrackEvents, eg. void (*sys_call_time)(UInt milliseconds); ? I'm not sure what you mean by "instructions doing a system call". I think your idea of embedding calls to gettimeofday or similar timing functions in the system call wrappers is better -- I don't want to add something to core that could be done easily in a skin. I think the cost of calling the syscall wrapper functions should be negligible compared to the granularity of gettimeofday. N |
|
From: Josef W. <Jos...@gm...> - 2002-11-14 18:50:45
|
Hi, how can I get the wall clock time spent in system calls in Valgrind 2.x? Instrumenting around a syscall and calling gettimeofday in according help= ers? Nick: What do you think of adding a new event type "Time spent in a syste= m=20 call" for instructions doing a system call? I got a wish item to allow for meassuring time for system calls in=20 cachegrind... Is this idea feasable? With the MHz of the processor, we could estimate cycles for the system ca= lls=20 to relate it to the syntetic cycle estimation (all to be done in=20 KCachegrind). Or does anybody have a better idea? Josef |
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 18:24:37
|
On 14 Nov 2002, Jeremy Fitzhardinge wrote: > Yes, but the patch is: > > +#ifndef NVALGRIND > > ----> Generate the client request magic sequence. > > +#else /* NVALGRIND */ > > ----> Don't generate the client request magic sequence, just make > the result the default return value. Bleh, I should learn how to read diffs. > To match this, your rearrangement should be: > > if (NVALGRIND) > no client requests > else > use client requests > > Which is what we want, right? Yes. Sorry for the confusion. N |
|
From: Jeremy F. <je...@go...> - 2002-11-14 18:19:04
|
On Thu, 2002-11-14 at 10:10, Nicholas Nethercote wrote:
> On 14 Nov 2002, Jeremy Fitzhardinge wrote:
>
> > No, it says
> >
> > #if*n*def NVALGRIND
>
> I know. In my simplification, I removed the double negative because it is
> confusing, and swapped the order of the two branches.
Yes, but the patch is:
+#ifndef NVALGRIND
----> Generate the client request magic sequence.
/* This defines the magic code sequence which the JITter spots and
handles magically. Don't look too closely at this; it will rot
your brain. Valgrind dumps the result value in %EDX, so we first
@@ -111,7 +112,22 @@
: "eax", "edx", "cc", "memory" \
); \
}
-
+#else /* NVALGRIND */
----> Don't generate the client request magic sequence, just make
the result the default return value.
+/* Define NVALGRIND to completely remove the Valgrind magic sequence
+ from the compiled code (analogous to NDEBUG's effects on
+ assert()) */
+#define VALGRIND_MAGIC_SEQUENCE( \
+ _zzq_rlval, /* result lvalue */ \
+ _zzq_default, /* result returned when running on real CPU */ \
+ _zzq_request, /* request code */ \
+ _zzq_arg1, /* request first param */ \
+ _zzq_arg2, /* request second param */ \
+ _zzq_arg3, /* request third param */ \
+ _zzq_arg4 /* request fourth param */ ) \
+ { \
+ (_zzq_rlval) = (_zzq_default); \
+ }
+#endif /* NVALGRIND */
To match this, your rearrangement should be:
if (NVALGRIND)
no client requests
else
use client requests
Which is what we want, right?
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 18:10:18
|
On 14 Nov 2002, Jeremy Fitzhardinge wrote: > No, it says > > #if*n*def NVALGRIND I know. In my simplification, I removed the double negative because it is confusing, and swapped the order of the two branches. N |
|
From: Jeremy F. <je...@go...> - 2002-11-14 18:02:23
|
On Thu, 2002-11-14 at 09:48, Nicholas Nethercote wrote:
> Ok, so does this mean the new behaviour (no error to suppress) is more
> correct, and thus I should update the reg tests?
Yes.
J
|
|
From: Jeremy F. <je...@go...> - 2002-11-14 18:01:49
|
On Thu, 2002-11-14 at 09:47, Nicholas Nethercote wrote:
> On 14 Nov 2002, Jeremy Fitzhardinge wrote:
>
> > Look more closely - it's a double negative:
>
> I know:
>
> if (NVALGRIND)
No, it says
#if*n*def NVALGRIND
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 17:48:49
|
On 14 Nov 2002, Jeremy Fitzhardinge wrote: > > pthread_mutex_unlock: mutex is not locked > > at 0x40116BBA: __pthread_mutex_unlock (vg_libpthread.c:934) > > by 0x4024B7E5: __register_frame_info (in /lib/libc-2.2.4.so) > > by 0x40115921: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so) > > by 0x401157B4: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so) > > Yes, that was a suppression hiding a vg_libpthread bug. Basically it's > an issue with the dynamic linker wanting to use pthreads in a > prehistoric (ie, before V is loaded) context. The old > pthread_mutex_lock/unlock code would leave the mutex in a garbage state, > which made subsequent uses of the mutex (once Valgrind was running) look > like an error. > > I made the non-Valgrind lock code keep the mutex structure in a > consistent state. Of course it does no locking; I'm assuming that > ld-linux.so doesn't actually want to create new threads before V has > started. I also added a mechanism to cope with the case of a lock being > taken before V starts, and then being released afterwards. I don't think > this has been exercised (fortunately). Ok, so does this mean the new behaviour (no error to suppress) is more correct, and thus I should update the reg tests? N |
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 17:47:26
|
On 14 Nov 2002, Jeremy Fitzhardinge wrote:
> Look more closely - it's a double negative:
I know:
if (NVALGRIND)
use client requests
else
no client requests
Compare with NDEBUG:
if (NDEBUG)
no assertions
else
use assertions
The logic of the two are opposite to each other.
I think that client requests should be on by default, but that you can
disable them by defining NVALGRIND. Ie. NVALGRIND == "no client
requests".
N
|
|
From: Jeremy F. <je...@go...> - 2002-11-14 17:47:04
|
On Thu, 2002-11-14 at 05:22, Nicholas Nethercote wrote:
> Hi,
>
> I just found that the pthread regression tests in
> valgrind/corecheck/tests/ are failing. Problem IS that previously there
> was at one error occurring and being suppressed for every pthreaded
> program.
>
> But now this error has disappeared. I'm guessing it was caused by
> Julian's merging of all Jeremy's patches yesterday, because I didn't have
> this problem a couple of days ago. There were some changes to
> vg_scheduler.c amongst the patches that might be causing the problem.
>
> The error that was being suppressed looks like this:
>
> pthread_mutex_unlock: mutex is not locked
> at 0x40116BBA: __pthread_mutex_unlock (vg_libpthread.c:934)
> by 0x4024B7E5: __register_frame_info (in /lib/libc-2.2.4.so)
> by 0x40115921: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so)
> by 0x401157B4: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so)
>
> Which I was able to determine using an old version and turning off the
> suppressions.
>
> This error is detected in vg_scheduler.c around line 2526. I can't see
> any recent changes in the immediate vicinity of that file, so I'm not sure
> what the problem is. Julian and/or Jeremy, would one of you mind having a
> look into this to figure out what has changed?
Yes, that was a suppression hiding a vg_libpthread bug. Basically it's
an issue with the dynamic linker wanting to use pthreads in a
prehistoric (ie, before V is loaded) context. The old
pthread_mutex_lock/unlock code would leave the mutex in a garbage state,
which made subsequent uses of the mutex (once Valgrind was running) look
like an error.
I made the non-Valgrind lock code keep the mutex structure in a
consistent state. Of course it does no locking; I'm assuming that
ld-linux.so doesn't actually want to create new threads before V has
started. I also added a mechanism to cope with the case of a lock being
taken before V starts, and then being released afterwards. I don't think
this has been exercised (fortunately).
> Also, can I gently suggest running the regression tests before committing
> in the future? It's very easy, just do
>
> $prefix/bin/vg_regtest --all
Hm, I'd been meaning to work out what all those tests were for...
J
|
|
From: Jeremy F. <je...@go...> - 2002-11-14 17:38:04
|
On Thu, 2002-11-14 at 01:36, Nicholas Nethercote wrote:
> One question: as implemented by the patch, is NVALGRIND really analogous
> to NDEBUG? AIUI, assertions are on by default, but if you #define NDEBUG
> they get turned off.
>
> Patch 27 looks to me like the behaviour is the opposite -- client requests
> are off by default but get turned on if you #define NVALGRIND.
> Should the #ifndef be a #ifdef?
Look more closely - it's a double negative:
+#ifndef NVALGRIND
If not not valgrind...
/* This defines the magic code sequence which the JITter spots and
handles magically. Don't look too closely at this; it will rot
your brain. Valgrind dumps the result value in %EDX, so we first
@@ -111,7 +112,22 @@
: "eax", "edx", "cc", "memory" \
); \
}
-
+#else /* NVALGRIND */
otherwise is not valgrind...
+/* Define NVALGRIND to completely remove the Valgrind magic sequence
+ from the compiled code (analogous to NDEBUG's effects on
+ assert()) */
+#define VALGRIND_MAGIC_SEQUENCE( \
+ _zzq_rlval, /* result lvalue */ \
+ _zzq_default, /* result returned when running on real CPU */ \
+ _zzq_request, /* request code */ \
+ _zzq_arg1, /* request first param */ \
+ _zzq_arg2, /* request second param */ \
+ _zzq_arg3, /* request third param */ \
+ _zzq_arg4 /* request fourth param */ ) \
+ { \
+ (_zzq_rlval) = (_zzq_default); \
+ }
+#endif /* NVALGRIND */
J
|
|
From: Jeremy F. <je...@go...> - 2002-11-14 17:16:14
|
On Thu, 2002-11-14 at 00:40, Julian Seward wrote:
> > Any ideas on how to work out if the current code has been compiled with
> > -fomit-frame-pointer? I guess the safe way is to generate a runtime
> > check per basic block which sees if EBP is near ESP. Not really keen on
> > that.
>
> On contemplation ...
>
> The only surefire way to know if something is a stack reference is that
> it falls within the bounds of the stack. What you are trying to do is
> first assume that ESP always points at the stack (reasonable enough), and
> then do a translation-time analysis to detect which refs are of the form
> ESP + small offset.
>
> My inclination with this is to either scrap it, or reduce the ambitiousness
> of the analysis to catch just the case ESP + small offset and nothing else.
> I'm not convinced that anything correct can be done viz EBP offsets, and it
> would be a bummer to cause Helgrind to miss non-stack offsets due to some
> mistake here.
>
> Could you look into this? I prefer correctness over performance :)
Well, the whole idea is performance over correctness; I implemented
because the Eraser paper said they ignored stack refs, and I wanted to
see what it bought them. There's no real reason to assume that a stack
is private, and even if the stack references were all accurately
identified, it would still miss some racy accesses. (For example: thread
A is working happily in its stack, and then passes a reference to B; B
uses the reference, and those accesses will be checked; A then racily
uses the same memory, but those accesses aren't checked. The error will
still be most likely be reported after B's accesses.)
The upside is that the 70% static (haven't measured dynamic) reduction
in access checks means that those checks can be more thorough, such as
with the --show-last-access stuff.
I agree with you in general about correctness over performance, but if
the program under test runs too slowly, then people just won't use V,
which has a lot worse correctness than these shortcuts. I'm wondering
what we can do about performance in general, actually.
I say if you're really worried about it, just make the option default to
off (it defaults to on now).
> > I also need to work out whether a given piece of code is compiled with
> > -fomit-frame-pointer to interpret the stab info on where a variable is
> > living. I think.
>
> You sure? That sounds a bit strange. If so, how does GDB manage it?
Not sure. I tried to find that bit the other day, but got lost.
The trouble is that stack and parameter stabs only contain an offset,
but they don't say what the offset is relative to. For locals its OK,
because if its a +ve offset it is off ESP, but if its -ve its off EBP.
However, parameter references are always +ve, but are off EBP when
there's a frame pointer and off ESP when there isn't. Unless I'm just
misunderstanding something.
> Um, is it too late to persuade you to make your initial implementation
> DWARF2 rather than stabs based, so as to avoid having to port it later
> from a format which is basically dead anyway? You mentioned, or implied,
> a few days back, that most of the work was format-independent, and so
> porting it to dwarf would not be a big deal. Is that still the case?
> Bear in mind also that even if it's not a big deal, anyone else who comes
> to do the port to dwarf2 will have to spend considerable time paging into
> their brain all the aspects of the problem which are already paged into
> your brain. This is also why I was hoping you'd work with dwarf from the
> outset ...
Well, I disagree with you that stabs are dead. V is going to have to
support them almost forever, regardless of whether most compilers
generate DWARF2. More particularly, everything on my system is
currently stabs, and I had the stabs documentation, but not DWARF2.
There isn't very much in the way of wasted effort. The debug info
parser needs to extract all the scope ranges, all the variables in each
of those scopes, and generate enough of a type description of those
variables to be able to see structures, arrays and pointers. Scopes,
scope ranges, variables and types are all represented in a generic
fashion, so its simply a matter of making something to traverse the
DWARF2 debugging info to generate the same information.
Most of my effort of the last few days has been in actually chewing
through the strings of goo that make up a stabs type definition; that
would have had to happen anyway, given that we need to keep supporting
stabs, but it shouldn't have any bearing on making DWARF2 work.
J
|
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 13:22:27
|
Hi, I just found that the pthread regression tests in valgrind/corecheck/tests/ are failing. Problem IS that previously there was at one error occurring and being suppressed for every pthreaded program. But now this error has disappeared. I'm guessing it was caused by Julian's merging of all Jeremy's patches yesterday, because I didn't have this problem a couple of days ago. There were some changes to vg_scheduler.c amongst the patches that might be causing the problem. The error that was being suppressed looks like this: pthread_mutex_unlock: mutex is not locked at 0x40116BBA: __pthread_mutex_unlock (vg_libpthread.c:934) by 0x4024B7E5: __register_frame_info (in /lib/libc-2.2.4.so) by 0x40115921: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so) by 0x401157B4: (within /local/scratch-2/njn25/local/src/grind/head2/inst/lib/valgrind/libpthread.so) Which I was able to determine using an old version and turning off the suppressions. This error is detected in vg_scheduler.c around line 2526. I can't see any recent changes in the immediate vicinity of that file, so I'm not sure what the problem is. Julian and/or Jeremy, would one of you mind having a look into this to figure out what has changed? Also, can I gently suggest running the regression tests before committing in the future? It's very easy, just do $prefix/bin/vg_regtest --all in valgrind/ and then look at the mentioned .diff files if any of them fail (memcheck/tests/tronical is the only one which is expected to fail). Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2002-11-14 09:36:56
|
On Thu, 14 Nov 2002, Julian Seward wrote: > > > - 27-nvalgrind -- is this really actually needed? Do you have some > > > performance numbers indicating, when running natively, that the 12-insn > > > sequence really causes significant performance loss? > > > > I doubt there's a good technical justification for it, but when trying > > to convince people to use Valgrind, I've found it most useful to be able > > to say "you can compile out all the Valgrind annotations for production > > builds". It's just one less argument for people to make. And when > > describing the client callback mechanism to people, they invariably ask > > whether the callbacks can be compiled out within about 1 to 2 > > milliseconds. > > Yes, I thought I was being a bit churlish not merging this. I'll merge > it (not right now, but later). One question: as implemented by the patch, is NVALGRIND really analogous to NDEBUG? AIUI, assertions are on by default, but if you #define NDEBUG they get turned off. Patch 27 looks to me like the behaviour is the opposite -- client requests are off by default but get turned on if you #define NVALGRIND. Should the #ifndef be a #ifdef? A general note: I think this patch is a good thing. At a research group talk I gave about Valgrind one person seemed upset by the potential performance effects of the magic sequence; "it could be in an inner loop!" he cried, more or less. People are very touchy about these things, as Jeremy said it's one less argument people can make. N |
|
From: Julian S. <js...@ac...> - 2002-11-14 08:33:42
|
> > - 03a-open-nonblock I merged, even though am not entirely happy about. > > Is it sufficiently robust to not cause problems later? > > I'm least happy about this one, but I can't think of a better simple > solution, and it does fix a real observed problem. A more correct > solution (from the kernel's perspective) would be to fire off a clone > thread to do blocking syscalls in, so that we can get exactly the right > semantics. I have no idea how to make the rest of V happy with this > though. Well, let's leave it as it is for now. Generally what I'd like to do is for everybody to commit the changes they want to, then fall into a feature-freeze stabilisation period in which we shake out the inevitable oddities that have appeared. > > - 27-nvalgrind -- is this really actually needed? Do you have some > > performance numbers indicating, when running natively, that the 12-insn > > sequence really causes significant performance loss? > > I doubt there's a good technical justification for it, but when trying > to convince people to use Valgrind, I've found it most useful to be able > to say "you can compile out all the Valgrind annotations for production > builds". It's just one less argument for people to make. And when > describing the client callback mechanism to people, they invariably ask > whether the callbacks can be compiled out within about 1 to 2 > milliseconds. Yes, I thought I was being a bit churlish not merging this. I'll merge it (not right now, but later). > > - 28-sigtrap -- didn't merge because I'm paranoid about breaking the > > already fragile signal simulation stuff. Am not per se opposed to it, > > but it's too late at night to sanity check this one in detail. > > It doesn't seem quite right. It doesn't break any existing correct > behaviour, but it doesn't always print the right error message on a > crash. Still need to look at it. Am still paranoid :-) > > - 37-hg-private-stack: at first was concerned about not checking %EBP > > relative references since %EBP is a general reg when > > -fomit-frame-pointer. However I see that you have some mini-dataflow > > analysis to get round this problem (I think?) Can you just confirm that > > it all makes sense even if -fomit-frame-pointer ? > > Hm, looking at the code, it doesn't quite get it right - it always > assumes EBP is a stack reference. This is hard to fix. The dataflow > stuff looks within a basic block to work out what temps are holding > addresses derived from a stack reference (ie, ESP or EBP), so it can > work out whether to suppress the check generation. > > Of course, I'm not doing any global dataflow analysis, so I can't tell > if any of the archregs are holding stack addresses, so I just assume > that ESP and EBP always do, and the rest don't. > > Any ideas on how to work out if the current code has been compiled with > -fomit-frame-pointer? I guess the safe way is to generate a runtime > check per basic block which sees if EBP is near ESP. Not really keen on > that. On contemplation ... The only surefire way to know if something is a stack reference is that it falls within the bounds of the stack. What you are trying to do is first assume that ESP always points at the stack (reasonable enough), and then do a translation-time analysis to detect which refs are of the form ESP + small offset. My inclination with this is to either scrap it, or reduce the ambitiousness of the analysis to catch just the case ESP + small offset and nothing else. I'm not convinced that anything correct can be done viz EBP offsets, and it would be a bummer to cause Helgrind to miss non-stack offsets due to some mistake here. Could you look into this? I prefer correctness over performance :) > I also need to work out whether a given piece of code is compiled with > -fomit-frame-pointer to interpret the stab info on where a variable is > living. I think. You sure? That sounds a bit strange. If so, how does GDB manage it? > > > I think that's all for now. How's it going with the fancy symbol reader? > > Well, I've got the stab type parser chewing through all the shared > libraries I've tested it on now, so its time to actually use all that > information. I'm hoping to get it going in the next few days, and maybe > convince someone else to write the DWARF2 parser... Um, is it too late to persuade you to make your initial implementation DWARF2 rather than stabs based, so as to avoid having to port it later from a format which is basically dead anyway? You mentioned, or implied, a few days back, that most of the work was format-independent, and so porting it to dwarf would not be a big deal. Is that still the case? Bear in mind also that even if it's not a big deal, anyone else who comes to do the port to dwarf2 will have to spend considerable time paging into their brain all the aspects of the problem which are already paged into your brain. This is also why I was hoping you'd work with dwarf from the outset ... J |
|
From: Jeremy F. <je...@go...> - 2002-11-14 01:20:55
|
On Wed, 2002-11-13 at 16:57, Jeremy Fitzhardinge wrote: > Thanks for that. I'll sync up now. OK, all synced. One new patch: nonblocking readv/writev. Not properly tested (but very simple). J |
|
From: Jeremy F. <je...@go...> - 2002-11-14 00:58:03
|
On Wed, 2002-11-13 at 15:26, Julian Seward wrote: > Hi Jeremy (also Nick :) -- see analysis, questions below, esp 41-linefix) > > Ok, have merged bazillions of patches in, specifically: > > 20-hg-lockgraph-report > 21-hg-hashed-lockset > 03a-open-nonblock > 22-mutex-destroy-unlock > 23-intercept-select-poll > 24-sym-offset > 25-hg-free-mutex > 26-hg-client-reqs > 29-hg-rename-hg_mutex_t > 30-hg-clo > 31-hg-shadow-execontext > 32-hg-lifetime-segments > 33-pre_mutex_lock > 36-hg-optim > 37-hg-private-stack > 38-hg-lazy-lasttouch > 39-lock-prefix > 40-hg-tidstate > 42-hg-show-all-locks > > Thank you for what is evidently a large amount of work. Thanks for that. I'll sync up now. > Analysis, questions: > > - 03a-open-nonblock I merged, even though am not entirely happy about. > Is it sufficiently robust to not cause problems later? I'm least happy about this one, but I can't think of a better simple solution, and it does fix a real observed problem. A more correct solution (from the kernel's perspective) would be to fire off a clone thread to do blocking syscalls in, so that we can get exactly the right semantics. I have no idea how to make the rest of V happy with this though. > - 27-nvalgrind -- is this really actually needed? Do you have some > performance numbers indicating, when running natively, that the 12-insn > sequence really causes significant performance loss? I doubt there's a good technical justification for it, but when trying to convince people to use Valgrind, I've found it most useful to be able to say "you can compile out all the Valgrind annotations for production builds". It's just one less argument for people to make. And when describing the client callback mechanism to people, they invariably ask whether the callbacks can be compiled out within about 1 to 2 milliseconds. > - 28-sigtrap -- didn't merge because I'm paranoid about breaking the > already fragile signal simulation stuff. Am not per se opposed to it, > but it's too late at night to sanity check this one in detail. It doesn't seem quite right. It doesn't break any existing correct behaviour, but it doesn't always print the right error message on a crash. > - 37-hg-private-stack: at first was concerned about not checking %EBP > relative references since %EBP is a general reg when -fomit-frame-pointer. > However I see that you have some mini-dataflow analysis to get round > this problem (I think?) Can you just confirm that it all makes sense > even if -fomit-frame-pointer ? Hm, looking at the code, it doesn't quite get it right - it always assumes EBP is a stack reference. This is hard to fix. The dataflow stuff looks within a basic block to work out what temps are holding addresses derived from a stack reference (ie, ESP or EBP), so it can work out whether to suppress the check generation. Of course, I'm not doing any global dataflow analysis, so I can't tell if any of the archregs are holding stack addresses, so I just assume that ESP and EBP always do, and the rest don't. Any ideas on how to work out if the current code has been compiled with -fomit-frame-pointer? I guess the safe way is to generate a runtime check per basic block which sees if EBP is near ESP. Not really keen on that. I also need to work out whether a given piece of code is compiled with -fomit-frame-pointer to interpret the stab info on where a variable is living. I think. > I think that's all for now. How's it going with the fancy symbol reader? Well, I've got the stab type parser chewing through all the shared libraries I've tested it on now, so its time to actually use all that information. I'm hoping to get it going in the next few days, and maybe convince someone else to write the DWARF2 parser... J |