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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: John R.
|
> Lucky for us, so does the x86. There is a flag you can set in some > register or other which makes the CPU trap on unaligned access. So long > as we don't do it internally, you could set that and watch all the > unaligned accesses in your program (even without Valgrind). Yes, it's the AC [Alignment Check] bit of the processor flags, which is bit 18 (the bit with positional value (1<<18) or 0x40000). It checks for unaligned access in user mode. $ cat foo.S _start: .globl _start pushf orl $1<<18,(%esp) popf movl 1(%esp),%eax nop $ gcc -o foo -nostartfiles -nostdlib foo.S $ gdb foo (gdb) run Program received signal SIGBUS, Bus error. 0x0804807d in _start () (gdb) x/i $pc 0x804807d <_start+9>: mov 0x1(%esp,1),%eax (gdb) q $ |
|
From: Jeremy F. <je...@go...> - 2003-08-14 17:50:26
|
On Thu, 2003-08-14 at 02:44, Nicholas Nethercote wrote: > On Thu, 14 Aug 2003 ps...@ic... wrote: > > > I would really appreciate a feature being added to detect > > non-aligned access - i.e. could the valgrind VM halt if it > > reads or writes a 2-byte value from an odd address? or > > a 4-byte value from a non-4-aligned address? (or have an > > option to give a warning?) > > > > This is possibly a good feature for others as well - it > > can ensure portability of your code to the SPARC, for > > example. > > It would absolutely have to be an option, since unaligned accesses are > valid on x86. I'm not convinced how useful this would be in general. > > [aside: don't feel bad, if we included every feature ever requested into > Valgrind, it would have about 100 options] Lucky for us, so does the x86. There is a flag you can set in some register or other which makes the CPU trap on unaligned access. So long as we don't do it internally, you could set that and watch all the unaligned accesses in your program (even without Valgrind). J |
|
From: Crispin F. <val...@fl...> - 2003-08-14 15:25:05
|
On Thu, 2003-08-14 at 08:35, Santeri Paavolainen wrote: > Nicholas Nethercote wrote: > > >This all sounds very complicated, for a case that comes up very rarely in > >practice. What do you think of just improving the error message produced > >by VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) so it says something like "you > >changed $VG_ARGS, so Valgrind can't continue", and similar for LD_PRELOAD > >and LD_LIBRARY_PATH? > > > > > I agree, this issue is anyway already covered in the FAQ now and I just > stumbled on it because the program I was testing sanitized the > environmental variables for its children. > > (I was just pointing out that putenv/clearenv/setenv are not the access > point to environmental variables, but the `environ' global variable is, > so if someone feels like patching valgrind, they should watch `environ', > not the individual functions that modify it..) Monitoring the environ variable is not perfect either as you can quite happily call execve directly and pass a brand new environment in. This is presumably all the valgrind sees at the moment (AIUI all the other exec functions are libc wrappers). Wouldn't it be possible for valgrind to realise that the required environment variables aren't present and add them in again, either by mallocing some space for the new env array and the env entries, or by using a few static buffers ? Crispin |
|
From: <ps...@ic...> - 2003-08-14 12:49:24
|
this is true however, our datasheet lists it as undefined-behavior, so to be safe i am assuming that undefined-behavior = worst-behavior-imaginable in any case i do actually have a suspicion that it corrupts the cache on this processor - so i want to rule this out the valgrind way. :-) -paul > In message <E19...@sc...> > ps...@ic... wrote: > > > However, the target platform (ARM) does not allow > > non-aligned short and int accesses. It also does not show > > up the error - the result of non-aligned access is cache > > corruption (ouch). > > I don't believe that the ARM will corrupt the cache if you do an > unaligned access but what it will do is load a wierd rotated value > that you won't be expecting. The behaviour is well defined, if a > little on the odd side, and truly sick people have been known to > write code that relies on it ;-) > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users --------------------------------------------- This message was sent using World Mail. http://www.worldonline.co.za |
|
From: Sebastian K. <Seb...@so...> - 2003-08-14 10:49:59
|
> I don't plan to invest too much money, > and I see the choice between Athlon who may have better cache, branch > prediction and memory architecture, versus higher speed clock but relatively > dumb Celeron. Well. General rule of thumb is that Athlon below model 2500+ compares more or less to P4 with the clock as high as Athlon's model number, and Athlons 2800+ and above are comparable to P4 with MHz == Athlon's model number - 200. And as Celeron has typically performance of P4 200-600 MHz slower (depending on task run) Athlon should be faster for most but a few workloads (those few are some inner loops of raytracing or media encoding/decoding -- which are hand optimised with vector ISA extensions (SSE & SSE2)). > My guts feeling is that for valgrind execution speed is mostly linear > with clock speed, though the branch prediction and cache may have a significant > effect too. But don't forget that on average Athlon has significantly greater instruction throughput. Also Valgrind severely increases cache pressure -- both instruction and data cache. And instrumentation code is allways integer code, so it diminishes the advantages Celeron (& P4) have in it's higher clocked vector unit. > So basically is there something else I forgot, and is there > existing Valgrind execution benchmarks for a given "test program" ? > I'm mostly interested in performances of the simple run of valgrind, > cachegrind kind of use is less common. Hmm, The best way is to benchmark it, by me suspiction is that smaller caches of Celeron with it's sensitivity to self modifing code would make it slower option rgds Sebastian |
|
From: Tom H. <th...@cy...> - 2003-08-14 10:36:34
|
In message <E19...@sc...>
ps...@ic... wrote:
> However, the target platform (ARM) does not allow
> non-aligned short and int accesses. It also does not show
> up the error - the result of non-aligned access is cache
> corruption (ouch).
I don't believe that the ARM will corrupt the cache if you do an
unaligned access but what it will do is load a wierd rotated value
that you won't be expecting. The behaviour is well defined, if a
little on the odd side, and truly sick people have been known to
write code that relies on it ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-14 09:56:30
|
On Thu, 14 Aug 2003 ps...@ic... wrote:
> I would really appreciate a feature being added to detect
> non-aligned access - i.e. could the valgrind VM halt if it
> reads or writes a 2-byte value from an odd address? or
> a 4-byte value from a non-4-aligned address? (or have an
> option to give a warning?)
>
> This is possibly a good feature for others as well - it
> can ensure portability of your code to the SPARC, for
> example.
It would absolutely have to be an option, since unaligned accesses are
valid on x86. I'm not convinced how useful this would be in general.
[aside: don't feel bad, if we included every feature ever requested into
Valgrind, it would have about 100 options]
However, it's easy to hack Valgrind yourself to abort when this happens.
In memcheck/mc_main.c, look for these functions:
MC_(helperc_LOADV4)()
MC_(helperc_LOADV2)()
MC_(helperc_STOREV4)()
MC_(helperc_STOREV4)()
One of them is called for every 4/2-byte memory read/write. You can
easily add a simple alignment check on the first argument ("a").
Something like this should work, for 2-byte accesses (warning, code not
tested):
if (a & 0x1 != 0) {
VG_(pp_ExeContext)(
VG_(get_ExeContext)(
VG_(get_current_or_recent_tid()
)
);
VG_(printf)("a = %p\n", a);
VG_(core_panic)("unaligned 2-byte access");
}
This code should work on the latest release, 20030725; I'm not sure about
earlier releases as some internal details have changed.
Hope this helps.
N
|
|
From: <ps...@ic...> - 2003-08-14 09:38:26
|
Hi there Many thanks for Valgrind I have been using it since 1.0.0 to clean all my applications, but now I am developing on a non-Intel platform. Solution is easy: i just develop on Linux, and recompiled later. However, the target platform (ARM) does not allow non-aligned short and int accesses. It also does not show up the error - the result of non-aligned access is cache corruption (ouch). I would really appreciate a feature being added to detect non-aligned access - i.e. could the valgrind VM halt if it reads or writes a 2-byte value from an odd address? or a 4-byte value from a non-4-aligned address? (or have an option to give a warning?) This is possibly a good feature for others as well - it can ensure portability of your code to the SPARC, for example. (Note that I am aware of the -Wcast-align option to gcc, but trying to make code free of this warning is sometimes too difficult a task for legacy code - certainly for myself at this point.) many thanks -paul --------------------------------------------- This message was sent using World Mail. http://www.worldonline.co.za |
|
From: Santeri P. <sa...@ss...> - 2003-08-14 08:10:17
|
Nicholas Nethercote wrote:
>This all sounds very complicated, for a case that comes up very rarely in
>practice. What do you think of just improving the error message produced
>by VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) so it says something like "you
>changed $VG_ARGS, so Valgrind can't continue", and similar for LD_PRELOAD
>and LD_LIBRARY_PATH?
>
>
I agree, this issue is anyway already covered in the FAQ now and I just
stumbled on it because the program I was testing sanitized the
environmental variables for its children.
(I was just pointing out that putenv/clearenv/setenv are not the access
point to environmental variables, but the `environ' global variable is,
so if someone feels like patching valgrind, they should watch `environ',
not the individual functions that modify it..)
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-14 07:59:14
|
On Wed, 13 Aug 2003, Daniel Veillard wrote: > It doesn't seems to be an FAQ but I would think it's a common problem. > What are the "best" processors to run Valgrind ? "best" in how do I compare > "usual" valgrind speed w.r.t. CPU architecture and clock speed. > I'm usually fine with a relatively slow processor for development but > Valgrind is changing this. I don't plan to invest too much money, > and I see the choice between Athlon who may have better cache, branch > prediction and memory architecture, versus higher speed clock but relatively > dumb Celeron. > My guts feeling is that for valgrind execution speed is mostly linear > with clock speed, though the branch prediction and cache may have a significant > effect too. So basically is there something else I forgot, and is there > existing Valgrind execution benchmarks for a given "test program" ? > I'm mostly interested in performances of the simple run of valgrind, > cachegrind kind of use is less common. See www.cl.cam.ac.uk/~njn25/pubs/valgrind2003.ps.gz, p16 for results on the SPEC benchmarks on an Athlon. That's the only "official" measurements we have, AFAIK. In general, who can say? Processors are so complex these days, I wouldn't have a clue how Valgrind may differ between eg. P3 vs P4. But you may be right, I could believe that Valgrind doesn't interact well with cache and branch prediction. The only way to get a definitive answer is to get actual measurements. I have a script that can be used for benchmarking the SPEC2000 suite, for those of you who have access to it. If anyone is interested, it's at www.cl.cam.ac.uk/~njn25/valgrind/myrun. Instructions for using it are at the top. > Just wondering, I'm probably not the first one who had that question, AFAIK, no-one else has asked this before. N |
|
From: Nicholas N. <nj...@ca...> - 2003-08-14 07:50:19
|
On Thu, 14 Aug 2003, Santeri Paavolainen wrote: > >Or simpler, just wrapper setenv and putenv and force valgrind's paths > >in and prevent VG_ARGS from being changed, but I worry slightly that an > >app might assume it knows how long a variable is because it just set it > >- something like this rather stupid contrived example: > > > To this work, you need to also monitor accesses to the `environ' global > variable. Perhaps that is actually easier, since `putenv', `clearenv' > etc. manipulate just that single global variable. This all sounds very complicated, for a case that comes up very rarely in practice. What do you think of just improving the error message produced by VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) so it says something like "you changed $VG_ARGS, so Valgrind can't continue", and similar for LD_PRELOAD and LD_LIBRARY_PATH? N |
|
From: Santeri P. <sa...@ss...> - 2003-08-14 07:41:33
|
Olly Betts wrote:
>Or simpler, just wrapper setenv and putenv and force valgrind's paths
>in and prevent VG_ARGS from being changed, but I worry slightly that an
>app might assume it knows how long a variable is because it just set it
>- something like this rather stupid contrived example:
>
>
To this work, you need to also monitor accesses to the `environ' global
variable. Perhaps that is actually easier, since `putenv', `clearenv'
etc. manipulate just that single global variable.
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Daniel V. <vei...@re...> - 2003-08-14 01:12:20
|
Hi, It doesn't seems to be an FAQ but I would think it's a common problem. What are the "best" processors to run Valgrind ? "best" in how do I compare "usual" valgrind speed w.r.t. CPU architecture and clock speed. I'm usually fine with a relatively slow processor for development but Valgrind is changing this. I don't plan to invest too much money, and I see the choice between Athlon who may have better cache, branch prediction and memory architecture, versus higher speed clock but relatively dumb Celeron. My guts feeling is that for valgrind execution speed is mostly linear with clock speed, though the branch prediction and cache may have a significant effect too. So basically is there something else I forgot, and is there existing Valgrind execution benchmarks for a given "test program" ? I'm mostly interested in performances of the simple run of valgrind, cachegrind kind of use is less common. Just wondering, I'm probably not the first one who had that question, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |