You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(3) |
2
(3) |
3
(20) |
4
(2) |
5
(4) |
|
6
(7) |
7
(5) |
8
(3) |
9
(4) |
10
(8) |
11
(1) |
12
|
|
13
(10) |
14
(7) |
15
(1) |
16
(10) |
17
(15) |
18
(3) |
19
(4) |
|
20
(4) |
21
(8) |
22
(4) |
23
(3) |
24
(12) |
25
(9) |
26
(2) |
|
27
(4) |
28
(31) |
29
(1) |
30
|
31
(13) |
|
|
|
From: Joerg B. <jo...@we...> - 2003-07-28 09:35:11
|
Nicholas Nethercote wrote: > On Mon, 28 Jul 2003, Joerg Beyer wrote: > > >>I am aware that valgrind (with the calltree skin) counts >>the processor instructions, used to run some code. Is there >>also a way to count the CPU cycles? > > > No. > would it be good to have such a cycle counter? >>valgrind is a cool tool to do optimizations on the source >>(you could even do challenges: "you finds the fastest variant >>of this piece of code ?"). Now somebody tells me, that counting >>the instructions might be wrong, because not all instructions >>take the same amount of cycles. I assume, that this is right, >>but irrelevant from a practical point of view. > > > On the contrary, it's extremely relevant from a practical point of view. > It's almost impossible to know how long any one instruction will take. > For example, on my machine, a memory read takes 1 cycle if it hits the L1 > cache, 10 cycles in the worst case if it only hits the L2 cache, and 206 > cycles in the worst case if it misses both caches. But out-of-order > execution and all the other fancy modern CPU mumbo-jumbo means that these > delays are rarely as bad as the worst case. Then throw in branch > mispredictions, and other pipeline stalls... it's a mess. > > N OK, so an implementation to do cycle counting needs to have a table that lists for every instruction how many cycles it need for the different cache-hit/miss situations. Are these informations available (for all the processors)? Joerg |
|
From: Nicholas N. <nj...@ca...> - 2003-07-28 09:22:30
|
On Mon, 28 Jul 2003, Joerg Beyer wrote: > I am aware that valgrind (with the calltree skin) counts > the processor instructions, used to run some code. Is there > also a way to count the CPU cycles? No. > valgrind is a cool tool to do optimizations on the source > (you could even do challenges: "you finds the fastest variant > of this piece of code ?"). Now somebody tells me, that counting > the instructions might be wrong, because not all instructions > take the same amount of cycles. I assume, that this is right, > but irrelevant from a practical point of view. On the contrary, it's extremely relevant from a practical point of view. It's almost impossible to know how long any one instruction will take. For example, on my machine, a memory read takes 1 cycle if it hits the L1 cache, 10 cycles in the worst case if it only hits the L2 cache, and 206 cycles in the worst case if it misses both caches. But out-of-order execution and all the other fancy modern CPU mumbo-jumbo means that these delays are rarely as bad as the worst case. Then throw in branch mispredictions, and other pipeline stalls... it's a mess. N |
|
From: Tom H. <th...@cy...> - 2003-07-28 09:18:32
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> > > Is there an option to let Valgrind complain is a program screws up things
> > > in a .data or .rosection part of a program ?
> >
> > Well it can't complain about writes to things in .data as that is
> > intended to be writable - it includes things like static variables
> > that the program is fully entitled to change.
>
> True, but the issue seems more complicated when dealing with threads.
> Something I did was definetely causing heap / stack corruption, and caused
> 1000 false reports.
I don't see why it should be more complicated when threads are bought
into the picture. The .data section is program global data and is
writable because it contains those variables which are defined at
file scope (either static or extern) and which are initialised
(uninitialised ones will be in .bss instead). As a result valgrind
can't mark it as uninitialised or unaddressable for the simple reason
that it isn't.
The simple fact is that whilst valgrind is very good it isn't
completely omniscient and there are some ways in which you can
corrupt things that it won't be able to detect.
> > As for .rodata that would normally be mapped as read only by the
> > operating system and hence would cause a SEGV if you wrote to it even
> > without valgrind. The same goes for any section in an ELF file that
> > has the READONLY attribute set.
>
> That doesn't seem the case, at least not in real-life practice.
Well it is here. Try writing a program that writes to a string
constant for example - something like this:
int main( int argc, char **argv )
{
char *x = "abcd";
x[0] = 'g';
exit( 0 );
}
That string constant will be put in the .rodata section, at least
if you are using gcc and don't specify -fwritable-strings when you
compile. It will also segfault when it hits the assignment.
If you think writes to a read-only section aren't segfaulting then
you should check the output of "objdump -h" to make sure the section
really is marked as read-only.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joerg B. <jo...@we...> - 2003-07-28 09:11:43
|
Dear List, I am aware that valgrind (with the calltree skin) counts the processor instructions, used to run some code. Is there also a way to count the CPU cycles? valgrind is a cool tool to do optimizations on the source (you could even do challenges: "you finds the fastest variant of this piece of code ?"). Now somebody tells me, that counting the instructions might be wrong, because not all instructions take the same amount of cycles. I assume, that this is right, but irrelevant from a practical point of view. Joerg |
|
From: Igmar P. <mai...@jd...> - 2003-07-28 09:01:59
|
> > Is there an option to let Valgrind complain is a program screws up things > > in a .data or .rosection part of a program ? > > Well it can't complain about writes to things in .data as that is > intended to be writable - it includes things like static variables > that the program is fully entitled to change. True, but the issue seems more complicated when dealing with threads. Something I did was definetely causing heap / stack corruption, and caused > 1000 false reports. > As for .rodata that would normally be mapped as read only by the > operating system and hence would cause a SEGV if you wrote to it even > without valgrind. The same goes for any section in an ELF file that > has the READONLY attribute set. That doesn't seem the case, at least not in real-life practice. Igmar |
|
From: Geoff A. <gal...@nc...> - 2003-07-28 02:42:26
|
----- Original Message -----
From: "Nicholas Nethercote" <nj...@ca...>
> No... the compiler looks like it's complaining about not knowing the
> "struct timeval" type. This is defined in bits/time.h, which is #included
> in vg_intercept.c via sys/time.h, like so:
>
> #ifdef GLIBC_2_1
> #include <sys/time.h>
> #endif
Thanks for the response. Removing the #ifdef GLIBC_2_1 fixed the problem.
SuSE 7.1 uses glibc 2.2. The config.h for valgrind properly sets GLIBC_2_2:
/* Define to 1 if you're using glibc 2.1.x */
/* #undef GLIBC_2_1 */
/* Define to 1 if you're using glibc 2.2.x */
#define GLIBC_2_2 1
/* Define to 1 if you're using glibc 2.3.x */
/* #undef GLIBC_2_3 */
The POSIX standard states that struct timeval is defined in sys/time.h
(http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/time.h.html), so
don't understand why vg_intercept.c wraps the include of sys/time.h with
#ifdef GLIBC_2_1. Doesn't sys/time.h need to be included on glibc 2.2 and
2.3 systems as well as glibc 2.1 systems? Is this a bug? If not, where is
vg_intercept.c suppose to get struct timeval on glibc 2.2 and 2.3 systems?
Thanks,
Geoff Alexander
|