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

Some discussion topic ideas:

• Release/bugfixing strategy/policy.
• Can we move to git yet?
• 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
• 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?
• Packaging valgrind for distros, handling patches, suppressions, etc.
• 32-bit x86 vs modern instruction sets (avx, etc.)
• VEX is in theory cross-architecture. What would it take to make valgrind cross-arch? How about starting with i686 on x86_64?
• 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?
• <YOUR SUGGESTION HERE!>

And now is the time on Sprockets when we hack!