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
(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: <ps...@ic...> - 2003-08-18 08:37:10
|
thanks for all the replies for my alignment problem i managed to easily modify the valgrind 1.0 sources to assert 2 and 4 byte reads and writes - so i can finally check my code is alignment clean. the x86 assembly is also useful to know. if i have time, i will make a patch that adds this in as an option: --warn-non-aligned-access (?) best wishes -paul --------------------------------------------- This message was sent using World Mail. http://www.worldonline.co.za |
|
From: Jeremy F. <je...@go...> - 2003-08-18 07:51:38
|
On Mon, 2003-08-18 at 00:13, Nicholas Nethercote wrote: > No, but I wasn't aware it was something to look out for. Is it clear what > needs to be checked, ie. is there a firm definition of "moderately > complex"? In simple terms, modifying data-structures in a signal handler. You could probably modify helgrind itself, or at least its algorithm, to handle this case. In effect, there are two threads: the main-line code, and the signal handlers (extra complication: signal handlers can be recursive). Signals, if delivered, cause the context switch. The mutex operator is sigprocmask, so you set a fixed set of NSIG locks. The general idea that if you're touching a piece of memory and the handler for signal N also touches that memory, you'd better have signal N blocked. You can easily tell when you start running a signal handler, because a signal is delivered. The tricky part is knowing when you've stopped - sigreturn is easy, but you can longjmp out of a handler. On the other hand, maybe it doesn't matter. J |
|
From: Nicholas N. <nj...@ca...> - 2003-08-18 07:27:55
|
On Sun, 17 Aug 2003, Jeremy Fitzhardinge wrote: > > I've written a new skin for Valgrind. It's called Crocus, and it searches > > for problems in signal handlers. > > Have you considered adding helgrind-like functionality to look for > signal races? Any code which needs to do something moderately complex > in a signal handler needs to make sure that it uses sigprocmask() to > prevent signals from happening at the wrong time in the mainline code. No, but I wasn't aware it was something to look out for. Is it clear what needs to be checked, ie. is there a firm definition of "moderately complex"? N |
|
From: Jeremy F. <je...@go...> - 2003-08-18 00:32:54
|
On Wed, 2003-07-02 at 03:05, Nicholas Nethercote wrote: > I've written a new skin for Valgrind. It's called Crocus, and it searches > for problems in signal handlers. Have you considered adding helgrind-like functionality to look for signal races? Any code which needs to do something moderately complex in a signal handler needs to make sure that it uses sigprocmask() to prevent signals from happening at the wrong time in the mainline code. I have a chunk of code (autofs4's automount daemon) which does quite a lot of stuff from signal handlers, and it would be nice to check for correct behaviour. J |
|
From: Tom H. <th...@cy...> - 2003-08-17 18:25:41
|
In message <BAY...@ho...>
"Sefer Tov" <se...@ho...> wrote:
> I have recently tried an old program of mine using valgrind (latest cvs
> version) and encountered an error stating it's missing an implementation
> syscall no. 7 on my Mandrake 9.1 (glibc 2.3.2) box.
> I looked through the header files and it seems to be coming from a missing
> implementation of "waitpid" (called via __libc_waitpid).
That's odd - if I compile a program using waitpid I find that it
actually calls the wait4 system call. I guess you must have compiled
it against an old version of glibc or something.
> I'd appreciate it if anyone could offer a patch to fix that and integrate
> it into the head branch.
The attached patch should handle it...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sefer T. <se...@ho...> - 2003-08-17 16:21:07
|
Hi!
I have recently tried an old program of mine using valgrind (latest cvs
version) and encountered an error stating it's missing an implementation
syscall no. 7 on my Mandrake 9.1 (glibc 2.3.2) box.
I looked through the header files and it seems to be coming from a missing
implementation of "waitpid" (called via __libc_waitpid).
I'd appreciate it if anyone could offer a patch to fix that and integrate it
into the head branch.
Thanks,
Sefer.
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: William T. <wtr...@sh...> - 2003-08-15 22:37:16
|
On Thu, 14 Aug 2003 22:14:38 -0700 Jeremy Fitzhardinge <je...@go...> wrote regarding Re: [Valgrind-users] Build Problem: > Looks like it's this bug: > http://www.mail-archive.com/bug...@gn.../msg01658.html Yes, that was it. I just built and installed make 3.80 and now Valgrind builds without error. Thanks to all who helped, Bill |
|
From: Nicholas N. <nj...@ca...> - 2003-08-15 07:58:11
|
On Thu, 14 Aug 2003, Jeremy Fitzhardinge wrote: > > ~# make --version > > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > > Built for i386-pc-linux-gnu > > > > I've built lots of source packages here without any make problems. Of course there's always a first time. > > Looks like it's this bug: > http://www.mail-archive.com/bug...@gn.../msg01658.html > > RH 9 has this version of make, but it doesn't have the bug, so > presumably there's a patch for it. And 3.80 was released last year. This bug has come up a few times. I've added it to the FAQ. N |
|
From: Santeri P. <sa...@ss...> - 2003-08-15 07:25:37
|
Crispin Flowerday wrote:
>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 ?
>
>
Good point. I noticed that Valgrind does the following steps wrt/ exec:
1. valgrind.so is hooked using LD_PRELOAD
2. Command line arguments are passed to coregrind through the VG_ARGS
environmental variable.
3. When an execve is trapped (vg_syscalls.c), clo_trace_children is
checked: if child tracing is enabled, valgrind does nothing. If child
tracing is disabled, mash_LD_PRELOAD_and_LD_LIBRARY_PATH is called to
modify LD_PRELOAD and LD_LIBRARY_PATH to remove valgrind.
To allow tracing environmetal variables, I think valgrind should instead
always remove itself from LD_PRELOAD, LD_LIBRARY_PATH and clear VG_ARGS
from the environment. When it traps the execve system call, it would
look into clo_trace_children, and if child tracing is enabled,
LD_PRELOAD, LD_LIBRARY_PATH and VG_ARGS would be modified to include the
original values (since valgrind knows what the values are, this step
would just copy the known correct values in).
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Jeremy F. <je...@go...> - 2003-08-15 05:25:18
|
On Thu, 2003-08-14 at 13:33, William Trenker wrote: > On Thu, 14 Aug 2003 20:16:56 -0700 > Jeremy Fitzhardinge <je...@go...> wrote regarding Re: [Valgrind-users] Build Problem: > > > What version of make and > > distro are you using? > > ~# make --version > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. > Built for i386-pc-linux-gnu > > I've built lots of source packages here without any make problems. Of course there's always a first time. Looks like it's this bug: http://www.mail-archive.com/bug...@gn.../msg01658.html RH 9 has this version of make, but it doesn't have the bug, so presumably there's a patch for it. And 3.80 was released last year. J |
|
From: William T. <wtr...@sh...> - 2003-08-15 03:55:47
|
On Thu, 14 Aug 2003 20:16:56 -0700 Jeremy Fitzhardinge <je...@go...> wrote regarding Re: [Valgrind-users] Build Problem: > What version of make and > distro are you using? ~# make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i386-pc-linux-gnu I've built lots of source packages here without any make problems. Of course there's always a first time. Bill |
|
From: Jeremy F. <je...@go...> - 2003-08-15 03:22:10
|
On Thu, 2003-08-14 at 12:19, William Trenker wrote: > source='cp-demangle.c' object='cp-demangle.o' libtool=no \ > depfile='.deps/cp-demangle.Po' tmpdepfile='.deps/cp-demangle.TPo' \ > depmode=gcc /bin/sh ../../depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include -Winline -Wall -Wshadow -O -fomit-frame-pointer -g -mpreferred-stack-boundary=2 -Wno-unused -Wno-shadow -c `test -f 'cp-demangle.c' || echo './'`cp-demangle.c > make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. Looks like an assert failure in make itself. What version of make and distro are you using? Might want to see if there's an update. J |
|
From: William T. <wtr...@sh...> - 2003-08-15 02:37:00
|
Can someone give me some direction with the build error shown below? Notice the assertion failure. I had simply downloaded the source, untar-ed it, did ./configure then tried make. My configuration is: Linux 2.4.19; libc.so.6 2.2.5; gcc 2.95.3 Thanks, Bill /src/valgrind-20030725# make make all-recursive make[1]: Entering directory `/src/valgrind-20030725' Making all in coregrind make[2]: Entering directory `/src/valgrind-20030725/coregrind' Making all in demangle make[3]: Entering directory `/src/valgrind-20030725/coregrind/demangle' source='cp-demangle.c' object='cp-demangle.o' libtool=no \ depfile='.deps/cp-demangle.Po' tmpdepfile='.deps/cp-demangle.TPo' \ depmode=gcc /bin/sh ../../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include -Winline -Wall -Wshadow -O -fomit-frame-pointer -g -mpreferred-stack-boundary=2 -Wno-unused -Wno-shadow -c `test -f 'cp-demangle.c' || echo './'`cp-demangle.c make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/src/valgrind-20030725/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/src/valgrind-20030725' make: *** [all] Error 2 |
|
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.
|