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@lists.llvm.org> wrote: > Forwarding to lldb-dev now that I’ve signed up. > > > > *From:* llvm-dev <llvm-dev-boun...@lists.llvm.org> *On Behalf Of > *Cazalet-Hyams, > Orlando via llvm-dev > *Sent:* 24 September 2020 08:54 > *To:* Robinson, Paul <paul.robin...@sony.com>; Eric Christopher < > echri...@gmail.com>; LLDB Dev <lldb-dev@lists.llvm.org>; ' > llvm-...@lists.llvm.org' <llvm-...@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.robin...@sony.com> > *Sent:* 23 September 2020 15:21 > *To:* Eric Christopher <echri...@gmail.com>; Cazalet-Hyams, Orlando < > orlando.hy...@sony.com>; LLDB Dev <lldb-dev@lists.llvm.org>; ' > llvm-...@lists.llvm.org' <llvm-...@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-boun...@lists.llvm.org> *On Behalf Of *Eric > Christopher via llvm-dev > *Sent:* Tuesday, September 22, 2020 2:42 PM > *To:* Cazalet-Hyams, Orlando <orlando.hy...@sony.com>; LLDB Dev < > lldb-dev@lists.llvm.org> > *Cc:* llvm-...@lists.llvm.org > *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table > > > > +LLDB Dev <lldb-dev@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-...@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.hy...@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-...@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@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
