|
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: 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...> - 2019-01-02 02:12:15
|
On Thu, 22 Feb 2018 at 12:18, Ivo Raisr <iv...@iv...> wrote: > > 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). For now I've been exploring Cirrus-CI as a hosted CI service for the ongoing work on upstreaming the FreeBSD port - see e.g. results at https://cirrus-ci.com/build/5675722230202368 Of course we can also set up a buildbot connecting to the main CI system. |
|
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: 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: Paul F. <pj...@wa...> - 2018-02-28 23:45:09
|
> On 22 Feb 2018, at 23:33, Phil Longstaff <plo...@sa...> wrote: > > 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 Hi Phil Nice job. I just gave it a go with FreeBSD 11.1-RELEASE-p6 and gcc (FreeBSD Ports Collection) 6.4.0. I ran autogen.sh, configure and gmake, resulting in a 32bit build. I had to make 3 changes to get the build to complete (see below). 'make regtest' gave me million.S:35:4: error: #error "Unknown OS" during the build phase. If you like I can also do some testing on Solaris/Linux/macOS. A+ Paul git diff diff --git a/coregrind/m_sigframe/sigframe-x86-freebsd.c b/coregrind/m_sigframe/sigframe-x86-freebsd.c index 39da65ddf..0b5731e48 100644 --- a/coregrind/m_sigframe/sigframe-x86-freebsd.c +++ b/coregrind/m_sigframe/sigframe-x86-freebsd.c @@ -291,6 +291,7 @@ static Addr build_sigframe(ThreadState *tst, /* EXPORTED */ void VG_(sigframe_create)( ThreadId tid, + Bool on_altstack, Addr esp_top_of_frame, const vki_siginfo_t *siginfo, const struct vki_ucontext *siguc, diff --git a/coregrind/m_signals.c b/coregrind/m_signals.c index 306ea705d..195c069ba 100755 --- a/coregrind/m_signals.c +++ b/coregrind/m_signals.c @@ -1067,7 +1067,7 @@ static void handle_SCSS_change ( Bool force_update ) ksa.sa_flags = skss.skss_per_sig[sig].skss_flags; # if !defined(VGP_ppc32_linux) && \ !defined(VGP_x86_darwin) && !defined(VGP_amd64_darwin) && \ - !defined(VGP_mips32_linux) && !defined(VGO_solaris) && !defined(VGP_amd64_freebsd) + !defined(VGP_mips32_linux) && !defined(VGO_solaris) && !defined(VGO_freebsd) ksa.sa_restorer = my_sigreturn; # endif /* Re above ifdef (also the assertion below), PaulM says: diff --git a/coregrind/pub_core_libcproc.h b/coregrind/pub_core_libcproc.h index 9d27f95c1..7ddec8832 100755 --- a/coregrind/pub_core_libcproc.h +++ b/coregrind/pub_core_libcproc.h @@ -89,7 +89,7 @@ extern void VG_(do_atfork_child) ( ThreadId tid ); #if defined(VGO_freebsd) // sysctl, modfind -extern Int VG_(sysctl)(Int *oid, UInt oidlen, void *oldp, vki_size_t *oldlenp, void *newp, vki_size_t newlen); +extern Int VG_(sysctl)(Int *oid, UInt oidlen, void *oldp, SizeT *oldlenp, void *newp, SizeT newlen); extern Int VG_(sysctlbyname)(const Char *name, void *oldp, vki_size_t *oldlenp, void *newp, vki_size_t newlen); extern Int VG_(getosreldate)(void); extern Bool VG_(is32on64)(void); |
|
From: Phil L. <plo...@sa...> - 2018-03-01 22:16:59
|
Hi Paul, Thanks. I only use 64-bit freebsd and have not tried to test 32-bit. I will add your changes. Phil -----Original Message----- From: Paul Floyd [mailto:pj...@wa...] Sent: Wednesday, February 28, 2018 6:45 PM To: valgrind Developers Subject: Re: [Valgrind-developers] Valgrind on FreeBSD > On 22 Feb 2018, at 23:33, Phil Longstaff <plo...@sa...> wrote: > > 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 Hi Phil Nice job. I just gave it a go with FreeBSD 11.1-RELEASE-p6 and gcc (FreeBSD Ports Collection) 6.4.0. I ran autogen.sh, configure and gmake, resulting in a 32bit build. I had to make 3 changes to get the build to complete (see below). 'make regtest' gave me million.S:35:4: error: #error "Unknown OS" during the build phase. If you like I can also do some testing on Solaris/Linux/macOS. A+ Paul git diff diff --git a/coregrind/m_sigframe/sigframe-x86-freebsd.c b/coregrind/m_sigframe/sigframe-x86-freebsd.c index 39da65ddf..0b5731e48 100644 --- a/coregrind/m_sigframe/sigframe-x86-freebsd.c +++ b/coregrind/m_sigframe/sigframe-x86-freebsd.c @@ -291,6 +291,7 @@ static Addr build_sigframe(ThreadState *tst, /* EXPORTED */ void VG_(sigframe_create)( ThreadId tid, + Bool on_altstack, Addr esp_top_of_frame, const vki_siginfo_t *siginfo, const struct vki_ucontext *siguc, diff --git a/coregrind/m_signals.c b/coregrind/m_signals.c index 306ea705d..195c069ba 100755 --- a/coregrind/m_signals.c +++ b/coregrind/m_signals.c @@ -1067,7 +1067,7 @@ static void handle_SCSS_change ( Bool force_update ) ksa.sa_flags = skss.skss_per_sig[sig].skss_flags; # if !defined(VGP_ppc32_linux) && \ !defined(VGP_x86_darwin) && !defined(VGP_amd64_darwin) && \ - !defined(VGP_mips32_linux) && !defined(VGO_solaris) && !defined(VGP_amd64_freebsd) + !defined(VGP_mips32_linux) && !defined(VGO_solaris) && + !defined(VGO_freebsd) ksa.sa_restorer = my_sigreturn; # endif /* Re above ifdef (also the assertion below), PaulM says: diff --git a/coregrind/pub_core_libcproc.h b/coregrind/pub_core_libcproc.h index 9d27f95c1..7ddec8832 100755 --- a/coregrind/pub_core_libcproc.h +++ b/coregrind/pub_core_libcproc.h @@ -89,7 +89,7 @@ extern void VG_(do_atfork_child) ( ThreadId tid ); #if defined(VGO_freebsd) // sysctl, modfind -extern Int VG_(sysctl)(Int *oid, UInt oidlen, void *oldp, vki_size_t *oldlenp, void *newp, vki_size_t newlen); +extern Int VG_(sysctl)(Int *oid, UInt oidlen, void *oldp, SizeT +*oldlenp, void *newp, SizeT newlen); extern Int VG_(sysctlbyname)(const Char *name, void *oldp, vki_size_t *oldlenp, void *newp, vki_size_t newlen); extern Int VG_(getosreldate)(void); extern Bool VG_(is32on64)(void); ------------------------------------------------------------------------------ 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: Paul F. <pj...@wa...> - 2018-03-04 05:52:36
|
> On 1 Mar 2018, at 22:31, Phil Longstaff <plo...@sa...> wrote: > > Hi Paul, > > Thanks. > > I only use 64-bit freebsd and have not tried to test 32-bit. I will add your changes. > > Phil > Hi Phil I’m also using FreeBSD amd64. Normally when you build Valgrind on 64bit platforms it will build both 32bit and 64bit binaries. My memory is a bit hazy on this; it may also depend on whether you have 32bit userland installed, and I can’t remember if this comes by default or not. As a rule, if something fails to build I just find which package to add and install it. Are you using ‘—enable-only64bit’ with configure? A+ Paul |
|
From: Paul F. <pj...@wa...> - 2018-03-04 10:07:30
|
> On 22 Feb 2018, at 23:33, Phil Longstaff <plo...@sa...> wrote: > > 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 > Hi Phil Some more feedback for other platforms. You’ve defined VKI_MAP_STACK in vki-freebsd.h (only) and added it to coregrind/m_aspacemgr/aspacemgr-linux.c without any conditional compilation. In coregrind/m_debuginfo/readelf.c around line 454 there looks like a code merge issue. The ‘#if !defined(VGO_freebsd) block looks spurious. coregrind/m_syswrap/syswrap-freebsd.c needs to be conditionally compiled. I added #if defined(VGO_freebsd) coregrind/m_syswrap/priv_types_n_macros.h has same changes for macOS around line 303 That’s all I needed to change on Linux. macOS and Solaris required quite a few more changes. Next, there are several linux conditional compilation blocks added to coregrind/m_syswrap/priv_syswrap-generic.h. I reverted all of them, and proceeded to make the minimum changes in sys wrap-generic.c where there are also many linux conditional compilation blocks. After that I was able to complete the build on all 3 platforms. A+ Paul |
|
From: Phil L. <plo...@sa...> - 2018-03-07 20:42:23
|
Hi Paul, In answer to a previous question of yours, I did use --enable-only64bit. Can you clone my repository, make the changes, then send me a pull request? Phil From: Paul Floyd [mailto:pj...@wa...] Sent: Sunday, March 4, 2018 5:07 AM To: val...@li... Subject: Re: [Valgrind-developers] Valgrind on FreeBSD On 22 Feb 2018, at 23:33, Phil Longstaff <plo...@sa...<mailto:plo...@sa...>> wrote: 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...> [mailto:pa...@fr...] Sent: Thursday, February 22, 2018 3:32 PM To: val...@li...<mailto:val...@li...> Subject: Re: [Valgrind-developers] Valgrind on FreeBSD Hi Phil Some more feedback for other platforms. You’ve defined VKI_MAP_STACK in vki-freebsd.h (only) and added it to coregrind/m_aspacemgr/aspacemgr-linux.c without any conditional compilation. In coregrind/m_debuginfo/readelf.c around line 454 there looks like a code merge issue. The ‘#if !defined(VGO_freebsd) block looks spurious. coregrind/m_syswrap/syswrap-freebsd.c needs to be conditionally compiled. I added #if defined(VGO_freebsd) coregrind/m_syswrap/priv_types_n_macros.h has same changes for macOS around line 303 That’s all I needed to change on Linux. macOS and Solaris required quite a few more changes. Next, there are several linux conditional compilation blocks added to coregrind/m_syswrap/priv_syswrap-generic.h. I reverted all of them, and proceeded to make the minimum changes in sys wrap-generic.c where there are also many linux conditional compilation blocks. After that I was able to complete the build on all 3 platforms. A+ Paul |
|
From: Phil L. <plo...@sa...> - 2018-03-07 21:28:10
|
Before you do that, I created a bit of a merge mess in the freebsd branch and need to clean it up. From: Phil Longstaff [mailto:plo...@sa...] Sent: Wednesday, March 7, 2018 3:42 PM To: Paul Floyd; val...@li... Subject: Re: [Valgrind-developers] Valgrind on FreeBSD Hi Paul, In answer to a previous question of yours, I did use --enable-only64bit. Can you clone my repository, make the changes, then send me a pull request? Phil From: Paul Floyd [mailto:pj...@wa...] Sent: Sunday, March 4, 2018 5:07 AM To: val...@li...<mailto:val...@li...> Subject: Re: [Valgrind-developers] Valgrind on FreeBSD On 22 Feb 2018, at 23:33, Phil Longstaff <plo...@sa...<mailto:plo...@sa...>> wrote: 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...> [mailto:pa...@fr...] Sent: Thursday, February 22, 2018 3:32 PM To: val...@li...<mailto:val...@li...> Subject: Re: [Valgrind-developers] Valgrind on FreeBSD Hi Phil Some more feedback for other platforms. You’ve defined VKI_MAP_STACK in vki-freebsd.h (only) and added it to coregrind/m_aspacemgr/aspacemgr-linux.c without any conditional compilation. In coregrind/m_debuginfo/readelf.c around line 454 there looks like a code merge issue. The ‘#if !defined(VGO_freebsd) block looks spurious. coregrind/m_syswrap/syswrap-freebsd.c needs to be conditionally compiled. I added #if defined(VGO_freebsd) coregrind/m_syswrap/priv_types_n_macros.h has same changes for macOS around line 303 That’s all I needed to change on Linux. macOS and Solaris required quite a few more changes. Next, there are several linux conditional compilation blocks added to coregrind/m_syswrap/priv_syswrap-generic.h. I reverted all of them, and proceeded to make the minimum changes in sys wrap-generic.c where there are also many linux conditional compilation blocks. After that I was able to complete the build on all 3 platforms. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2018-03-08 07:51:59
|
> On 7 Mar 2018, at 22:28, Phil Longstaff <plo...@sa...> wrote: > > Before you do that, I created a bit of a merge mess in the freebsd branch and need to clean it up. > Hi Phil OK, let me know when you’ve done. A+ Paul |
|
From: Phil L. <plo...@sa...> - 2018-03-09 21:13:03
|
OK. I’m not completely up-to-date with today’s valgrind source changes, but please clone my repository and make your changes on the freebsd branch. From: Paul Floyd [mailto:pj...@wa...] Sent: Thursday, March 8, 2018 2:52 AM To: val...@li... Subject: Re: [Valgrind-developers] Valgrind on FreeBSD On 7 Mar 2018, at 22:28, Phil Longstaff <plo...@sa...<mailto:plo...@sa...>> wrote: Before you do that, I created a bit of a merge mess in the freebsd branch and need to clean it up. Hi Phil OK, let me know when you’ve done. A+ Paul |
|
From: Ed M. <em...@fr...> - 2019-01-02 04:56:45
|
On Fri, 9 Mar 2018 at 16:18, Phil Longstaff <plo...@sa...> wrote: > > OK. I’m not completely up-to-date with today’s valgrind source changes, but please clone my repository and make your changes on the freebsd branch. A quick status update - I've rebased the work in progress, fixed a few minor issues, and pushed to a 'freebsd.rebase' branch in the FreeBSD Foundation's GitHub repository, at https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.rebase Additional testing, as well as fixes for regression tests, are very welcome. The current diff is also available at https://people.freebsd.org/~emaste/valgrind/valgrind-freebsd-20190101.diff |
|
From: Philippe W. <phi...@sk...> - 2019-01-02 13:07:20
|
On Tue, 2019-01-01 at 23:56 -0500, Ed Maste wrote: > On Fri, 9 Mar 2018 at 16:18, Phil Longstaff <plo...@sa...> wrote: > > > > OK. I’m not completely up-to-date with today’s valgrind source changes, but please clone my repository and make your changes on the freebsd branch. > > A quick status update - I've rebased the work in progress, fixed a few > minor issues, and pushed to a 'freebsd.rebase' branch in the FreeBSD > Foundation's GitHub repository, at > https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.rebase > > Additional testing, as well as fixes for regression tests, are very welcome. > > The current diff is also available at > https://people.freebsd.org/~emaste/valgrind/valgrind-freebsd-20190101.diff That all looks like a big pile of work ! I hope it will be integrated ... To be discussed with Julian, and I guess the bottleneck will be the review bandwidth :(. I just scanned the diff very quickly, and as far as I can see, the changes in the common files looks usually small/isolated. At that stage, only a minor comment: as far as I can see, a bunch of files specific to freebsd were created by taking a copy of the linux files, but the header and trailer of these files still mention linux and/or an incorrect machine, which is confusing. For example, vki/vki-machine-types-amd64-freebsd.h starts with: +/*--- x86/Linux-specific kernel interface: posix types. ---*/ +/*--- vki_posixtypes-x86-linux.h ---*/ There are a bunch of other files to fix similarly, e.g. m_syswrap/syswrap-freebsd-variants.c, ... What is the status of the regression tests ? Note that to run a daily build+regression tests, if/when integrated upstream, you could possibly make use of the gcc compile farm. See https://cfarm.tetaneutral.net/machines/list/ Philippe |
|
From: Ed M. <em...@fr...> - 2019-01-08 02:54:25
|
On Wed, 2 Jan 2019 at 08:08, Philippe Waroquiers <phi...@sk...> wrote: > > That all looks like a big pile of work ! > I hope it will be integrated ... I certainly hope so. The current hurdle is addressing the test failures - I'll try to go through them and categorize the issues. Notes on some of what I've looked at so far: annotate_barrier.stderr.out +parse DIE(readdwarf3.c:3685): confused by: + <2><a8>: Abbrev Number: 9 (DW_TAG_subrange_type) + DW_AT_type : <b6> + DW_AT_count : 8 +parse_type_DIE: +WARNING: Serious error when reading debug info +When reading debug info from /usr/home/emaste/src/valgrind/drd/tests/annotate_barrier: +confused by the above DIE + This doesn't look FreeBSD-specific - perhaps missing support for DWARF info emitted by contemporary Clang? 65 .diff files contain 'Serious error when reading debug info' - by 0x........: (within libpthread-?.?.so) + by 0x........: ??? (in /lib/libthr.so.3) I'm not sure what prompts "within" vs "in" but the name of the thread library ought to be handled by a generic filter I suppose? This issue appears in 39 diff files. +Thread 3: +Conflicting load by thread 3 at 0x........ size 1 + at 0x........: ??? (in /lib/libthr.so.3) + by 0x........: pthread_exit (in /lib/libthr.so.3) + by 0x........: ??? (in /lib/libthr.so.3) +Allocation context: BSS section of libthr.so.3 It seems we end up with a number of cases of an extra conflicting thread. 34 diff files contain '^\+Conflicting load by thread' annotate_ignore_rw.stderr.out -Location 0x........ is 0 bytes inside global var "s_c" -declared at annotate_ignore_rw.c:12 +Allocation context: BSS section of annotate_ignore_rw leak-autofreepool-5.stderr.out -Memcheck: mc_leakcheck.c:... (vgMemCheck_detect_memory_leaks): the 'impossible' happened. +Memcheck: mc_leakcheck.c:... (void vgMemCheck_detect_memory_leaks(ThreadId, LeakCheckParams *)): the 'impossible' happened. none/tests/nocwd.stderr.diff +WARNING: unhandled amd64-freebsd syscall: 563 One test reported unhandled syscall, in this case getrandom. > To be discussed with Julian, and I guess the bottleneck will > be the review bandwidth :(. It's clear we have a ways to go in getting the test suite into shape. In parallel with that, I would really like to start working on understanding other requirements for upstreaming this, and on additional review. |
|
From: Ed M. <em...@fr...> - 2019-01-02 14:39:13
|
On Wed, 2 Jan 2019 at 08:08, Philippe Waroquiers <phi...@sk...> wrote: > ... >> https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.rebase > ... > > That all looks like a big pile of work ! > I hope it will be integrated ... > To be discussed with Julian, and I guess the bottleneck will > be the review bandwidth :(. Indeed, at least 30 people have contributed to maintaining this over the last fifteen years. One concern I had is that this has been maintained as a monolithic patch and isn't broken up into smaller changes, but I noticed that e.g. the Solaris port was added in a single commit (ac60633d) so presumably the same approach can be taken here. > I just scanned the diff very quickly, and as far as I can see, > the changes in the common files looks usually small/isolated. Thanks for the quick look. Indeed, the changes are mostly contained to FreeBSD; I did have to adjust two or three cases where these changes broke the build on non-FreeBSD. > At that stage, only a minor comment: as far as I can see, a bunch > of files specific to freebsd were created by taking a copy of the > linux files, but the header and trailer of these files still mention > linux and/or an incorrect machine, which is confusing. Indeed, I'll address those shortly. > What is the status of the regression tests ? There's some ways to go - Phil's recent results were: == 599 tests, 203 stderr failures, 68 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == > Note that to run a daily build+regression tests, if/when integrated > upstream, you could possibly make use of the gcc compile farm. > See https://cfarm.tetaneutral.net/machines/list/ Thanks. I have a machine which provides a buildbot for LLDB on FreeBSD and can probably build Valgrind on there too, but it's good to have additional options. |
|
From: Ivo R. <iv...@iv...> - 2019-01-02 15:31:31
|
> One concern I had is that this has been maintained as a monolithic > patch and isn't broken up into smaller changes, but I noticed that > e.g. the Solaris port was added in a single commit (ac60633d) so > presumably the same approach can be taken here. Ed, don't be fooled by this appearance. Solaris port was made available for review in several patches (I believe 8 or 9). The actual integration happened as one commit, yes, but review was done on the smaller patch files. I. |
|
From: Ed M. <em...@fr...> - 2019-01-03 15:55:33
|
On Wed, 2 Jan 2019 at 10:31, Ivo Raisr <iv...@iv...> wrote: > > Ed, don't be fooled by this appearance. > Solaris port was made available for review in several patches (I > believe 8 or 9). I've fixed up a few more issues, and started working on curating the changes into more reasonably reviewable pieces. Current WIP is in the "freebsd.20190103" branch - I'll try to keep the patch set rebased on upstream and will start a new branch when rebasing. https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.20190103 Work can be followed in PR 208531 https://bugs.kde.org/show_bug.cgi?id=208531 |
|
From: Ed M. <em...@fr...> - 2019-03-07 18:10:21
|
On Thu, 3 Jan 2019 at 10:55, Ed Maste <em...@fr...> wrote: > > Current WIP is in the "freebsd.20190103" branch - I'll try to keep the > patch set rebased on upstream and will start a new branch when > rebasing. FreeBSD patches are now rebased on upstream 3217459c, in the freebsd.20190307 branch: https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.20190307 Some of these are still changes to earlier patches in the set; the next step will be to curate the patch set into more reviewable pieces. > Work can be followed in PR 208531 > https://bugs.kde.org/show_bug.cgi?id=208531 Updated. |
|
From: Ed M. <em...@fr...> - 2019-02-14 18:45:32
|
On Wed, 2 Jan 2019 at 10:31, Ivo Raisr <iv...@iv...> wrote: > Solaris port was made available for review in several patches (I > believe 8 or 9). > The actual integration happened as one commit, yes, but review was > done on the smaller patch files. I'll continue to iteratively refine the patch set. One issue we're running into is that a lot of tests are failing because they encode specifics of the Linux environment (e.g., tests that look for specific shared object names and backtraces). How did the Solaris port address those? |
|
From: Ivo R. <iv...@iv...> - 2019-02-14 19:39:22
|
> One issue we're running into is that a lot of tests are failing > because they encode specifics of the Linux environment (e.g., tests > that look for specific shared object names and backtraces). How did > the Solaris port address those? After careful examination of a particular test failure, we chose the right thing(TM) from: 1. adjust an existing filter 2. create a new filter 3. create a new .exp file It was time consuming, indeed, but it also led to discovery of several problems in the port. I. |
|
From: Philippe W. <phi...@sk...> - 2019-02-14 21:04:04
|
On Thu, 2019-02-14 at 20:38 +0100, Ivo Raisr wrote: > > One issue we're running into is that a lot of tests are failing > > because they encode specifics of the Linux environment (e.g., tests > > that look for specific shared object names and backtraces). How did > > the Solaris port address those? > > After careful examination of a particular test failure, we chose the > right thing(TM) from: > 1. adjust an existing filter > 2. create a new filter > 3. create a new .exp file > > It was time consuming, indeed, but it also led to discovery of several > problems in the port. And IMO, it is better to do 1. if possible, otherwise 2., and only as a last resort 3. (as the maintenance of a bunch of different .exp files for a lot of tests is a nightmare). Philippe |