Other Valgrind reboot

Paul Floyd

Member

Reaction score: 10
Messages: 61

I had some free time on my hands recently, which is about to come to an end. During that time I worked on bringing Valgrind up to date on FreeBSD. 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.

My first big question is: is it worth trying to go further? Clang and GCC sanitizers can now do most of the things that Valgrind does, sometimes better and usually faster.

Here's a brief summary of the things that I've done. Firstly, the bulk of the code that I've been working on came from Phil Longstaff and Ed Maste (and perhaps others before them). I don't want to take their credit.

  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. Added libc++ to libraries that undergo symtab loading.
  4. Added a couple of syscall stubs.
There is an even bigger list of jobs to do
  • The x86 secondary build completes, but there seems to be a problem with the creation of the initial stack.
  • Test builds on older platforms, at least FreeBSD 11 and probably FreeBSD 10.
  • There are many 'regtest' failures, including ~10 hangs in Valgrind
  • Some of the above may be due to mmap errors (also present in the 3.10 ports version)
  • There are still many unsupported syscalls
  • I was building with GCC. When I switch to building with clang I get a few more problems - a couple of crashes and symtab loading problems again.
To start with I want to look at the hangs and the mmap issues.

Depending on the interest I see here, I'll keep you posted.
 
Last edited:

Nyantastic

Member

Reaction score: 9
Messages: 51

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.
 

Nyantastic

Member

Reaction score: 9
Messages: 51

Are you looking at things like this? There hasn't been any update on the Valgrind bugs which I'm aware of.
 
OP
OP
P

Paul Floyd

Member

Reaction score: 10
Messages: 61

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.
 

Nyantastic

Member

Reaction score: 9
Messages: 51

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.
 
OP
OP
P

Paul Floyd

Member

Reaction score: 10
Messages: 61

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).
 

Nyantastic

Member

Reaction score: 9
Messages: 51

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.
 
OP
OP
P

Paul Floyd

Member

Reaction score: 10
Messages: 61

I'm a bit of a github newbie, but try this


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.
 
Top