[llvm-dev] Optimised code debugging experience Round Table follow up
Cazalet-Hyams, Orlando via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 19 05:50:34 PDT 2020
Thank you to everyone who attended the optimised code debugging experience Round Table. Here is a summary of the discussion:
Testing & validation
* 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).
* 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.
* New tool created by Carlos for providing a higher level / semantic view of debug-info. Needs renaming.
* gdb test suite running on llvm. Not necessarily super useful.
* PLDI paper  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.
* 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 .
* 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
 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
 Key Instructions: Solving the Code Location Problem for Optimized Code
Caroline Tice, Prof. Susan L. Graham
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev