[llvm-dev] Optimised-code debugging experience Round Table

[Eric Christopher via llvm-dev]

Hi Paul,

I took it rather as a set of suggested topics depending on who is
interested rather than a proposed agenda.

-eric

On Wed, Sep 23, 2020 at 7:20 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same time, I’m concerned about a risk to making the topic so broad that
> we don’t have time to get through all the things people want to get
> through.  I’m thinking there’s a different way to slice the topics,
> hopefully without much overlap, but that will allow a bit more focus.  No
> doubt a lot of the same people would be interested in multiple slices, but
> by limiting the scope of each conversation I’m hoping we’ll get more
> accomplished.  I daresay a lot of people interested in debug-info quality
> in general might totally tune out a DWARF-nerd discussion 😊
>
> The slicing could be something like this:
>
>
>
>    1. Getting LLVM to do a better job of tracking info internally, so
>    what gets emitted in the end is more representative of the original
>    program. This should improve the debugging experience by letting the
>    debugger do a better job of mapping the executing program to the original
>    source, because the data it works with is more accurate/complete.
>       1. This is basically about IR/Metadata handling and representation,
>       although it might leak into things like the “is_stmt” flag, and doing
>       better with “prologue_end,” which are currently handled by AsmPrinter.
>       2. Better handling of induction variables, entry-values, variables
>       with multiple locations, etc.
>    2. Changes to optimization passes/pipelines and codegen, to avoid
>    borking the source-location and value/variable tracking; again this should
>    improve the debugging experience by letting the debugger do a better job of
>    mapping the executing program back to the original source, because that
>    mapping is simpler.
>       1. This is basically about IR/MIR transforms, and is where an Og/O1
>       kind of topic would fit.
>       2. Also things like extended lifetimes, limiting code
>       motion/duplication, etc.
>    3. Changing the DWARF spec itself to improve the completeness and
>    efficiency of the information it contains.  This should improve the
>    debugging experience by making the DWARF itself a richer information
>    source, to the extent that it can describe more of what happened to the
>    original program; also hopefully any efficiency improvements will allow the
>    debugger to be more responsive.
>       1. This is obviously about DWARF itself, although to some extent
>       how we go about generating it.
>       2. Take better advantage of ranges and the .debug_addr table.
>       dblaikie and clayborg have put up ideas about this.
>       3. Figure out a way to allow tracking multiple source locations for
>       an individual instruction.  Right now we mostly give up and set locations
>       to line-0 when this happens.
>       4. Understand the competing needs of profiling and debugging
>       consumers, and see what might be doable there.  (Although this might be
>       tough enough to be its own topic.)
>    4. Debug-info testing/validation.  How do we decide what is
>    “correct”?
>       1. What are the tools we have, what are they good/bad at, what’s
>       missing?
>
>
>
> I hear that round-tables can be proposed for either ~half hour or ~full
> hour, so with more focused topics we might rather have shorter sessions?
>
>
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Eric
> Christopher via llvm-dev
> *Sent:* Tuesday, September 22, 2020 2:42 PM
> *To:* Cazalet-Hyams, Orlando <orlando.hyams at sony.com>; LLDB Dev <
> lldb-dev at lists.llvm.org>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> +LLDB Dev <lldb-dev at lists.llvm.org>
>
>
>
> I'll sign up. :)
>
>
>
> My particular interests are:
>
>
>
> - Og (and O1 as Og)
>
> - Correctness testing tools
>
>
>
> Past that the rest of your list seems quite specific, but the overall
> "line tables" and "variable locations" are important.
>
>
>
> Relatedly we have a number of DWARF committee members in llvm and another
> possible discussion area could be: "what extensions do debug info consumers
> think should happen to make dwarf a better input into debugging".
>
>
>
> Thanks.
>
>
>
> -eric
>
>
>
>
>
> On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> I haven't seen a proposal for an optimised-code debugging experience Round
> Table yet so here goes!
>
> Please let me know if you are interested by emailing me at:
>
>
>
>     orlando.hyams at sony.com
>
>
>
> Below is a non-exhaustive list of possible topics. Feel free to include
> any preferences and
>
> suggestions in your response.
>
>
>
>   a. Line tables:
>
>     1. Can we fix is_stmt?
>
>     2. Is prologue_end reliable?
>
>     3. General stepping behaviour/quality.
>
>
>
>   b. Variable locations:
>
>     1. The state of DW_OP_entry_values in llvm.
>
>     2. The state of the instruction-referencing DBG_VALUE work.
>
>     3. The state of multi-register DWARF expressions in llvm.
>
>     4. The possibility of salvaging out-of-liveness values using the 3
> projects mentioned above.
>
>     5. Floating point debug-info quality in llvm.
>
>     6. Loop induction variable locations.
>
>
>
>   c. Testing debug-info:
>
>     1. Variable correctness testing tools.
>
>     2. Location coverage testing tools.
>
>
>
>   d. The state of -Og.
>
>
>
> Please respond before Friday (25th) if you are interested as that is the
> submission deadline.
>
>
>
> Thanks,
>
> Orlando
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!qZNIykNGKyisLnvZ4ZEA_BQPbabOTQucziiEgm1DmJ154Z_DBQc8k6R5JENTM2Ewyg$>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200924/8b372a59/attachment.html>