Compile Once Debug Twice; Picking a compiler for debuggability

This proposal has been rejected.


One Line Summary

Symbolic debuggers are one of the most important tools in the programmer’s toolkit, but also one of the most overlooked pieces of technology. They have to work in some of the harshest conditions, supporting a huge set of programming languages and aggressive transformations by compilers. This talk explores how these debuggers work and how they fail.


In this presentation, we will take you on a journey to some of the darkest and most confusing pits of systems programming involving debug formats, compilers and process control. We will describe situations where debuggers have failed you, why and how they can be addressed. These failures include missing critical data, corrupted output, performance bottlenecks and more.

Even a single snapshot of application state can yield important clues that can reduce time to resolution. This ranges from the classes of instructions involved, to run-time breadcrumbs from the garbage collector or memory allocator, to the relationships of objects in application memory. We will take a tour of commonly neglected areas of application state whose exploration can greatly reduce time to resolution of common classes of bugs. Various aspects of popular debuggers such as GDB and LLDB will be analyzed, including performance and debug information handling.

Some of the worst bugs are ones that leave engineers with no visibility into application state. Perhaps a process is unable to dump core on your filesystem, or your debugger hangs extracting application state or your compiler has completely optimized out a crucial piece of information. What are the common pitfalls and how can they be resolved? We will investigate real-world situations where standard symbolic debugging techniques are insufficient or fail and how some of those situations can be mitigated. We will investigate some of the most recent developments in symbolic debugging.


debugging, GDB, lldb


  • Sbahra-s

    Samy Bahra



    Samy Al Bahra is the cofounder of Backtrace, where he is helping build a modern debugging platform for today’s complex applications. Prior to Backtrace, Samy was a principal engineer at AppNexus, where he played a lead role in the architecture and development of many mission-critical components of the ecosystem. His work at AppNexus was instrumental in scaling the system to 18 billion impressions with orders of magnitude in efficiency improvements. Prior to AppNexus, Samy was behind major performance improvements to the core technology at Message Systems. At the George Washington University High Performance Computing Laboratory, Samy worked on the UPC programming language, heterogeneous computing, and multicore synchronization. Samy is also the founder of the Concurrency Kit project, which several leading technology companies rely on for scalability and performance. Samy serves on the ACM Queue Editorial Board.