Mark Wielaard

Valgrind is 20 years old now! On July 27, 2002 Valgrind 1.0 was released. And the initial commit to the code repository was March 22, 2002. But the real birthday of Valgrind might go back as far as the Norse Mythology. Please come and join us for a celebration of (at least) 20 years of Valgrind. A retrospective of the project and (your) ideas for the next 20 years.

Other people: Julian Seward

With debuginfo Valgrind can provide more useful information about issue found. But till recently it was sometimes hard to get at the debuginfo and valgrind startup time would be really slow parsing the debuginfo. With the introduction of debuginfod support getting the debuginfo is much easier, if your distribution supports it. And the parsing of debuginfo has been improved dramatically. This talk will explain how debuginfod integrates with valgrind and how the debuginfo parsing was improved.

Debugging data is a necessary evil. It is necessary for running debuggers in situ, some tracing tools, or for coredump analysis. It is evil because it is big - potentially many times the size of the binaries. Therefore, software distributions have conflicting needs to generate & keep this data but not burden everyone with its storage.

We will review some degrees of freedom for debugging data distribution, across compiled languages and OS distributions, identifying some of the best practices. We will identify the remaining shortcomings that necessitate exploring yet another way of making debuginfo data available needed.

We will present the elfutils debuginfo-server, where a web service offers a lightweight, build-id-indexed lookup of debuginfo-related data on demand. This service is designed to run on a nearby host, private or shared within teams, or even by OS distributions. Clients built into various debugging type tools will be demonstrated.

Other people: Frank Ch. Eigler

After several years a new DWARF debugging standard, DWARF5, has been released that incorporates various GNU extensions that allow to better express how to map various binary constructs created by optimizing compilers back to the original source code while reducing the size of the debugging information. This results in more expressive debuginfo, but also introduces more complexity that DWARF consumers need to deal with.

We will go over the existing GNU Extensions to DWARF, how they were adopted by DWARF5, and describe how debug consumers can take advantage of them. To reduce space a lot of different strategies are being used. Separate .debug files, .gnu_debuglink, build-ids, compressed ELF sections, debug types in ELF COMDAT sections, the Dwarf Compressor DWZ .multi files, DWARF Supplementary Object Files, GNU Debug Fission, split-dwarf .dwo files, DWARF Package Files .dwp files. The basic structure of describing a program with a tree of Debug Information Entries (DIEs) with attributes per compile unit augmented with some auxiliary data structures to map to source files, describe macros used in the source and get call frame information hasn't fundementally changed between DWARF version 2 and version 5. But the hierarchy of the representation and where the bits are stored has become much more complex. It is no longer possible to just see the DWARF descriptions as a fancy symbol table which can be simply indexed through some offsets. It has also become much more expressive than that.

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 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!

gcc/glibc support fortification of some functions by defining FORTIFYSOURCE. This inserts some compile and runtime buffer overflow checks for selected glibc functions. These checks have no or very little runtime overhead and work on the object level (the compiler provides/proofs the size of the object buffer size). valgrind memcheck provides similar memory buffer overflow checks. These checks don't need any compiler help (you won't have to rebuild your code). But they have a much higher runtime overhead. They also work on a different level. valgrind memcheck doesn't know anything about the objects the user is manipulation but has knowledge of all memory blocks allocated. Lets explore how these different mechanisms work and how we can make them work better together.

Users (and developers) don't just want to run an executable, they also like to know that it runs efficiently, that it doesn't use unnecessary resources and if it crashes and burns they want to collect the pieces and inspect what went wrong. So a package should also provide the user with a means to easily profile, trace and debug what is running on their system. This means a distro should also package symbols, debuginfo and sources for easy/automatic installation. With different distros and different versions of distro packages running next to each other in containers we need some standard conventions to identify executables (build-id) and match and fetch the needed symbols, debuginfo and sources to help the user profile, trace and debug any binary they find on their system.

We will go briefly over differently tools for shared library abi inspection, tracing, debugging, profiling and post-mortem crash analysis. What extra information such tools need, like CFI/backtrace, symbols, gnu_debugdata, debuginfo and sources. Then we will discuss the tools that are used on Fedora to extract and package the extra information. How build-ids are used as a means to find/match the information. So the user/developer can know exactly which version of a library was actually running when the core file was created for example. And identify some deficiencies in the current packaging. It is impossible to install both the 32bit and 64bit version of the debuginfo for example. What extra challenges there are when you might be running different versions of a package in different containers. And some suggestions on tools and conventions that distro packages can adopt to make all this easier for the user and tools. At the end it would be nice to have a discussion how other distros deal with some of these challenges. How distros/packagers can coordinate on making this information (a symbol/debuginfo server) available cross distros and how/if to extend these ideas to non-native ELF/DWARF executables.

If you always wanted to hack on Valgrind, but haven't yet really looked at the code yet, then this talk is for you. We'll go over setting up the sources to start hacking, where to start and explore various easy hacks by example. After attending this talk, you should be all set to attend the hackaton in the Valgrind devroom at the end of the day.

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!?@!!!

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

Often when people ask the question "Can I legally do that?", they mean "Will someone sue me if I do...?". Sadly the answer is that if something is successful, no matter what and how you did things, at some point someone will just try and sue, just to see if they can get some part of the success/money. This talk will describe some of the copyright, trademark and patent issues a Free Software hacker dealing with the core java platform may encounter. And some techniques we as a community can employ to make the chances of individual hackers being the target of a lawsuit smaller and how to make it harder for someone to take down one of our core java platform projects.

Brief Welcome to the Free Java DevRoom

Other people: Andrew Haley Andrew Hughes Ben Evans Dalibor Topić Mario Torre Martijn Verburg Sylvestre Ledru Tom Marble