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
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Josef W. <Jos...@gm...> - 2004-01-09 18:53:19
|
Am Mittwoch, 7. Januar 2004 13:04 schrieb Nicholas Nethercote:
> Colon (':') chars? Yes, they wouldn't be allowed, but that doesn't seem
> like a great loss? If that's a problem, maybe --toolname::option, or
> something even more obscure?
In calltree, in some options there can symbol names be specified, e.g. where
to start collecting, and so on. Unfortunately, for C++, colons can be part of
the symbol name.
As my options are like --option=... it would work with your scheme if we only
allow alpha(numeric?) characters as part of a tool/skin name, e.g. not '='.
Is this acceptable?
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-09 17:56:49
|
On Fri, 9 Jan 2004, Jeremy Fitzhardinge wrote: > > I've swapped, giving: > > > > 1. VALGRIND_OPTS > > 2. ~/.valgrindrc > > 3. ./.valgrindrc > > Where does the command-line come into this? What happens with > _VALGRIND_CLO? I think if the latter is set, then everything else > should be ignored, since it should contain the complete union of all > command line options anyway. Behaviour should be the same as before; where VALGRIND_OPTS was read before, I know read VALGRIND_OPTS plus the two .rc files. > > Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc > > files and didn't munmap them is reasonable. > > Why mmap? Why not just allocate a chunk of memory and read? Didn't think of that. I'll change it. > > I think this also fixes bug 71126, thanks to Tom for his patch. > > I still think this could do with a more radical rearrangement. I don't > think main() should be parsing the command line at all, or loading the > tool. If it simply generates a unified vg_argv and passes it to > VG_(main), VG_(main) can do the rest. This means that the address space > should remain padded until VG_(main) is ready to unpad it (ie, after > doing dlopen on the tool). Can you clarify what you see as the conceptual difference between main() and VG_(main)()? One possibility is that main() is a bit like __libc_start_main(), ie sets things like argv/argc up ready for the program. Then VG_(main)() is a bit like main() for a normal program -- start doing real stuff. In which case, moving the command-line parsing to main() makes perfect sense. However, to me, the unpadding feels like it should be done as part of the setup stuff in main(). 1. pad 2. setup argv 3. partially parse argv to find tool 4. load tool.so + valgrind.so 5. do_exec the client binary 6. unpad Because it's all a bit mixed up at the start -- necessary due to tool selection from the command-line -- there doesn't seem to be an obvious cut point between main() and VG_(main)(). N |
|
From: Doug R. <df...@nl...> - 2004-01-09 17:47:03
|
On Fri, 2004-01-09 at 17:40, Nicholas Nethercote wrote: > On Fri, 9 Jan 2004, Doug Rabson wrote: > > > > Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc > > > files and didn't munmap them is reasonable. > > > > This will have problems if the file is exactly getpagesize() bytes long > > since the mmap'ed image won't be null terminated. > > Would changing this: > > f_clo = mmap(0, s1.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); > > to this > > f_clo = mmap(0, s1.st_size+1, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); > > fix it? Probably. It does seem easier to malloc+read the contents though. |
|
From: Nicholas N. <nj...@ca...> - 2004-01-09 17:40:11
|
On Fri, 9 Jan 2004, Doug Rabson wrote:
> > Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc
> > files and didn't munmap them is reasonable.
>
> This will have problems if the file is exactly getpagesize() bytes long
> since the mmap'ed image won't be null terminated.
Would changing this:
f_clo = mmap(0, s1.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
to this
f_clo = mmap(0, s1.st_size+1, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
fix it?
N
|
|
From: Jeremy F. <je...@go...> - 2004-01-09 17:38:18
|
On Fri, 2004-01-09 at 08:20, Nicholas Nethercote wrote: > I've swapped, giving: > > 1. VALGRIND_OPTS > 2. ~/.valgrindrc > 3. ./.valgrindrc Where does the command-line come into this? What happens with _VALGRIND_CLO? I think if the latter is set, then everything else should be ignored, since it should contain the complete union of all command line options anyway. > Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc > files and didn't munmap them is reasonable. Why mmap? Why not just allocate a chunk of memory and read? > I think this also fixes bug 71126, thanks to Tom for his patch. I still think this could do with a more radical rearrangement. I don't think main() should be parsing the command line at all, or loading the tool. If it simply generates a unified vg_argv and passes it to VG_(main), VG_(main) can do the rest. This means that the address space should remain padded until VG_(main) is ready to unpad it (ie, after doing dlopen on the tool). J |
|
From: Jeremy F. <je...@go...> - 2004-01-09 17:30:17
|
On Fri, 2004-01-09 at 01:15, Julian Seward wrote: > So if a PPC port was done, the ppc insn decoder/emitters > would go in ppc-common, and then ppc-linux would hold the > glue for that particular (arch, OS) pair? Sounds ok to me. Yup. > Are there any problems now stopping us using C++ ? We'd > have to connect new/delete to our internal memory manager, > but that's doable, no? Should be OK, in principle. Haven't tested it. J |
|
From: Doug R. <df...@nl...> - 2004-01-09 16:49:02
|
On Fri, 2004-01-09 at 16:20, Nicholas Nethercote wrote: > On Thu, 8 Jan 2004, Nicholas Nethercote wrote: > > > I'm currently looking in three places: > > > > 1. ~/.valgrindrc > > 2. VALGRIND_OPTS > > 3. ./.valgrindrc > > > > Args are added in that order, the idea being that more 'local' args are > > added later, to override less local ones. (1) and (2) could be swapped, > > but (3) should definitely be last, as it's clearly the most local. > > I've swapped, giving: > > 1. VALGRIND_OPTS > 2. ~/.valgrindrc > 3. ./.valgrindrc > > Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc > files and didn't munmap them is reasonable. > > I think this also fixes bug 71126, thanks to Tom for his patch. This will have problems if the file is exactly getpagesize() bytes long since the mmap'ed image won't be null terminated. |
|
From: Nicholas N. <nj...@ca...> - 2004-01-09 16:27:44
|
On Fri, 9 Jan 2004, Nicholas Nethercote wrote: > Diff is attached, feedback welcome. Oh, I haven't added support for quoting to allow spaces within args... N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-09 16:20:06
|
On Thu, 8 Jan 2004, Nicholas Nethercote wrote: > I'm currently looking in three places: > > 1. ~/.valgrindrc > 2. VALGRIND_OPTS > 3. ./.valgrindrc > > Args are added in that order, the idea being that more 'local' args are > added later, to override less local ones. (1) and (2) could be swapped, > but (3) should definitely be last, as it's clearly the most local. I've swapped, giving: 1. VALGRIND_OPTS 2. ~/.valgrindrc 3. ./.valgrindrc Diff is attached, feedback welcome. I hope the way I mmap'd in the .rc files and didn't munmap them is reasonable. I think this also fixes bug 71126, thanks to Tom for his patch. N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-09 16:15:38
|
CVS commit by nethercote:
Remove address from output, which varies from machine to machine and causes
failure.
M +2 -2 as_shm.c 1.3 [POSSIBLY UNSAFE: printf]
M +1 -1 as_shm.stdout.exp 1.2
--- valgrind/corecheck/tests/as_shm.c #1.2:1.3
@@ -19,5 +19,5 @@ int main()
perror("shmat @ 0");
else
- printf("shmat 0: addr=%p\n", addr);
+ printf("shmat 0: addr=...\n");
addr = shmat(shmid, top, 0);
@@ -26,5 +26,5 @@ int main()
perror("shmat @ top");
else
- printf("shmat 2: addr=%p\n", addr);
+ printf("shmat 2: addr=...\n");
shmctl(shmid, IPC_RMID, NULL);
--- valgrind/corecheck/tests/as_shm.stdout.exp #1.1:1.2
@@ -1 +1 @@
-shmat 0: addr=0x81156000
+shmat 0: addr=...
|
|
From: Johan R. <jry...@ni...> - 2004-01-09 10:46:28
|
Jeremy Fitzhardinge <je...@go...> wrote: : Because I can never work out how glibc actually builds itself, I think it adds all the directories to the VPATH, with the more specific ones ordered first. : and I don't want the directory tree to get too deep. Good argument, but I still think the "glibc way" is more logical, and actually, much more good looking. : Well, autoconf seems to use the form CPU-OS; common-unix means "any cpu, : unixish OS". It's true that autoconf uses that form, but I see no real reason to keep the common- prefix at all. Why not simply "unix" ? -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net | http://www.nongnu.org/guss/ Playing A-Skills and Krafty Kuts - Tricka Technology |
|
From: Julian S. <js...@ac...> - 2004-01-09 09:13:25
|
> rather than anything of substance. It would be really nice to put all > that common stuff into a common place, to try and cut down on > duplication. I'd also like to minimise #ifdefs in shared code. Definitely. Zero ifdefs is a worthy goal. I've seen maintenance nightmares caused by ifdef trees. > To this end, I think we'll need a number of arch directories: > i386-linux machine-specific linux stuff > i386-freebsd machine-specific freebsd stuff > common-linux general linux stuff > common-freebsd general freebsd stuff > i386-common OS-independent i386 stuff > common-unix things common to Unix-like systems So if a PPC port was done, the ppc insn decoder/emitters would go in ppc-common, and then ppc-linux would hold the glue for that particular (arch, OS) pair? Sounds ok to me. Are there any problems now stopping us using C++ ? We'd have to connect new/delete to our internal memory manager, but that's doable, no? J |
|
From: Jeremy F. <je...@go...> - 2004-01-09 08:48:38
|
On Fri, 2004-01-09 at 00:35, Johan Rydberg wrote: > Why not go with a directory structure that looks like the one > in for example glibc? Because I can never work out how glibc actually builds itself, and I don't want the directory tree to get too deep. > Of course, in glibc all these dirs are located in sysdeps/ > I think the "common" suffix and prefix make it too messy. > And why not "unix-common" instead of "common-unix"? i386-linux > vs linux-i386? Well, autoconf seems to use the form CPU-OS; common-unix means "any cpu, unixish OS". J |
|
From: Johan R. <jry...@ni...> - 2004-01-09 08:35:36
|
Jeremy Fitzhardinge <je...@go...> wrote:
: To this end, I think we'll need a number of arch directories:
: i386-linux machine-specific linux stuff
: i386-freebsd machine-specific freebsd stuff
: common-linux general linux stuff
: common-freebsd general freebsd stuff
: i386-common OS-independent i386 stuff
: common-unix things common to Unix-like systems
Why not go with a directory structure that looks like the one
in for example glibc? Example:
unix/ things common to Unix-like systems
unix/linux/ general linux stuff
unix/linux/i386 machine-specific linux stuff
...
i386/ OS-independent i386 stuff
Of course, in glibc all these dirs are located in sysdeps/
I think the "common" suffix and prefix make it too messy.
And why not "unix-common" instead of "common-unix"? i386-linux
vs linux-i386?
--
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/
|