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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Jeremy F. <je...@go...> - 2003-12-28 21:52:19
|
On Sun, 2003-12-28 at 06:43, Doug Rabson wrote: > It seems to me that the simplest approach would be to move the really > os-dependant files into a subdir of coregrind (e.g. coregrind/linux). > Files which seem to be in this category are vg_libpthread*.c, > vg_procselfmaps.c, vg_proxylwp.c, vg_signals.c (maybe), vg_syscall.S, > vg_syscalls.c, vg_unistd.h, vg_unsafe.h. Similarly in include, > vg_kerneliface.h would move to include/linux/vg_kerneliface.h. Yes, but I think we should take the time to break it down further. Some of those files are just Linux-dependent (like most of proxylwp.c, most of vg_syscalls.c, procselfmaps.c, etc), and some are both linux-x86 dependent (*.S, vg_kerneliface.c, and so on). Is FreeBSD x86 only, or has it been ported to other architectures (I know the other BSDs are widely ported). Do you know if all the BSDs have, for example, common syscall numbers across architectures? I'd be really interested if you can update the port for the FV world. I'd like to know where the new non-portable bits are. For example, how does FreeBSD lay out the user address space, and how much is reserved for the kernel? J |
|
From: Doug R. <df...@nl...> - 2003-12-28 14:43:25
|
On Sun, 2003-12-28 at 14:32, Julian Seward wrote: > On Saturday 27 December 2003 17:02, Dirk Mueller wrote: > > > > Most of the > > > syscall hairy bits should also help to get NetBSD and OpenBSD going too. > > > I have ended up with a bit of an ifdef tangle in a few places but that > > > might be best managed by simply forking a few of the source files > > > (vg_kerneliface.h, vg_syscalls.c and similar). My patch is currently > > > about 130k (as a unified diff against 2.1.0. > > > > Yes. ideally we should start with a directory structure and move the linux > > specific files in a subdir, and fork them for other operating systems or > > architectures. > > I agree with Dirk. Ports are of course a good thing, but we need > structure. Can you make a proposal for how to adjust the directory > structure so as to accommodate these x86 unixes as cleanly/modularly > as possible? Then we can think about adding the FreeBSD stuff to > the cvs. Solaris-x86 is another potential target, btw. It seems to me that the simplest approach would be to move the really os-dependant files into a subdir of coregrind (e.g. coregrind/linux). Files which seem to be in this category are vg_libpthread*.c, vg_procselfmaps.c, vg_proxylwp.c, vg_signals.c (maybe), vg_syscall.S, vg_syscalls.c, vg_unistd.h, vg_unsafe.h. Similarly in include, vg_kerneliface.h would move to include/linux/vg_kerneliface.h. > Thanks, > > J > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2003-12-28 13:15:19
|
On Saturday 27 December 2003 17:02, Dirk Mueller wrote: > > Most of the > > syscall hairy bits should also help to get NetBSD and OpenBSD going too. > > I have ended up with a bit of an ifdef tangle in a few places but that > > might be best managed by simply forking a few of the source files > > (vg_kerneliface.h, vg_syscalls.c and similar). My patch is currently > > about 130k (as a unified diff against 2.1.0. > > Yes. ideally we should start with a directory structure and move the linux > specific files in a subdir, and fork them for other operating systems or > architectures. I agree with Dirk. Ports are of course a good thing, but we need structure. Can you make a proposal for how to adjust the directory structure so as to accommodate these x86 unixes as cleanly/modularly as possible? Then we can think about adding the FreeBSD stuff to the cvs. Solaris-x86 is another potential target, btw. Thanks, J |
|
From: Robert W. <rj...@du...> - 2003-12-28 11:31:37
|
> Most of the really serious hacking was in vg_mylibc, vg_proxylwp, > vg_signals, vg_syscalls and vg_kerneliface. Most of the rest of the > changes are simple things (like working around the lack of > ksa_restorer). vg_mylibc should start going away real soon now. FV pretty much took care of that. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |