Optimised code debugging experience Round Table follow up

Hi everyone,

Thank you to everyone who attended the optimised code debugging experience Round Table. Here is a summary of the discussion:

Testing & validation

  • debugify:

  • debugify extension Djordje has been working on uses existing (instead of synthetic) debug-info.

  • Potential for an extension which helps find problems with debug intrinsic handling.

  • Is debugify appropriate for CI regression testing? (Seems not).

  • dexter:

  • Concerns raised about scalability - already being addressed.

  • Using dexter to look at stack backtraces.

  • Getting LNT metrics for dexter tests upstream might be useful - needs evaluating.

  • Upstream test suite is small, Phillip P. mentions we are sitting on a bunch downstream.

  • llvm-diva

  • New tool created by Carlos for providing a higher level / semantic view of debug-info. Needs renaming.

  • Other:

  • gdb test suite running on llvm. Not necessarily super useful.

  • PLDI paper [1] implements automated validation pipeline on synthesised programs. Scalability concerns again.


  • O1 as Og. Proposed by Eric a while ago (see mails/RFC).

  • Main goal: Somewhat optimised code with quick build and useful debug-info.

  • Remove abstraction penalties but leave things as debuggable as possible.

  • Give all locals stack homes? Runtime performance implication needs investigation.

  • The analysis/testing has developed further since the last discussions but nothing put upstream yet.

  • Contributors welcome - discuss with Eric.

  • Lifetime extension? Prefer to fix/improve variable location tracking.

Stepping behaviour

  • is_stmt & program breakpoints:

  • There is a lot of interest in, and agreement for, changing how llvm identifies useful program breakpoints (DWARF is_stmt flag).

  • lldb and Sony’s debugger ignore is_stmt currently.

  • “Statement” at the language level is definitely too coarse. Expressions might be a useful as a start.

  • Caroline T. suggests breakpoints (is_stmt) should be on all user visible state changes [2].

  • prologue_end can be misleading:

  • Difficult because of shrink wrapping etc.

  • Some debuggers use it, some don’t.

  • We may need to guard changes in this area behind a flag to avoid breaking compatibility with consumers.

Useful links captured from the Zoom chat:

Paper on work done for OpenVMS debugger in the 1990s.
Ronald F. Brender, Jeffrey E. Nelson, Mark E. Arsenault


[1] Debug Information Validation for Optimized Code (PLDI 2020)

Yuanbo Li, Shuo Ding, Qirun Zhang, Davide Italiano


Debugging Information Testing: A Python reimplementation for the debug-information testing framework for the paper



[2] Key Instructions: Solving the Code Location Problem for Optimized Code

Caroline Tice, Prof. Susan L. Graham