C++ Valgrind feature poll

Which feature(s) would you like to see added to Valgrind?

  • lldb server

    Votes: 2 16.7%

  • fair scheduler

    Votes: 1 8.3%

  • arm7 support

    Votes: 2 16.7%

  • riscv64 support

    Votes: 0 0.0%

  • LLVM OpenMP support

    Votes: 1 8.3%

  • better ioctl coverage

    Votes: 5 41.7%

  • proper FreeBSD core dumps

    Votes: 5 41.7%
  • Total voters
    12
P

Paul Floyd

Some explanation of these choices.
FeatureDifficultyDescription
lldb serverunknown, but probably a large projectcurrently Valgrind only has support for gdb server (with the bundled vgdb tool). lldb server is possible but difficult to set up and only for lldb experts
fair schedulereasythe default Valgrind scheduler will context switch at each syscall or 100k basic blocks, but the switching is just the luck of the draw. Linux (only) has a futex based fair scheduler that it supposed to be more like a real OS scheduler
LLVM openMPunknown, but probably a large projectDRD and Helgrind only understand pthread and Qt threading interfaces. GNU OpenMP can be built using pthread. Valgrind does not understand LLVM OpenMP synchronisation at all, making it impossible to use with DRD or Helgrind.
ioctlslarge, needs a lot of investigation to get a list of all ioctls and all of their inputs and outputsonly a few have proper coverage, most just default to the read/write encoding of the ioctl
core dumpsmediumValgrind will dump a FreeBSD core file but the internals are not correct and neigher gdb nor lldb will be able to do anything with it
riscv64/arm7 portsmediumarm64 took about 1 month
 
cracauer@ said:
What does valgrind do with ioctls?
Click to expand...
Like all syscalls it
  • checks the arguments are initialised
  • for pointers to memory that the ioctl will read, checks that the memory is valid and initialised
  • for pointers to memory that the ioctl will write, checks that the memory is valid and marks it as initialised (if the ioctl succeeds)
Right now only 7 have specific support and some of those are only partially supported (e.g. CAMIOCOMMAND).
 
vmisev said:
I, for one, had to google “Valgrind” to see what this is about – never even heard about it before 🤷‍♂️
Click to expand...
It's an amazing tool, and we have Mr. Dr. Floyd to thank for Freebsd support. I've used it for basic crash debugging, albeit not recently.
 
Last edited:
Jose said:
It's an amazing tool, and we have Mr. Floyd to thank for Freebsd support. I've used it for basic crash debugging, albeit not recently.
Click to expand...
That’s what I love about FreeBSD, I can never get too old to be surprised with something new and amazing. I’ll try to learn more about it; thanks Paul Floyd 🙏
 
Jose said:
I really have no idea. Help me choose.
Click to expand...
Are you a userland developer in C or C++ (or even Rust or Ada and maybe even Go)? Do you debug crashes or similar issues? Do you run CI tests?

In most of these cases you should learn how to use Valgrind (and the sanitizers).
 
cracauer@ said:
WHat does "fair scheduler" mean in the context of Valgrind?
Click to expand...

Currently Valgrind on FreeBSD only has the default scheduler, which is no scheduling really.

Valgrind has a global lock, implemented by writing to and reading from a pipe. Blocked threads are trying to read from the pipe. When the running thread releases the lock (either to perform a guest syscall or because it has used up its execution slot) then it writes one ASCII letter to the pipe.

It's then a matter of luck as to which of the blocked threads succeeds in reading that letter. There's no form of priority. There may be situations where the same thread keeps getting the lock, starving other threads.

The fair scheduler is supposed to do some proper scheduling and avoid thread starvation.
 
I chose better ioctl coverage because it seems some folks in this thread would find it useful and it's the most Freebsd-specific thing that would not be a ton of work.

  • lldb server: much as I would like to be rid of GNU tools, this one seems like a lot of work for not much reward.
  • fair scheduler: if the thing is going to crash, it's likely to crash regardless of how the threads are scheduled. Besides, if it's really a threading issue, you can Valgrind it in Linux and find out. In any case, I suspect Mr. Dr. Floyd will do this anyway 'cause it's easy for him :)
  • LLVM openMP: Sounds awesome, but again, it can be debugged in Linux since it's multi-platform by design. Gotta choose your battles when you're a minor platform.
  • core dumps: If your thing dumps core, it probably dumps core even when it's not being run under Valgrind.
  • riscv64/arm7 ports: A close second. Both of these are minor platforms right now. One is likely on the way out, and the other is maybe on its way in. Either way, there's time to decide.
 
Last edited:
Jose said:
I chose better ioctl coverage because it seems some folks in this thread would find it useful and it's the most Freebsd-specific thing that would not be a ton of work.

  • lldb server: much as I would like to be rid of GNU tools, this one seems like a lot of work for not much reward.
Click to expand...

This would also benefit Linux LLVM users (and macOS if ever we can get the macOS port back to being tier 1).

Jose said:
  • fair scheduler: if the thing is going to crash, it's likely to crash regardless of how the threads are scheduled. Besides, if it's really a threading issue, you can Valgrind it in Linux and find out. In any case, I suspect Mr. Floyd will do this anyway 'cause it's easy for him :)
Click to expand...

It's more likely just to hang. And easy is all relative.

Jose said:
  • LLVM openMP: Sounds awesome, but again, it can be debugged in Linux since it's multi-platform by design. Gotta choose your battles when you're a minor platform.
Click to expand...

Again this would also benefit Linux (and eventually macOS).
 
You must log in or register to reply here.
Back
Top