[Valgrind-users] Fosdem devroom and Valgrind Hackaton

[Mark W. <mj...@re...>]

Hi Valgrind users, hackers and enthusiasts,

We have program from the valgrind devroom that will take place during
Fosdem in Brussels on Saturday 5 February 2017:
https://fosdem.org/2017/schedule/track/valgrind/

The last session will be the Valgrind BoF and Hackaton!

We need your help for that session! The simplest way to help is to just
show up and discuss anything you like and then start hacking! But it is
also fun to have a little structure to the session by letting us know
beforehand what you think we should discuss and/or hack on.

Here is the current desciption, please help improve it:

Valgrind BoF and Hackaton
Open discussion of ideas for Valgrind - and then we hack!
https://fosdem.org/2017/schedule/event/valgrind_hackaton/

Come and hack on Valgrind together. Open discussion about small (or big)
ideas to improve or change Valgrind.

Valgrind developers and users are encouraged to participate either by
submitting ideas/suggestions or by joining the discussion. And of course
by kindly (or bitterly) complain about bugs you find important that are
still Not YET solved for that many years!?@!!!

Afterwards we will sit together and try to fix or implement some of the
things discussed.


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
mj...@re... 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!