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 *On Behalf Of
> *Cazalet-Hyams,
> Orlando via llvm-dev
> *Sent:* 24 September 2020 08:54
> *To:* Robinson, Paul ; Eric Christopher <
> echri...@gmail.com>; LLDB Dev ; '
> 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
> *Sent:* 23 September 2020 15:21
> *To:* Eric Christopher ; Cazalet-Hyams, Orlando <
> orlando.hy...@sony.com>; LLDB Dev ; '
> 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
