Solved Valgrind reboot

P

Paul Floyd

My github repo is here

github.com

GitHub - paulfloyd/freebsd_valgrind: Git repo used to Upstream the FreeBSD Port of Valgrind

Git repo used to Upstream the FreeBSD Port of Valgrind - paulfloyd/freebsd_valgrind
github.com github.com

I'd appreciate any feedback from anyone that can build and try the tools.

I've been working on bringing Valgrind up to date on FreeBSD. That's up to data as in being based on the main Valgrind git repo HEAD code, what is currently just after Valgrind 3.16.1. There have been various attempts over the past few years to bring back FreeBSD support. I don't know all of the details, but the FreeBSD port seems to have kept up between about versions 3.5 and 3.10. The FreeBSD ports system contains Valgrind 3.10 with the occasional patch to fix things. Currently the ports version is pretty much useless on current (12.1) FreeBSD. It builds and it runs but 'memcheck' cannot detect any dynamic memory errors. i386 doesn't even run.

Here's a brief summary of the things that I've done.
  1. Updated the build. New syscalls and 'stat' structures in FreeBSD 12 broke a few things.
  2. Fixed symtab loading due to extra read-only PT_LOAD ELF segments. This was the cause of not seeing dynamic memory issues.
  3. Analyzed and resolved many clang related issues.
  4. Added libc++ to libraries that undergo symtab loading.
  5. Added about 40 more syscalls
  6. Removed some obsolete syscalls
  7. i386 is now working which involved a difficult workaround for a bug in rtld
  8. Added FreeBSD 11 support, also builds on FreeBSD 10
  9. All hangs resolved on amd64, one remaining on i386
  10. Analyzed most of the regression tests and updated either testcases or results files.
  11. DRD and Helgrind both work reasonably well.
Things still need doing
  • Signal handling does not work correctly, particularly on i386
  • Adding more FreeBSD specific regression tests
  • Getting clean default suppressions that filter non-issues in libc but don't result in user false negatives
  • Cleaner handling of applications using capsicum or chroot
 
Last edited:
Just to give some feedback, I really appreciate your work so far, and it would be very useful for me if you could make it work. My particular problem is that it completely fails on FreeBSD 11 with a 32 bit system. I'm switching over to Go as the main programming language for my application but I still need to debug the old C version, and valgrind used to be a very useful tool for that.
 
I will be looking at adding missing syscalls, but my priority is going to be a) getting x86 to work b) getting optimized clang builds to work and c) seeing if there are any "easy" fixes for the 200 or so failures in the regression tests.
 
Thank you for your efforts.
I have basic C programming skills, and I can contribute time to getting this to work, so let me know if you have some project you'd like me to do.
 
Thanks for the offer. Valgrind is a difficult beast, but I expect that there will be ways that you can help.

To give you an idea of the problem with getting x86 to work, here is an outline of the problem.
  • Unlike normal C applications, Valgrind doesn't start with "main()". Rather it starts with some assembler that creates a separate stack which it then uses with "_start_in_C_freebsd", the C entry point which is just a wrapper for "valgrind_main"
  • Also unlike normal C programs, Valgrind does not use any functions from the C standard library. It is statically linked and has to re-implement everything it needs. It also has to do a lot of the low level actions like reading the ELF data structures of the client application that it is testing and load everything into memory.
  • Valgrind has to maintain its own memory space and also the memory space of the client application. The memory space of the client needs to conform to what FreeBSD expects.
  • At the point of failure, Valgrind is trying to map the client's stack into memory. It should find some free memory, but it is getting memory that is reserved for Valgrind itself. When it sees that it exits with a message.
I don't (yet) know what caused this to break. Currently I'm debugging this on FreeBSD 12.1 and also on Linux (to have a working reference, even though there are significant differences between the two). I'd like to set up some older FreeBSD VMs (11, 10 and 9 to go back as far as when GCC was the system compiler).
 
I'm using the latest FreeBSD 11 so I can test it for you on that. One machine is 86 and the other is 64 bit. I can't offer access to the machines though. The valgrind that I used in those tests mentioned in the bug reports is valgrind-3.13.0 for FreeBSD.

Do you have a github repository or something like that?

My github is https://github.com/benkasminbullock, and my email is <githubname> @gmail.com.
 
I'm a bit of a github newbie, but try this

github.com

GitHub - paulfloyd/freebsd_valgrind: Git repo used to Upstream the FreeBSD Port of Valgrind

Git repo used to Upstream the FreeBSD Port of Valgrind - paulfloyd/freebsd_valgrind
github.com github.com

For the moment I get better results with GCC, just make sure you have GCC installed and follow the README.

clang builds sort of work. When I turn on optimizations I get crashes but

configure CFLAGS="-g -O0" CC=clang

works, at least minimally.

Nothing is working currently on x86. When you do a build on amd64, it will do two builds, the primary one for amd64 and a secondary one for x86. If you build on x86 then it will only do one build, x86.

I'll try to add a specific FreeBSD README with build instructions and a list of issues/limitations.
 
I'd just like to say that the valgrind reboot so far is looking very good. It is already working correctly on my FreeBSD 11 / x86 system, and things seem to be back in order. Thank you Paul Floyd for your work here.
 
You must log in or register to reply here.
Back
Top