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
(5) |
2
(1) |
3
(1) |
|
4
|
5
|
6
(2) |
7
(1) |
8
|
9
|
10
|
|
11
|
12
(5) |
13
(2) |
14
|
15
(2) |
16
(1) |
17
|
|
18
(1) |
19
(1) |
20
(2) |
21
|
22
(5) |
23
|
24
(1) |
|
25
|
26
|
27
(2) |
28
(3) |
|
|
|
|
From: Phil L. <plo...@sa...> - 2018-02-22 22:33:15
|
I have now built valgrind for freebsd up to 3.13.0. I have a git repository (https://bitbucket.org/plongstaff/valgrind-freebsd-git) which has a 'master' branch which is a clone of the official git repository, and a 'freebsd' branch which has the freebsd changes. These originally came from the work that Stanislav Sedov had, with some additions that we made at Sandvine for some syscalls. These branches allow me to 'git pull' any valgrind source changes, then rebase the freebsd branch to keep it up to date. 'make regtest' builds, but does not pass. I have fixed a few of the problems but not all of them. Phil -----Original Message----- From: pa...@fr... [mailto:pa...@fr...] Sent: Thursday, February 22, 2018 3:32 PM To: val...@li... Subject: Re: [Valgrind-developers] Valgrind on FreeBSD ----- Original Message ----- > I see that the topic of upstreaming FreeBSD Valgrind support has come > up again. (It seems my mailing list subscription was disabled and I > missed the thread.) > > Various folks have been updating and maintaining the Valgrind FreeBSD > port for over a decade so I will be very happy if we can finally > upstream our changes. Hi I'd be interested in this as I have a FreeBSD system at home. The current FreeBSD Valgrind version is 3.10.1 - that's about 3 years ago. I did take a look at the state of the differences between the Valgrind SVN head and the FreeBSD fork about a year ago. There were a lot of platform specific diffs where Solaris and Tile-GX had been added and FreeBSD removed. Otherwise, relatively few significant differences. I couldn't get 'make regtest' to execute, there is a build failure in drd/tests/std_thread.cpp, a problem with a bit of code that is using internals from libstdc++ thread.cc. FreeBSD no longer uses libstdc++ so it won't compile. A+ Paul ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <pa...@fr...> - 2018-02-22 20:32:01
|
----- Original Message ----- > I see that the topic of upstreaming FreeBSD Valgrind support has come > up again. (It seems my mailing list subscription was disabled and I > missed the thread.) > > Various folks have been updating and maintaining the Valgrind FreeBSD > port for over a decade so I will be very happy if we can finally > upstream our changes. Hi I'd be interested in this as I have a FreeBSD system at home. The current FreeBSD Valgrind version is 3.10.1 - that's about 3 years ago. I did take a look at the state of the differences between the Valgrind SVN head and the FreeBSD fork about a year ago. There were a lot of platform specific diffs where Solaris and Tile-GX had been added and FreeBSD removed. Otherwise, relatively few significant differences. I couldn't get 'make regtest' to execute, there is a build failure in drd/tests/std_thread.cpp, a problem with a bit of code that is using internals from libstdc++ thread.cc. FreeBSD no longer uses libstdc++ so it won't compile. A+ Paul |
|
From: Ivo R. <iv...@iv...> - 2018-02-22 17:18:53
|
2018-02-22 17:19 GMT+01:00 Ed Maste <em...@fr...>: > I see that the topic of upstreaming FreeBSD Valgrind support has come > up again. (It seems my mailing list subscription was disabled and I > missed the thread.) > > Various folks have been updating and maintaining the Valgrind FreeBSD > port for over a decade so I will be very happy if we can finally > upstream our changes. > > The requirements mentioned include: > >> some users, > > I don't have statistics, but there are definitely a reasonable number > of consistent Valgrind users on FreeBSD. This issue came up most > recently from a discussion of the PMDK (Persistent Memory Development > Kit) on FreeBSD, which makes use of Valgrind in its tests. > >> developer(s) doing maintenance > > Various developers have been maintaining the FreeBSD port since before > 2004; people come and go and tend to get burned out by the challenges > of maintaining a local patch set, but I am confident that if we can > get the changes upstream we'll have sufficient maintainers to keep on > top of new syscalls etc. Oh, that's excellent news! > >> developer(s) reachable to answer simple questions about the port > > Are you referring to user's questions, or questions from other developers? Questions from other developers. This mostly boils down to scenarios where a change in one platform affects seemingly unrelated part affecting another platform. We do not assume that every developer has access to every supported platform - it is up to that particular developer to resolve any problems with platform maintainers in a constructive way. > I'm certain that most of the folks who have been involved in the port > to date will be willing to answer questions that come up with respect > to the FreeBSD port when others are adding new Valgrind features etc., > and I think we'll be able to respond to user questions specific to the > FreeBSD port. > >> access to a system to test/compile >> nightly regression build sending results to valgrind-testresults alias > > Do you mean access to a system for other developers to test proposed > changes on FreeBSD? The FreeBSD Foundation should be able to arrange a > machine or VM to run regression tests and provide Valgrind developer > access. That would be also cool. But what is more needed is to setup a FreeBSD buildbot and maintain it. There are simple instructions in Valgrind repo how to do it (nightly/README.txt). Various platform maintainers maintain Valgrind buildbots, checking for regressions. I have been maintaining Solaris port and Solaris 11.3+11.4 buildbot since 2015. >> OS specific regression tests versioned in Valgrind GIT > > I am unsure what the state of the regression tests is at present; as > Phil Longstaff has most recently been working on the port he might > have some insight? In practice, you should submit FreeBSD specific regression tests along with the rest of your patches. It's in your best interest to keep them up to date and passing. I. |
|
From: Ed M. <em...@fr...> - 2018-02-22 16:20:18
|
I see that the topic of upstreaming FreeBSD Valgrind support has come up again. (It seems my mailing list subscription was disabled and I missed the thread.) Various folks have been updating and maintaining the Valgrind FreeBSD port for over a decade so I will be very happy if we can finally upstream our changes. The requirements mentioned include: > some users, I don't have statistics, but there are definitely a reasonable number of consistent Valgrind users on FreeBSD. This issue came up most recently from a discussion of the PMDK (Persistent Memory Development Kit) on FreeBSD, which makes use of Valgrind in its tests. > developer(s) doing maintenance Various developers have been maintaining the FreeBSD port since before 2004; people come and go and tend to get burned out by the challenges of maintaining a local patch set, but I am confident that if we can get the changes upstream we'll have sufficient maintainers to keep on top of new syscalls etc. > developer(s) reachable to answer simple questions about the port Are you referring to user's questions, or questions from other developers? I'm certain that most of the folks who have been involved in the port to date will be willing to answer questions that come up with respect to the FreeBSD port when others are adding new Valgrind features etc., and I think we'll be able to respond to user questions specific to the FreeBSD port. > access to a system to test/compile > nightly regression build sending results to valgrind-testresults alias Do you mean access to a system for other developers to test proposed changes on FreeBSD? The FreeBSD Foundation should be able to arrange a machine or VM to run regression tests and provide Valgrind developer access. > OS specific regression tests versioned in Valgrind GIT I am unsure what the state of the regression tests is at present; as Phil Longstaff has most recently been working on the port he might have some insight? |
|
From: Olaf H. <ol...@ae...> - 2018-02-22 13:34:52
|
In coregrind/m_syswrap/syswrap-xen.c the handlers of sysctl and domctl check the current ->interface_version. If it is not yet known, an error is reported. Otherwise the current ->cmd is processed. Several commands handle various ->interface_version. But none of these handlers have a concept of "use the latest". If a new interface_version is added at the beginning of the list, each and every handler must be updated with the newly added version number. I think it would be simpler to check the supported versions as it is done now, then each handler uses the latest layout in a "default:" case. A picture to show what I mean:
index 54153ab1c..910869ff6 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -821,7 +821,7 @@ PRE(domctl)
case 0x0000000a:
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_00000007, machine_sbdf);
break;
- case 0x0000000b:
+ default:
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_0000000b, dev);
__PRE_XEN_DOMCTL_READ(test_assign_device, assign_device_0000000b, flag);
switch (domctl->u.assign_device_0000000b.dev) {
That may fix d73f2c748, which just added a new global version without adjusting every other ->interface_version check. XEN_DOMCTL_test_assign_device, for example, might have been unchanged in xen-4.6, but now valgrind does not handle it anymore.
Olaf
|