[lldb-dev] FW: [llvm-dev] Optimised-code debugging experience Round Table
Tom Weaver via lldb-dev
lldb-dev at lists.llvm.org
Thu Sep 24 03:44:14 PDT 2020
Tom Weaver will answer the councils call!
count me in, can't wait to have a good chin wag (talk for our non brit
brethren) about debug info and it's many faceted forms.
I somewhat agree with Paul's concern about discussing everything, but we
can make a judgement call on the day about what we wish to focus on the
most.
thanks for sorting this out Orlando, looking forward to it.
Tom W
On Thu, 24 Sep 2020 at 09:00, Cazalet-Hyams, Orlando via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> Forwarding to lldb-dev now that I’ve signed up.
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Cazalet-Hyams,
> Orlando via llvm-dev
> *Sent:* 24 September 2020 08:54
> *To:* Robinson, Paul <paul.robinson at sony.com>; Eric Christopher <
> echristo at gmail.com>; LLDB Dev <lldb-dev at lists.llvm.org>; '
> llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> Hi Paul, Eric, lists,
>
>
> FWIW I agree with Paul here. Given the limited time available for the
> discussions I think it makes sense to split up the conversations to keep
> them focused. Though, it'd be good to coordinate non-overlapping time
> slots. As you say, it is likely that people (including me) would want to
> attend more than one of these.
>
>
> Saying that, I've only had 3 people outside of Sony express an interest in
> the Round Table that I proposed. At this rate we may not have the requisite
> numbers to split. Of course, if that number is indicative of actual turn
> out then we won't need to split anyway, but I suspect that there will be
> more attendees on the day.
>
> We must also remember that the Round Table submission deadline is tomorrow
> (tonight?). Unless more people express an interest very soon, I think we
> might need to fall back onto the single Round Table.
>
>
> Thanks,
>
> Orlando
>
> *From:* Robinson, Paul <paul.robinson at sony.com>
> *Sent:* 23 September 2020 15:21
> *To:* Eric Christopher <echristo at gmail.com>; Cazalet-Hyams, Orlando <
> orlando.hyams at sony.com>; LLDB Dev <lldb-dev at lists.llvm.org>; '
> llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
> *Subject:* RE: [llvm-dev] Optimised-code debugging experience Round Table
>
>
>
> 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$>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200924/0fc4d4d0/attachment-0001.html>
More information about the lldb-dev
mailing list