| Summary: | [PATCH]: FreeBSD support for valgrind | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Stanislav Sedov <stas> |
| Component: | general | Assignee: | Paul Floyd <pjfloyd> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bart.vanassche+kde, emaste, flo2030, freebsd, gharris, ivosh, kostikbel, pjfloyd, rakuco, swills, tom |
| Priority: | NOR | ||
| Version: | 3.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=433437 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
patch
Valgrind 3.5.0-4 FreeBSD diff (normal diff format) |
||
At the very end of the patch, you have:
#elif defined(VGO_darwin)
if ( 0 == strcmp( OS, "darwin" ) ) return True;
+#elif defined(VGO_freebsd)
+ if ( 0 == strcmp( OS, "darwin" ) ) return True;
+
Should that not be:
#elif defined(VGO_darwin)
if ( 0 == strcmp( OS, "darwin" ) ) return True;
+#elif defined(VGO_freebsd)
+ if ( 0 == strcmp( OS, "freebsd" ) ) return True;
+
I know nothing about how the patch works but this just looked like a copy & paste error to me. Thanks for putting in the effort and porting Valgrind!
That change has been incorporated now: http://p4db.freebsd.org/fileDiffView.cgi?FSPC=//depot/projects/valgrind/tests/os_test.c&REV=3&ACT=edit DRD should be also functional now, though gives a lot of false positives. I still need to come up with a reasonable suppression file. I'll attach the new patch with all changes incorporated later. Stanislav, has there been any progress on this one lately? Sure, we're still working on it. You can track the progress in FreeBSD perforce repository: http://p4web.freebsd.org/@md=d&cd=//depot/projects/&c=moY@//depot/projects/valgrind/?ac=83 I'll post the detailed status update soon. Created attachment 52723 [details]
Valgrind 3.5.0-4 FreeBSD diff (normal diff format)
Formatting change to switch perforce diff to regular diff format.
Isn't it possible to split the patch into smaller, logically separate ones so that it is easier to review them (and hopefully commit them)? FYI, work on the FreeBSD port has moved out of the FreeBSD Perforce repository to bitbucket.org to make it easier for others to follow the work: https://bitbucket.org/stass/valgrind-freebsd For reference here are some details of the current state of the patch: Added files: README_FREEBSD coregrind/m_coredumpcoredump-amd64-freebsd.c coregrind/m_coredumpcoredump-x86-freebsd.c coregrind/m_dispatchdispatch-amd64-freebsd.S coregrind/m_dispatchdispatch-x86-freebsd.S coregrind/m_initimginitimg-freebsd.c coregrind/m_sigframesigframe-amd64-freebsd.c coregrind/m_sigframesigframe-x86-freebsd.c coregrind/m_syswrappriv_syswrap-freebsd.h coregrind/m_syswrapsyscall-amd64-freebsd.S coregrind/m_syswrapsyscall-x86-freebsd.S coregrind/m_syswrapsyswrap-amd64-freebsd.c coregrind/m_syswrapsyswrap-freebsd-variants.c coregrind/m_syswrapsyswrap-freebsd.c coregrind/m_syswrapsyswrap-x86-freebsd.c coregrindlauncher-freebsd.c coregrindlink_tool_exe_freebsd.in freebsd.supp getpath include/vkivki-amd64-freebsd.h include/vkivki-freebsd.h include/vkivki-machine-types-amd64-freebsd.h include/vkivki-machine-types-x86-freebsd.h include/vkivki-scnums-freebsd.h include/vkivki-x86-freebsd.h memcheck/tests/amd64xor-undef-amd64.stderr.exp-freebsd memcheck/testssigkill.stderr.exp-freebsd none/testsshell.stderr.exp-freebsd none/testsshell.stdout.exp-freebsd none/testsshell_dir.stderr.exp-freebsd Changes: Makefile.all.am | 13 Makefile.am | 1 Makefile.tool.am | 24 + autogen.sh | 2 cachegrind/tests/Makefile.am | 2 callgrind/tests/Makefile.am | 2 configure.in | 93 ++++ coregrind/Makefile.am | 18 coregrind/m_aspacemgr/aspacemgr-common.c | 64 ++- coregrind/m_aspacemgr/aspacemgr-linux.c | 115 +++++ coregrind/m_coredump/coredump-elf.c | 143 +++++-- coregrind/m_debugger.c | 6 coregrind/m_debuginfo/d3basics.c | 4 coregrind/m_debuginfo/debuginfo.c | 14 coregrind/m_debuginfo/readdwarf.c | 8 coregrind/m_debuginfo/readdwarf3.c | 4 coregrind/m_debuginfo/readelf.c | 39 + coregrind/m_debuginfo/readpdb.c | 5 coregrind/m_debuginfo/readstabs.c | 7 coregrind/m_debuginfo/storage.c | 6 coregrind/m_debuglog.c | 92 ++++ coregrind/m_libcassert.c | 6 coregrind/m_libcfile.c | 95 +++- coregrind/m_libcproc.c | 105 +++++ coregrind/m_libcsignal.c | 133 ++++++ coregrind/m_machine.c | 25 + coregrind/m_main.c | 77 +++ coregrind/m_redir.c | 2 coregrind/m_scheduler/scheduler.c | 3 coregrind/m_signals.c | 80 +++ coregrind/m_stacktrace.c | 4 coregrind/m_syscall.c | 128 ++++++ coregrind/m_syswrap/priv_syswrap-generic.h | 16 coregrind/m_syswrap/priv_types_n_macros.h | 63 ++- coregrind/m_syswrap/syswrap-generic.c | 70 +++ coregrind/m_syswrap/syswrap-main.c | 322 +++++++++++++++- coregrind/m_trampoline.S | 84 +++- coregrind/m_translate.c | 3 coregrind/m_ume/elf.c | 104 +++-- coregrind/m_ume/main.c | 2 coregrind/m_ume/priv_ume.h | 4 coregrind/m_vki.c | 4 coregrind/m_vkiscnums.c | 15 coregrind/pub_core_aspacemgr.h | 4 coregrind/pub_core_debuginfo.h | 2 coregrind/pub_core_initimg.h | 40 - coregrind/pub_core_libcproc.h | 8 coregrind/pub_core_machine.h | 4 coregrind/pub_core_mallocfree.h | 2 coregrind/pub_core_sigframe.h | 5 coregrind/pub_core_syscall.h | 2 coregrind/pub_core_trampoline.h | 8 coregrind/pub_core_vkiscnums.h | 3 coregrind/vg_preloaded.c | 2 drd/drd_main.c | 2 drd/tests/Makefile.am | 6 exp-ptrcheck/h_main.c | 6 exp-ptrcheck/pc_main.c | 5 exp-ptrcheck/tests/Makefile.am | 7 helgrind/hg_intercepts.c | 107 +++++ helgrind/hg_main.c | 3 helgrind/tests/tc07_hbl1.c | 9 helgrind/tests/tc08_hbl2.c | 9 helgrind/tests/tc11_XCHG.c | 9 helgrind/tests/tc17_sembar.c | 11 helgrind/tests/tc20_verifywrap.c | 2 helgrind/tests/tc23_bogus_condwait.c | 11 helgrind/tests/tc24_nonzero_sem.c | 9 include/Makefile.am | 4 include/pub_tool_basics.h | 32 + include/pub_tool_basics_asm.h | 2 include/pub_tool_machine.h | 4 include/pub_tool_redir.h | 16 include/pub_tool_vki.h | 2 include/pub_tool_vkiscnums.h | 5 include/pub_tool_vkiscnums_asm.h | 3 include/valgrind.h | 16 lackey/Makefile.am | 1 memcheck/mc_replace_strmem.c | 52 ++ memcheck/tests/Makefile.am | 3 memcheck/tests/addressable.c | 4 memcheck/tests/addressable.stderr.exp | 49 -- memcheck/tests/amd64/Makefile.am | 2 memcheck/tests/amd64/more_x87_fp.c | 4 memcheck/tests/badjump2.c | 3 memcheck/tests/buflen_check.c | 1 memcheck/tests/memalign2.c | 5 memcheck/tests/mempool.c | 6 memcheck/tests/noisy_child.stderr.exp | 17 memcheck/tests/pointer-trace.c | 4 memcheck/tests/pointer-trace.stderr.exp | 2 memcheck/tests/sh-mem-random.c | 2 memcheck/tests/str_tester.c | 26 - memcheck/tests/x86/more_x86_fp.c | 2 mpi/Makefile.am | 6 none/tests/Makefile.am | 4 none/tests/amd64/bug156404-amd64.c | 4 none/tests/amd64/insn_ssse3.vgtest | 2 none/tests/amd64/ssse3_misaligned.vgtest | 2 none/tests/closeall.c | 2 none/tests/execve.stderr.exp | 3 none/tests/faultstatus.c | 2 none/tests/fdleak_cmsg.c | 1 none/tests/fdleak_socketpair.c | 1 none/tests/map_unaligned.c | 4 none/tests/mq.c | 1 none/tests/pth_atfork1.c | 4 none/tests/resolv.c | 1 none/tests/rlimit_nofile.c | 1 none/tests/sem.c | 1 none/tests/shell | 3 none/tests/sigstackgrowth.c | 2 none/tests/x86/faultstatus.c | 4 none/tests/x86/insn_ssse3.vgtest | 2 none/tests/x86/ssse3_misaligned.vgtest | 2 perf/bigcode.c | 2 perf/tinycc.c | 2 tests/arch_test.c | 4 tests/filter_discards | 2 tests/malloc.h | 4 tests/os_test.c | 4 tests/sys_mman.h | 2 As mentioned before a lot of the small change counts are things like -#if defined(VGO_linux) || defined(VGO_darwin) +#if defined(VGO_linux) || defined(VGO_darwin) || defined(VGO_freebsd) All of that said - yes, in order to prepare this for committing upstream we will need to break this out into a form that's easier to review. JFYI, we updated the FreeBSD version of valgrind to 3.6.1 and fixed some minor and major issues found (unhandled syscalls, setcontext/getcontext misbehavior, etc). You can grab the new version in FreeBSD ports, or at https://bitbucket.org/stass/valgrind-freebsd, where our repository is hosted. The diff agains the mainline can be retrieved from there too. Is anyone here interested in working with us to integrate our patches into the mainline? It's certianly stable enough (we can run big applications like Firefox, ruby without any issues), and doesn't touch a lot in the common code (mostly it's FreeBSD specific platform files). What kind of help do you need? I'm just a FreeBSD user with no contact with the valgrind developers, but I'd like to help in any possible way. What you can do to help: - Test the FreeBSD port as each new version comes out and report any problems you see on your apps - Demonstrate to the Valgrind developers that there is a broad base of users who want to use Valgrind on FreeBSD - Vote this bug up (it's currently the highest-voted Valgrind issue on bugs.kde.org I believe) Thanks Ed (In reply to comment #11) > What you can do to help: > I worked on the s390x port which was added earlier this year. In my experience the following helped (no promises though): (1) Post the patch here. (2) Keep changes to the common code to a minimum. It's OK to have #ifdef's in places where the other OSes have them. #ifdef's elsewhere are a different story. (3) Add testcases. I would add that I doubt adding votes to the bug will achieve anything. As far as I know nobody pays any attention to the vote count. In fact I've never found any open source project which supports "votes" on bugs where the votes are paid attention to. The reason I suggested marking it with a vote is just to demonstrate the level of interest in Valgrind on FreeBSD. I've heard the comment in the past that there's a belief that there is not much interest in running Valgrind on FreeBSD, and that is definitely not the case. > (1) Post the patch here. Patches have been posted at various points over the last two years, and referenced in the mailing lists. There are some 30 new files and about 130 files with changes. Shall we start posting the diffs themselves to the devel mailing list? > (2) Keep changes to the common code to a minimum. It's OK to have #ifdef's in places where the other OSes have them. #ifdef's elsewhere are a different story. Of course, that is in general what's been done with this port. If there are any cases where this isn't true we will clean them up. > (3) Add testcases. With your experience with the s390x port can you comment on the types of testcases that needed to be added (were not covered by the existing valgrind test suite)? On 09/11/11 02:11, Ed Maste wrote:
>> (3) Add testcases.
>
> With your experience with the s390x port can you comment on the types of
> testcases that needed to be added (were not covered by the existing valgrind
> test suite)?
Being NOT a maintainer, I add my 2 cents as well_
The "covered by" is a good indicator.
I would start with testcases for any supported system call that is not
available on Linux or system calls with different behaviours:
- calling conventions
- return parameters
- different behaviour (I know there are some differences between bsd and sysV)
In addition, you should be able to use most instruction tests, but
please inspect all testcase failures and start fixing testcases or the port
(You might also want to post the testsuite results here).
Christian
Does stuff like this mean that the FreeBSD port is incomplete ? --- //depot/vendor/valgrind/callgrind/tests/Makefile.am.orig +++ //depot/vendor/valgrind/callgrind/tests/Makefile.am @@ -17,7 +17,11 @@ notpower2-use.vgtest notpower2-use.stderr.exp \ threads.vgtest threads.stderr.exp -check_PROGRAMS = clreq simwork threads +check_PROGRAMS = clreq simwork + +if !VGCONF_PLATFORMS_INCLUDE_X86_FREEBSD +check_PROGRAMS += threads +endif AM_CFLAGS += $(AM_FLAG_M3264_PRI) AM_CXXFLAGS += $(AM_FLAG_M3264_PRI) And why has the change below been made ? As far as I can see $(EGREP) doesn't occur anywhere. --- //depot/vendor/valgrind/configure.in.orig +++ //depot/vendor/valgrind/configure.in @@ -39,6 +39,7 @@ # AC_SUBST([OBJCFLAGS]) # ]) AC_PROG_RANLIB +AC_PROG_EGREP # If no AR variable was specified, look up the name of the archiver. Otherwise # do not touch the AR variable. And why has AC_PATH_PROG(SED, sed) been added ? AC_PROG_SED is already present in configure.in. +# find sed +AC_PATH_PROG(SED, sed) + Another note:(In reply to comment #0) > It's now against version 3.5.0, but I can update it to HEAD at any > moment. Maybe you should better do that - 3.5.0 is so old that it isn't worth to spend time reviewing a patch that is based on 3.5.0. Many of the configure.in changes fail to apply on the trunk by the way. > Maybe you should better do that - 3.5.0 is so old that it isn't worth to spend > time reviewing a patch that is based on 3.5.0. Many of the configure.in changes > fail to apply on the trunk by the way. The port was done against 3.5.0 two years ago; the current port is against 3.7.0. Stanislav's maintaining the FreeBSD port in Mercurial on bitbucket, at: https://bitbucket.org/stass/valgrind-freebsd/changesets We'll regenerate diffs for review. Hi, Bart! Thanks a lot for you comments. We'we working on finishing the 3.7.0 port right now, where some of this stuff will be gone. The FreeBSD port is not complete in the sense that some of valgrind parts are not working yet (exp-ptrcheck being one example, but it seems it's gone now). We're ready to address all this limitations and do the diff cleanup (there're still some places where our diff touches the common code, which probably should be ifdef'ed at least initially) if there's any interest in merging our code. I will post the new diff as soon as it's fully tested. Thanks! Current state of the test suite: == 497 tests, 169 stderr failures, 11 stdout failures, 0 stderrB failures, 0 stdoutB failures, 3 post failures == The reported failures break down as follows: 19 memcheck 2 massif 16 none 44 helgrind 98 drd 2 exp-sgcheck 1 exp-bbv (In reply to comment #20) > Current state of the test suite: > > == 497 tests, 169 stderr failures, 11 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 3 post failures == > > The reported failures break down as follows: > > 19 memcheck > 2 massif > 16 none > 44 helgrind > 98 drd > 2 exp-sgcheck > 1 exp-bbv All DRD tests pass on the currently supported systems, so there must be something wrong with the FreeBSD port. On Mon, Nov 14, 2011 at 06:44:00PM +0000, Bart Van Assche wrote:
> All DRD tests pass on the currently supported systems, so there must be
> something wrong with the FreeBSD port.
I haven't looked at the drd ones yet, but the first 30 or so results
I have investigated are false positive failures - i.e., the output
when run on FreeBSD doesn't match what's expected, but the functionality
itself works.
(In reply to comment #22) > On Mon, Nov 14, 2011 at 06:44:00PM +0000, Bart Van Assche wrote: > > > All DRD tests pass on the currently supported systems, so there must be > > something wrong with the FreeBSD port. > > I haven't looked at the drd ones yet, but the first 30 or so results > I have investigated are false positive failures - i.e., the output > when run on FreeBSD doesn't match what's expected, but the functionality > itself works. Adding support for FreeBSD on the trunk means setting up a nightly build server for FreeBSD too such that developers who write and test patches on Linux have a way to verify that nothing breaks on FreeBSD. The output of the nightly build script for FreeBSD will be worthless unfortunately with so many known failures. On Wed, Nov 16, 2011 at 05:05:24PM +0000, Bart Van Assche wrote:
> Adding support for FreeBSD on the trunk means setting up a nightly build
> server for FreeBSD too such that developers who write and test patches on
> Linux have a way to verify that nothing breaks on FreeBSD. The output of
> the nightly build script for FreeBSD will be worthless unfortunately with
> so many known failures.
Thanks for the comment Bart. We're committed to getting the test suite
into good shape in order to have a candidate ready for committing to
SVN trunk. The goal in trying to engage now to flesh out the roadmap on
getting the patches ready for a smooth integration.
On this specific topic of the nightly build server, I've had a look at
bin/nightly and I'm thinking of getting it to run against our downstream
repo for now as we clean up the test failures. (Extending the script to
check out from a Hg repo on bitbucket.org instead.) I also want to start
running the regression suite with a checkout of our tree on Linux to
ensure we're not breaking anything.
Do you have additional suggestions for the process?
Thanks,
Ed
(In reply to comment #24) > Do you have additional suggestions for the process? There are some changes that affect the Linux build. These should be explained (e.g. increasing the number of reserved FDs and the VKI_SIGSYS changes). Also, I think you should address the remaining to-do items in your patch, e.g. +# elif defined(VGO_freebsd) +# warning "Needs love" Stanislav, Ed et al, Has there been any progress recently on fixing the remaining issues on FreeBSD port [1]? I see the last commit dates 2016-01-13, more than 1,5 years ago. Perhaps the port has moved somewhere else? [1] https://bitbucket.org/stass/valgrind-freebsd/ *** Bug 368873 has been marked as a duplicate of this bug. *** Current work is in progress at https://github.com/freebsdfoundation/valgrind. The most up-to-date branch is freebsd.rebase, https://github.com/freebsdfoundation/valgrind/tree/freebsd.rebase. (In reply to Bart Van Assche from comment #16) > -check_PROGRAMS = clreq simwork threads > +check_PROGRAMS = clreq simwork > + > +if !VGCONF_PLATFORMS_INCLUDE_X86_FREEBSD > +check_PROGRAMS += threads > +endif This is no longer in the patchset. tsan_unittest is disabled on FreeBSD in the patch though: +if !VGCONF_OS_IS_FREEBSD +check_PROGRAMS += tsan_unittest endif > And why has the change below been made ? As far as I can see $(EGREP) > doesn't occur anywhere. > > --- //depot/vendor/valgrind/configure.in.orig > +++ //depot/vendor/valgrind/configure.in > @@ -39,6 +39,7 @@ > # AC_SUBST([OBJCFLAGS]) > # ]) > AC_PROG_RANLIB > +AC_PROG_EGREP Does it get used implicitly by AC_EGREP_CPP perhaps? I also see a ${EGREP} use in setting xpg_present. > And why has AC_PATH_PROG(SED, sed) been added ? AC_PROG_SED is already > present in configure.in. This one has been removed. I believe the specific points raised in previous comments have been addressed. On the mailing list Philippe Waroquiers reported that many files based on a Linux version still have the old filename in header comments etc., will address those soon. Regtest results as of today: == 599 tests, 203 stderr failures, 68 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == 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 Two questions: - link_tool_exe_freebsd.in is a copy of older link_tool_exe_linux.in. Our toolchain is GNU-compatible and link_tool_exe_linux.in will probably work out of the box on FreeBSD. For cases like this should we share the script (perhaps renaming it)? - tests/filter_libc starts with #! /usr/bin/perl -w which does not work on FreeBSD (perl is /usr/local/bin/perl). Should this be renamed to tests/filter_libc.in and start with #! @PERL@ ? Rebased patch set in https://github.com/FreeBSDFoundation/valgrind/tree/freebsd.20190307 Over 10 years since this item was opened and it's my turn to take a stab at getting it done. Here a couple of sample results (best and worst) GCC on amd64 configured with -O0 == 714 tests, 19 stderr failures, 5 stdout failures, 1 stderrB failure, 3 stdoutB failures, 0 post failures == clang on x86 == 648 tests, 69 stderr failures, 4 stdout failures, 4 stderrB failures, 4 stdoutB failures, 1 post failure == Stuff that's been fixed ~~~~~~~~~~~~~~~~~~~~~~~ FreeBSD 11.1 added a ~64MB MAP_GUARD region below the user stack which was breaking the address space manager on x86. For x86 on amd64 there was a failure arising from Valgrind not fully synthesizing auxv for the guest combined with a bug in rtld. That took a long time to hunt down. x86 sigreturn was broken. Debug output never worked on x86 and caused crashes on amd64. There were several redir errors in drd and helgrind. Added ~ 20 syscalls. Remaining problems ~~~~~~~~~~~~~~~~~~ The number one remaining issue is with signal delivery, and it's worse on x86. Some of the clang failures that I've looked at are due to the codegen. In a couple of cases I saw that clang used cmov opcodes rather then test/jmp used by GCC. I need to look ore at things like varinfo differences. The default suppression file is pretty noisy with plain old libc functions. If I run 'ps' under memcheck then I get a bunch of 'Conditional jumps' in strlen and strvis. Qt apps could also do with some attention. Not enough regtests yet. I've only added 7 I think. I definitely need to add a 'scalar' test. Other stuff ~~~~~~~~~~~ There are a few other issues, but I might be able to live with them as known limitations. I've tried to clean out the diffs in common source files as much as possible, but there's still some work to do. I have been fairly heavy handed in modifying test scripts that use sed, and should probably make .in files and a configure time AC_CONF_SED. Next steps ~~~~~~~~~~ Before any talk of patches or code reviews: I'd like to deal with the signal issues on x86, but that does not look easy. The issues with clang need to be all analyzed, since this is the system compiler. Test, test, test. My github repo is here https://github.com/paulfloyd/freebsd_valgrind Some gory details, part 1. In the FreeBSD world, normally there are 2 active release streams (currently 11 and 12) and one development stream (currently 13). The system compiler is clang, with GCC as an optional install. Whilst other architectures are supported by FreeBSD, amd64 and x86 are the only two that work with Valgrind. x86 (i386 in the FreeBSD world) is still fairly widely used. My primary build/test work is all on FreeBSD 12.1. I started with amd64/GCC but now I'm concentrating on amd64/clang. I also build and test on x86/clang and x86/gcc. I occasionally do builds on FreeBSD 11.3. Here are some regtest results that I'm currently getting, and some analysis of the failures. More analysis here https://github.com/paulfloyd/freebsd_valgrind/issues amd64/clang == 725 tests, 22 stderr failures, 1 stdout failure, 1 stderrB failure, 0 stdoutB failures, 0 post failures == memcheck/tests/leak* (4 fails) There's a discrepancy with clang between the client request report and the final report. WIP. drd/tests/omp (3 fails) Many errors, not fully analysed. clang support for OpenMP seems fairly weak. memcheck/tests/varinfo6 (+1 similar) drd/tests/tc04_free_lock Issue with getting varinfo, error line number printed as 0 drd/tests/dlopen Hits an assert setting pthreadid, possibly related to the special handling that was required for dlopen on Solaris. memcheck/tests/descr_belowsp Error message doesn't mention guard page. Needs different guard page detection heuristics? memcheck/tests/gone_abrt_xml helgrind/tests/tc22_exit_w_lock There's a hack for stacktraces without function call prologs that doesn't work in these 2 cases. gdbserver_tests/mcinfcallWSRU Line number diffs in stderrB. Looks harmless. memcheck/tests/amd64/insn-pmovmskb Looks like clang optimization won the day with this testcase. Missing error messages and changes in order. memcheck/tests/clientperm Looks like clang optimization of branches. helgrind/tests/tls_threads (+ drd) Hard problem. On Linux this relies on spying on libc variables for tls. That doesn't work with non-GCC FreeBSD libc. helgrind/tests/pth_cond_destroy_busy One missing error message helgrind/tests/tc22_exit_w_lock drd/tests/std_list A load of locale errors. drd/tests/atomic_var Missing varinfo details none/tests/amd64/ssse3_misaligned SIGSEGV in host :-( none/tests/rlimit_nofile Only fails when I'm on KDE because of an extra krunner socket. Gory details part 2. x86/clang, this is the worst case. == 668 tests, 32 stderr failures, 2 stdout failures, 3 stderrB failures, 1 stdoutB failure, 0 post failures == Mostly the same as amd64/clang none/tests/sigsusp Testcase hangs :-( We try to clear the VGKILL bit in the syswrap, but for some reason that is failing (perhaps because the mask is const). none/tests/manythreads Fails after 8192 threads have run. Don't know why yet. gdbserver_tests/nlpasssigalrm SIGSEGV in host. Problem with correct construction of sigframe. none/tests/pth_self_kill_15_other drd/tests/sigalrm More SIGSEGVs in host. drd/tests/concurrent_close (4 cases in total) drd/tests/annotate* Extra conflicting loads Gory details, part 3. Last for the moment. Good news for any FreeBSD users compiling with GCC on amd64: == 735 tests, 7 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == I won't dwell on that since clang is the priority. The full git diff --stat output is too scary to copy in its entirety. Here is the last line 498 files changed, 107880 insertions(+), 1377 deletions(-) I will work on removing as many gratuitous differences as possible, but at the same time I'm adding regression tests, so I'm afraid this is just going to get bigger. Finally, syscall and test coverage. I reckon that FreeBSD 12.1 has 363 syscalls (not counting obsolete ones). 75 of these are covered by generic syscalls, 287 specific to FreeBSD. 43 of these are unimplemented. There are tests for at least 77 of these syscalls, plus a full scalar test. clang/x86 none/tests/sigsusp no longer hangs :-) That 'only' leaves a couple of segfaults and client requests with clang as serious problems on FreeBSD 12.1. That's it. The Beastie has landed. Champagne tonight. FreeBSD is now part of the official Valgrind code. When 3.18 is out I'll update the FreeBSD port (devel/valgrind) to point to the offical tarball. |
Created attachment 37173 [details] patch Hello! The patch attached adds FreeBSD support for valgrind. It's now against version 3.5.0, but I can update it to HEAD at any moment. Most of the tools testes and work fine, helgrind and drd still needs some work (the first one gives excessive false positives, and DRD doesn't work currently at all). There're also some changes in the patch that will influence other platforms as well, I can ifdef them if/when needed.