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.

Og

  • 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

https://www.semanticscholar.org/paper/Debugging-Optimized-Code%3A-Concepts-and-on-DIGITAL-Brender-Nelson/b94d517a8f5780db9cbca43a4b7870bec4d13f52

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

Yuanbo Li, Shuo Ding, Qirun Zhang, Davide Italiano

https://helloqirun.github.io/papers/pldi20_yuanbo1.pdf

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

https://www.cc.gatech.edu/~qrzhang/projects/debug/debug.html

https://github.com/yuanboli233/debug-info-testing

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

Caroline Tice, Prof. Susan L. Graham

https://www.researchgate.net/publication/2432347_Key_Instructions_Solving_the_Code_Location_Problem_for_Optimized_Code

Thanks,

Orlando