Tom Tromey

Emacs Lisp is good, actually, and Emacs should primarily be written in Emacs Lisp. This talk will describe a way forward.

The future of the Emacs core is a frequent topic in the Emacs community. Should the core be in C? Or Rust? Should Elisp continue to be the scripting language? Or Guile? Or Python, Perl (the "Perfect Emacs Rewriting Language") or JS?

This talk advocates the rarely discussed view that Emacs Lisp is good, actually, and that Emacs should be written in Emacs Lisp. Threading, compilation, and addressing Emacs' other low-level deficiencies will be covered, with an eye toward a practical way to roll out the changes.

GDB has had a curses-based interface for many years. Come see what new features are available and how it can improve your debugging experience.

This talk will cover GDB's text user interface (the "TUI"). In particular we'll discuss the benefits of the rewrite, the new features that are available, and how you can easily extend it yourself. A fun demo will be included.

Debugger support for Rust is good but not great. This talk will discuss the difficulties specific to Rust, and will outline a plan to modify LLVM, LLDB, and the Rust compiler to improve the Rust debugging story.

Rust is a systems programming language that originated at Mozilla. Because Rust's type system differs from that of C++, it presents some debuginfo generation challenges to LLVM. This talk provides a brief introduction to Rust with an emphasis on these differences; outlines the Rust-specific difficulties faced by LLVM and debuggers; and proposes a plan for fixing these problems. The talk is intended to be interactive, in that feedback on the proposed plan is actively encouraged. There will also be some discussion of coordination with the DWARF standard and with gdb.

Rust presents new challenges for the debugging ecosystem. This talk will cover some debugging peculiarities of Rust and how we plan to solve them.

Rust is a new systems programming language from Mozilla. Debugging Rust requires new capabilities from LLVM, from debuggers, and even DWARF. This talk will cover some of the difficulties presented by Rust, and will describe ongoing work to fix these problems in DWARF, LLVM, lldb, and gdb.

Given the current state of Valgrind and GDB how can we make things even better and smoother? Put some Valgrind and GDB hackers in the same room and let them discuss the technical details needed on each side. Come and help us brainstorm some crazy and fun ways to make the Valgrind/GDB combo even cooler and more powerful.

• Setting up Valgrind with GDB is a bit more work than some would like. Wouldn't it be nice if all one would need to do inside GDB would be:

  (gdb) target valgrind (gdb) run

Exactly how one gets here though ... may need changes to both GDB and Valgrind. Can "target valgrind" also work nicely with ssh somehow, so you can gdb a valgrind on a different machine.

• How can we get extended-remote features from Valgrind? In particular it would be nice to have multi-inferior working. This is tricky, though, because in the Valgrind model each new inferior would have its own gdbserver. Brainstorm solutions.

• Can we get Valgrind to handle non-stop? This is the direction GDB is moving towards.

• Right now Valgrind provides "monitor" commands to control it. Could instead let Valgrind create real commands with completion; perhaps via Python. Is this worth doing; and how would we do it?

• Likewise is it interesting for memcheck to provide a convenience function that can be used to tell whether some memory is valid? On the GDB side it might be interesting if the function could work with ASAN or gdb-heap as well.

• Given that Valgrind sees everything you get unlimited "hardware" data watchpoints. Do you want more?

• Reverse debugging using Valgrind.

• Can GDB put breakpoint tracepoint expressions in a Valgrind inferior that VEX would JIT?

• Given the work on GDB catch syscall support are there any more catch targets that Valgrind could/should provide?

In recent years GDB has undergone a renaissance, adding Python scripting and other cool new features. This talk will show you how to customize GDB for your application and your debugging needs. We'll go into depth about pretty printing, stack trace filtering, and writing new commands; and will also discuss writing GUIs and other tools inside GDB. Finally, we'll cover other interesting and useful GDB projects.

In this talk we'll cover:

• A high-level overview of how GDB has modernized in the last few years

• Customizing GDB for your application, using Python:

  • Writing a pretty-printer
  • Writing a stack trace ("frame") filter
  • Writing new commands, functions and other goodies
  • Cool use cases like built-in GUIs

• Other projects to help your debugging

  • Scalability
  • Local/remote feature parity
  • C++ features
  • Multi-inferior, multi-target debugging