llvm dev - Oct 2020 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201019/02fbd4c8/attachment.html>