Discuss any kind of possible improvement (technical or functional) to Valgrind.

If you want to put something on the agenda please send a small description (one or two paragraphs) to the the moderator Mark Wielaard mjw@redhat.com with in the subject: "FOSDEM devroom discuss: ..." If you want to discuss a somewhat larger topic please do feel free to send two or three slides in advance.

Mark will collect ideas/suggestions/... and present these and coordinate the discussion (and keep track of the time, so every idea will be discussed).

Suggested discussion topics:

• Release/bugfixing strategy/policy.
• Valgrind and transactional memory.
• Making Valgrind really multi-threaded, parallelising Memcheck, parallelising the rest of the framework, and tools.
• Instant leak detector. Modify memcheck to report the last leaked pointer to a block. Integrate "omega" as a memcheck option or omega as a separate tool. http://www.brainmurders.eclipse.co.uk/omega.html
• Should we continue to support MacOS? What about Valgrind on MS-Windows?
• Make Callgrind work sanely on ARM (and PPC). The Callgrind algorithm to track call and return is to be improved to work properly on these platforms. Is there a way to make this better? E.g. by having a fast way working in most cases, and rely on unwind info in the difficult cases. Can we detect at instrumentation time that an instruction is a difficult case?
• Redo the JIT framework to reduce baseline overheads. Could we reuse some "compiler lib" (qemu tcg, llvm or gcclib as code generator)? Probably cannot (easily) link these with V => use a "co-process"? Destroys startup time? Any other suggestion to (significantly) improve the speed of Valgrind JITted code?
• Packaging valgrind for distros, handling patches, suppressions, etc.
• An interactive SQL relational interface to Valgrind data structures https://github.com/mfragkoulis/PiCO_QL/tree/master/src/Valgrind-mod
• 80 bit arithmetic on x86/AMD64.
• Which CPUID is it anyway? Valgrind isn't completely consistent in handling host CPU capabilities vs VEX emulation capabilities. What can we do to improve that? Make it user tunable?
• VEX is in theory cross-architecture. What would it take to make valgrind cross-arch? How about starting with i686 on x86_64?
• Improve memcheck leak heuristics. In 3.9.0, some heuristics were added to memcheck to decrease the false positive rate of possible leaks for c++ objects (such as std::string). Add more of such heuristics? And/or have a more flexible way to define heuristics, e.g. using "user definable expressions"? Add a way to specify a stack trace to match for a heuristic?
• helgrind improvements:
  • currently, in race conditions errors, locks are only described by an address and their creation stack trace. Add more info (when possible) based e.g. on --read-var-info=yes
  • speed up helgrind 'mini stacktrace' capture avoid to take duplicate stack traces? Or have a way to detect only the top most IP has been updated since previous stack trace?
  • suppressions entries for helgrind with matching the stack trace of one or the other or both threads involved.
• Support stack traces containing IP of "disappeared" code e.g. in memcheck, memory can be allocated by a piece of code that has disappeared at the time the stacktrace has to be shown.
  • Support build-ids https://fedoraproject.org/wiki/Releases/FeatureBuildId
  • Better support compiled/JITted code. Allowing the JIT compiler to indicate to Valgrind the link between the JITted code and the source code. (See also GDB BoF, steal their code/design?)
• Implement a generalised "xtree" Massif has a data structure called an xtree. Basically, a bunch of stack traces, represented under the form of a tree, where each node of the tree contains the sum of all the memory size allocated by the called functions. The idea is to generalise this data structure, so as to make it usable in other contexts. Of course; use the generalised one to replace the massif one. also use it in memcheck (to allow massif like output from memcheck) maybe other uses, e.g. to collect and show events or calls to various things, using a common infrastructure.
• Revisit the default value of (some of) the command line options e.g. Decrease helgrind redzone size from 16 to the minimum needed. Change -keep-stacktraces=alloc-then-free to alloc-and-free default other relevant options we should change the default ?
• Client Requests as SDT markers? https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation