Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 3 is here

[Dimitry Andric via lldb-dev]

On 22 Sep 2020, at 17:12, Hans Wennborg via Release-testers 
 wrote:
> 
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.

This rc3, like rc2, I could finally build and test without adding any
patches! :)

Main results on amd64-freebsd11:

  Unsupported:  5122 (rc2:  5121)
  Passed : 69761 (rc2: 69739)
  Expectedly Failed  :   245 (rc2:   245)
  Timed Out  :16 (rc2:16)
  Failed :   480 (rc2:   481)
  Unexpectedly Passed: 2 (rc2: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (rc2: 2399)
  Failed:3 (rc2:3)

Main results on i386-freebsd11:

  Unsupported:  3513 (rc2:  3512)
  Passed : 66636 (rc2: 66614)
  Expectedly Failed  :   230 (rc2:   230)
  Timed Out  : 7 (rc2: 7)
  Failed :   321 (rc2:   322)
  Unexpectedly Passed: 1 (rc2: 1)

Uploaded:
SHA256 (clang+llvm-11.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 
8ef0c820ff9865d54c2d2b79abc0aae3ca584218a3f90a31487590a90f398a26
SHA256 (clang+llvm-11.0.0-rc3-i386-unknown-freebsd11.tar.xz) = 
17e9f4bafbd34de102f0e8530ca154a57fa205cd183f402b366f873f3607f55b

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [11.0.0 Release] Release Candidate 3 is here

[Michał Górny via lldb-dev]

On Tue, 2020-09-22 at 17:12 +0200, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
> 
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.
> 
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc3
> and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc3
> 
> Pre-built binaries will be added as they become ready.
> 
> Please file bug reports for any issues you find as blockers of
> https://llvm.org/pr46725
> 
> Release testers: please start your engines, run the script, share your
> results, and upload binaries. And thank you very much for your help so
> far.
> 
> There are currently no open release blockers, so unless anything new
> and bad comes up, this is what the final release will look like.
> 

Nothing really new on Gentoo end.  It seems that a few clangd and one
lld test failed when old version was installed on the system
but I suppose it's not important enough to care about it right now.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table

[Robinson, Paul via lldb-dev]

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  On Behalf Of Eric Christopher 
via llvm-dev
Sent: Tuesday, September 22, 2020 2:42 PM
To: Cazalet-Hyams, Orlando ; LLDB Dev 

Cc: llvm-...@lists.llvm.org
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table

+LLDB Dev

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 
mailto: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