Robinson, Paul via llvm-dev
2020-Sep-23 14:20 UTC
[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.
* 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.
* 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.
* This is basically about IR/MIR transforms, and is where an Og/O1 kind
of topic would fit.
* 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.
* This is obviously about DWARF itself, although to some extent how we go
about generating it.
* Take better advantage of ranges and the .debug_addr table. dblaikie
and clayborg have put up ideas about this.
* 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.
* 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”?
* 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<mailto: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<mailto: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<mailto: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<mailto: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/20200923/d9609c46/attachment.html>
Cazalet-Hyams, Orlando via llvm-dev
2020-Sep-24 07:54 UTC
[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.
* 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.
* 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.
* This is basically about IR/MIR transforms, and is where an Og/O1 kind
of topic would fit.
* 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.
* This is obviously about DWARF itself, although to some extent how we go
about generating it.
* Take better advantage of ranges and the .debug_addr table. dblaikie
and clayborg have put up ideas about this.
* 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.
* 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”?
* 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<mailto: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<mailto:orlando.hyams
at sony.com>>; LLDB Dev <lldb-dev at lists.llvm.org<mailto:lldb-dev
at lists.llvm.org>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table
+LLDB Dev<mailto: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<mailto: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<mailto: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<mailto: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/6543a09a/attachment.html>
Tom Weaver via llvm-dev
2020-Sep-24 10:44 UTC
[llvm-dev] [lldb-dev] FW: Optimised-code debugging experience Round Table
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/llvm-dev/attachments/20200924/0fc4d4d0/attachment.html>
Eric Christopher via llvm-dev
2020-Sep-24 19:41 UTC
[llvm-dev] Optimised-code debugging experience Round Table
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>