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: Nicholas N. <n.n...@gm...> - 2009-03-27 12:58:28
|
On Thu, Mar 26, 2009 at 2:43 PM, Ehab Ababneh <eha...@gm...> wrote: > > what I would like to do is some probably something similar to what was > described here: > http://www.inesc-id.pt/ficheiros/publicacoes/4867.pdf > > However, with little differences: in this paper the code produced by > Valgrind was optitmized. And I am looking at adding some redundant > instructions. > > lets say we have a block (I1, I2, ..., In). I would like to add my own > instructions Ax to the block while preserving the sequence of original > instructions. So, it would look like something like this (I1, I2, A1, A2, > I3, A3,....In). > And what are these A instructions anyways? they are sometimes repetitions of > some of the original instructions (so, may be I1 = A1 but writing to > different registers) and sometimes comparison instructions (may be something > like content(dist(I1)) ?= content(dist(A1))). > > So, basically I am not looking at only collecting some statistics about the > program being executed. I am also trying to play with the instruction stream > being executed. The paper you cited focused on improving the code generated by Valgrind's back-end. It sounds like you want to simply instrument a program's original code with additional code, ie. write a normal tool. In which case understand the Vex IR is crucial. I'd recommend reading this paper if you haven't already: http://www.valgrind.org/docs/valgrind2007.pdf Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:52:54
|
On Fri, Mar 27, 2009 at 3:53 AM, Filipe Cabecinhas <fi...@gm...> wrote: > Hi, > > Disclaimer: I know the DARWIN branch is unstable ;-) > > I'm having some problems compiling valgrind (DARWIN). Coregrind can't > build because gcc can't find the file coregrind/m_mach/mach_vmUser.c > > I see there are *.Po files with vmUser on the name but they all seem to > be dummy files. > > Does valgrind compile on DARWIN or not yet? (I have this bug since a few > weeks ago, at least) It does, I've been working on it frequently in the past few weeks. The coregrind/m_mach/*User.c files are generated by a program called 'mig' (short for Mach Interface Generator, IIUC), see coregrind/Makefile.am. So I would guess that there's a build system problem, especially if you've had this problem for weeks. Have you tried a fresh check-out and build? Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:46:32
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Merging a Windows port to the existing repository would take time and > effort. In particular, the portability infrastructure would need to be built > up in some places where all current ports happen to be the same. To give you an idea, I've been working on merging Greg's Darwin port for about 2 months now, with a couple of weeks of help from Julian, and I would estimate we are roughly half way towards merging it with the trunk. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:45:05
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Porting to Windows or Haiku or some other OS > that is fundamentally not-a-Unix would be a big step up in difficulty. > (Also, kernel and C library source code is invaluable. That would be another > obstacle on Windows in particular.) Another problem with Windows, AIUI, is that the syscall interface between the kernel and user-space isn't well defined (ie. not public and subject to change). Rather, what is well defined is the equivalent of libc. So writing syscall wrappers is problematic. A couple of years ago there was some more detailed discussion about a Windows port on the dev list. You might be able to find the thread with some searching. I couldn't find it, but I could find this: http://www.mail-archive.com/val...@li.../msg01402.html which suggests that getting Valgrind working with Wine would be much easier. Nick |
|
From: Filipe C. <fi...@gm...> - 2009-03-27 08:54:22
|
Hi, Disclaimer: I know the DARWIN branch is unstable ;-) I'm having some problems compiling valgrind (DARWIN). Coregrind can't build because gcc can't find the file coregrind/m_mach/mach_vmUser.c I see there are *.Po files with vmUser on the name but they all seem to be dummy files. Does valgrind compile on DARWIN or not yet? (I have this bug since a few weeks ago, at least) What would this vmUser file do? Thanks in advance, F |
|
From: Bart V. A. <bar...@gm...> - 2009-03-27 08:21:33
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-27 02:00:02 EDT Results differ 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) ================================================= == Results 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, 37 stderr failures, 9 stdout failures, 0 post failures == drd/tests/pth_create_chain (stderr) 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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Mar 27 03:10:28 2009 --- new.short Fri Mar 27 04:21:14 2009 *************** *** 8,11 **** ! == 407 tests, 37 stderr failures, 9 stdout failures, 0 post failures == ! drd/tests/pth_create_chain (stderr) exp-ptrcheck/tests/bad_percentify (stderr) --- 8,10 ---- ! == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-27 04:34:15
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-27 03:05:12 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-27 04:28:14
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-27 03:20:12 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-27 03:52:13
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-27 03:10:13 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: Greg P. <gp...@ap...> - 2009-03-27 02:11:05
|
On Mar 26, 2009, at 2:05 AM, Tor Lillqvist 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? Copyright issues did delay the release. But note that after 30,000 lines of changes, it's still not a "finished" port. And Mac OS X is a relatively friendly porting environment for Valgrind - much of it is Unix so much of the Linux code can be reused. Porting to Windows or Haiku or some other OS that is fundamentally not-a-Unix would be a big step up in difficulty. (Also, kernel and C library source code is invaluable. That would be another obstacle on Windows in particular.) > 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? Merging a Windows port to the existing repository would take time and effort. In particular, the portability infrastructure would need to be built up in some places where all current ports happen to be the same. The natural path is probably something like what the Darwin port followed. Start with an entirely separate tree that you can mangle at your leisure. Later move to patches then a branch then the trunk, as your changes settle down and you add any necessary multi-platform infrastructure. The Darwin port had two ground-up restarts in its first two years, as various experiments came and went. You really don't want to be anywhere near trunk when your change rate looks like that. -- Greg Parker gp...@ap... Runtime Wrangler |
|
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. |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-25 15:21:54
|
On Wed, Mar 25, 2009 at 2:18 AM, Tom Hughes <th...@cy...> wrote:
> Nicholas Nethercote wrote:
>
>> I added a suppression to exp-ptrcheck.supp to suppress this, but it
>> doesn't seem to have worked.
>>
>> {
>> Occurs on Fedora 7--9?
>> exp-ptrcheck:SorG
>> fun:_dl_fini
>> fun:exit
>> fun:(below main)
>> }
>>
>> Tom, would you be able to take a look and see what's wrong with the
>> suppression? Using --gen-suppressions=yes would be the obvious
>> starting point.
>
> Well gen-suppressions is saying it should he a Heap suppression, not an SorG
> suppression? Changing it to a Heap suppression certainly suppresses it for
> me.
Great, thanks, I'm glad it was easy. I'll commit a fix when I get a chance.
Nick
|