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
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: <sv...@va...> - 2009-03-26 19:07:38
|
Author: bart Date: 2009-03-26 19:07:15 +0000 (Thu, 26 Mar 2009) New Revision: 9496 Log: - Reindented code such that it uses three spaces for indentation instead of two. The indentation of the DRD source code is now consistent with the other Valgrind source files. - Added emacs mode line with indentation settings. Modified: trunk/drd/drd.h trunk/drd/drd_barrier.c trunk/drd/drd_barrier.h trunk/drd/drd_basics.h trunk/drd/drd_bitmap.c trunk/drd/drd_bitmap.h trunk/drd/drd_clientobj.c trunk/drd/drd_clientobj.h trunk/drd/drd_clientreq.c trunk/drd/drd_clientreq.h trunk/drd/drd_cond.c trunk/drd/drd_cond.h trunk/drd/drd_error.c trunk/drd/drd_error.h trunk/drd/drd_gomp_intercepts.c trunk/drd/drd_load_store.c trunk/drd/drd_load_store.h trunk/drd/drd_main.c trunk/drd/drd_malloc_wrappers.c trunk/drd/drd_malloc_wrappers.h trunk/drd/drd_mutex.c trunk/drd/drd_mutex.h trunk/drd/drd_pthread_intercepts.c trunk/drd/drd_qtcore_intercepts.c trunk/drd/drd_rwlock.c trunk/drd/drd_rwlock.h trunk/drd/drd_segment.c trunk/drd/drd_segment.h trunk/drd/drd_semaphore.c trunk/drd/drd_semaphore.h trunk/drd/drd_strmem_intercepts.c trunk/drd/drd_suppression.c trunk/drd/drd_suppression.h trunk/drd/drd_thread.c trunk/drd/drd_thread.h trunk/drd/drd_thread_bitmap.h trunk/drd/drd_vc.c trunk/drd/drd_vc.h trunk/drd/pub_drd_bitmap.h [... diff too large to include ...] |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-26 15:13:30
|
On Wed, Mar 25, 2009 at 11:57 PM, Ehab Ababneh <eha...@gm...> wrote: > Hello, > For a research project I am doing right now, I need to play with the > generated instruction stream. In some cases I need to inject my own added > instructions into the guest code and in other cases I need to duplicate > already existing instructions. I am right now looking a VEX/priv/.... sub > folder but I also appreciate any help or information that explains the code > with some details. You can assume anything to save time/pain for the emails > back and forth asking for more info (for example for platform I am using > Linux, for the architecture I am using the x86). It's unclear exactly what you want to do. If you need to learn about Vex IR, then VEX/pub/libvex_ir.h is the place to look, and long with the existing tools (especially "lackey", which is a tutorial tool). If you want to change the way native *host* code is generated from Vex IR, then VEX/priv/host-*/ would be the place to look. If you want to add instructions into the *guest* code... I'm not sure what that means. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-26 15:10:02
|
On Thu, Mar 26, 2009 at 4:05 AM, Tor Lillqvist <tm...@ik...> wrote: >> For example, Greg Parker spent about 4 years >> working on the Mac OS X port in his spare time before it got >> incorporated onto a branch. > > Is this the DARWIN branch? Yes. > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? Mostly modesty/secrecy/copyright-issues-with-Apple, AFAIK. > So I am just wondering, if I start doing this in earnest, will I > forever have to just keep my stuff in a local tree (and offer as > separate patched source tarballs, if ever it gets so far that others > could sensibly help), or would it be allowed onto a branch, or as > properly ifdeffed etc, even trunk? See http://www.valgrind.org/info/platforms.html ("porting plans" at the bottom). If you could get Windows working without completely gutting Valgrind that would be very useful because Windows is so widespread. As for branches, we don't have an official policy but having something that works at least on small programs would be much more convincing than something that doesn't. And the bar for putting something on a branch is much lower than including it in the trunk -- eg. the Darwin branch is pretty capable but still has some way to go before it will be merged to the trunk. The reason being that the trunk is the basis of releases and we wouldn't want a release to include a really flaky port -- that's the kind of thing people can get themselves from SVN and their expectations will be set appropriately. > Btw, a question about the indentation and spacing style in Valgrind... > it is somewhat different in different files. Obviously, for existing > files one should use the style of the surrounding code, but which file > is a "canonical" one to have a s a guide when writing completely new > source files? I think .c and .h files are pretty consistently 3-space indents and perl scripts are 4-space. Nick |
|
From: Tor L. <tm...@ik...> - 2009-03-26 11:06:54
|
> That's strange. If you lack exec(), you won't be able to run valgrind in > it's normal form (valgrind will search for a tool executable and exec() it). Trust me, I know what I am doing. The way the valgrind launcher starts the tool is the least of the problems here. And that code is already in platform-dependent launcher-foo.c files anyway, so doing it differently on Windows than on Linux and AIX5 won't cause any ifdefs. --tml |
|
From: Filipe C. <fi...@gm...> - 2009-03-26 10:47:36
|
Hi, Why are you looking at VEX for that? Can't you write a tool to insert those instructions you want? Or do you want to do something that can's be accomplished with a tool? Regards, F On Thu, Mar 26, 2009 at 04:57, Ehab Ababneh <eha...@gm...> wrote: > Hello, > For a research project I am doing right now, I need to play with the > generated instruction stream. In some cases I need to inject my own added > instructions into the guest code and in other cases I need to duplicate > already existing instructions. I am right now looking a VEX/priv/.... sub > folder but I also appreciate any help or information that explains the code > with some details. You can assume anything to save time/pain for the emails > back and forth asking for more info (for example for platform I am using > Linux, for the architecture I am using the x86). > > Thanks in advance. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Filipe C. <fi...@gm...> - 2009-03-26 10:45:52
|
F On Thu, Mar 26, 2009 at 09:05, Tor Lillqvist <tm...@ik...> wrote: > > For example, Greg Parker spent about 4 years > > working on the Mac OS X port in his spare time before it got > > incorporated onto a branch. > > Is this the DARWIN branch? > > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? The patch wasn't available until "recently", but I don't know if Greg spoke/emailed any of the developers off-list in the meantime... > I am contemplating porting Valgrind to x86-windows and have done some > experimentation, and it doesn't seem impossible at all. (I am not > naïve, I do know it will be a lot of work, and I do know that many > things in Windows are totally different from typical Unixes on x86. > OTOH, it is just software, nothing is impossible;) And the lack of > fork() and exec() even makes some things simpler than on Unix, I > guess...) That's strange. If you lack exec(), you won't be able to run valgrind in it's normal form (valgrind will search for a tool executable and exec() it). Btw, a question about the indentation and spacing style in Valgrind... > it is somewhat different in different files. Obviously, for existing > files one should use the style of the surrounding code, but which file > is a "canonical" one to have a s a guide when writing completely new > source files? > >From what I saw in VEX, the spacing was consistently 3 space characters to indent. In coregrind I think it was the same, but I don't know about other tools. Also, some parts of files can have the indentation broken due to someone using different settings. Regards, F |
|
From: Tor L. <tm...@ik...> - 2009-03-26 09:06:15
|
> For example, Greg Parker spent about 4 years > working on the Mac OS X port in his spare time before it got > incorporated onto a branch. Is this the DARWIN branch? Was this four year wait just because of modesty or secrecy on his side, or do the main developers in principle oppose allowing new ports even onto a branch until they are "finished" and actually work, or something? I am contemplating porting Valgrind to x86-windows and have done some experimentation, and it doesn't seem impossible at all. (I am not naïve, I do know it will be a lot of work, and I do know that many things in Windows are totally different from typical Unixes on x86. OTOH, it is just software, nothing is impossible;) And the lack of fork() and exec() even makes some things simpler than on Unix, I guess...) So I am just wondering, if I start doing this in earnest, will I forever have to just keep my stuff in a local tree (and offer as separate patched source tarballs, if ever it gets so far that others could sensibly help), or would it be allowed onto a branch, or as properly ifdeffed etc, even trunk? Btw, a question about the indentation and spacing style in Valgrind... it is somewhat different in different files. Obviously, for existing files one should use the style of the surrounding code, but which file is a "canonical" one to have a s a guide when writing completely new source files? --tml |
|
From: Bart V. A. <bar...@gm...> - 2009-03-26 08:24:27
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-26 02:00:01 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Ehab A. <eha...@gm...> - 2009-03-26 04:57:10
|
Hello, For a research project I am doing right now, I need to play with the generated instruction stream. In some cases I need to inject my own added instructions into the guest code and in other cases I need to duplicate already existing instructions. I am right now looking a VEX/priv/.... sub folder but I also appreciate any help or information that explains the code with some details. You can assume anything to save time/pain for the emails back and forth asking for more info (for example for platform I am using Linux, for the architecture I am using the x86). Thanks in advance. |
|
From: Tom H. <th...@cy...> - 2009-03-26 04:22:46
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-26 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 4 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-26 04:22:38
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-26 03:20:11 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 487 tests, 0 stderr failures, 0 stdout failures, 0 post failures == |
|
From: Tom H. <th...@cy...> - 2009-03-26 03:48:34
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-26 03:10:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 484 tests, 4 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) none/tests/linux/mremap2 (stdout) |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-26 02:57:09
|
2009/3/25 Adrian Panasiuk <ad...@gm...>: > Hi, > I am considering porting valgrind to Haiku ( http://www.haiku-os.org/ > ). I am aware that it is unlikely that my efforts would be integrated > into the main tree, but I am ok with keeping the patchset externally. > > Could you tell me what are the main challenges when porting valgrind > to a new platform? I want to limit myself to coregrind and nulgrind. > Am I correct, that there is little platform-dependent code in files > which do not have a platform name in their filename? Could you give me > a brief explanation of what each platform-dependent piece's functions > are? You'll need to port to a new arch/OS combination, eg. x86/Haiku. docs/internals/porting-HOWTO.txt has some details, but it's also out-of-date and so shouldn't be trusted completely. Limiting yourself to coregrind and nulgrind sounds strange -- is that really what you want? Then you'll be able to run programs more slowly than normal under Valgrind but not learn anything useful about them. Surely you want Memcheck as well? Platform-dependent code is sprinkled in lots of places, not just the files with names like foo-x86-linux.c. Look for things like "#if defined (VGO_linux)" and "#if defined(VGP_x86_linux)". A port is a lot of work. Porting Valgrind is much harder than porting a normal program. For example, Greg Parker spent about 4 years working on the Mac OS X port in his spare time before it got incorporated onto a branch. The patch that was incorporated was 31,000 lines of code. And you'll need a really good idea of how the Haiku kernel interfaces with user-space, and you'll have to learn a lot about Valgrind too. Nick |
|
From: Adrian P. <ad...@gm...> - 2009-03-26 01:09:46
|
Hi, I am considering porting valgrind to Haiku ( http://www.haiku-os.org/ ). I am aware that it is unlikely that my efforts would be integrated into the main tree, but I am ok with keeping the patchset externally. Could you tell me what are the main challenges when porting valgrind to a new platform? I want to limit myself to coregrind and nulgrind. Am I correct, that there is little platform-dependent code in files which do not have a platform name in their filename? Could you give me a brief explanation of what each platform-dependent piece's functions are? Regards, Adrian. -- Czy ty orzeł, czy ty kawka? -wkrótce zdłabi kaszel, czkawka. Śmierć szyję zaszyje. |