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

2020-09-24 Thread Eric Christopher via lldb-dev
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 wrote: > Hi Eric & Orlando, > > > > It’s great to see interest in a lot of different aspects of debug info. At > the same

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

2020-09-22 Thread Eric Christopher via lldb-dev
+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

Re: [lldb-dev] [llvm-dev] HTTP library in LLVM

2020-08-31 Thread Eric Christopher via lldb-dev
+LLDB Dev as well for visibility. +Pavel Labath since he and I have talked about such things. On Mon, Aug 31, 2020 at 7:26 PM David Blaikie wrote: > [+debug info folks, just as FYI - since the immediate question's more > about 3rd party library deps than the nuances of DWARF, etc] > > I'd

Re: [lldb-dev] [llvm-dev] RFC: Release process changes

2020-05-26 Thread Eric Christopher via lldb-dev
This set of changes sounds good to me. Thanks! -eric On Thu, May 21, 2020 at 12:00 PM Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hi, > > I would like to propose a few changes to the LLVM release process. The > current process is documented here: >

Re: [lldb-dev] Pre-merge lldb testing

2020-05-16 Thread Eric Christopher via lldb-dev
On Sat, May 16, 2020 at 12:18 PM Greg Clayton wrote: > > > On May 15, 2020, at 7:04 PM, Eric Christopher via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi All, > > We've been testing[1] a number of patches upstream by default via some > pre-merge chec

[lldb-dev] Pre-merge lldb testing

2020-05-15 Thread Eric Christopher via lldb-dev
Hi All, We've been testing[1] a number of patches upstream by default via some pre-merge checks in phabricator. I was thinking of turning them on for lldb as well. Mostly it well just help people know whether or not they've broken lldb before they commit something, but won't stop committing or do

Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!

2019-12-31 Thread Eric Christopher via lldb-dev
Yep! On Tue, Dec 31, 2019 at 5:53 PM George Burgess IV via cfe-dev < cfe-...@lists.llvm.org> wrote: > Thank you all! > > To clarify, a booking with Steins has already been made, yeah? > > George > > On Mon, Dec 30, 2019 at 10:28 AM Tanya Lattner via cfe-dev < > cfe-...@lists.llvm.org> wrote: >

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

2019-05-15 Thread Eric Christopher via lldb-dev
The dependency edges caused by the file means that any time anyone touches that file everything that depends on it is rebuilt. The way it's included basically means you're doing a full build any time you touch it. It's who is depending on this file or any file this file includes, not the other way

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

2019-05-15 Thread Eric Christopher via lldb-dev
A couple of perspectives FWIW: a) Header file includes increase overall dependencies which affects incremental rebuild time whenever you touch something. Especially more when that header is included into multiple headers that are then included into an array of translation units b) Having each

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

2019-03-19 Thread Eric Christopher via lldb-dev
Honestly I'm looking forward to GitHub's interface here. On Tue, Mar 19, 2019, 1:25 PM James Y Knight via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I think we definitely will want to support github PRs, at the very least > as an _option_, even if we continue running/preferring phabricator. >

Re: [lldb-dev] Status of DWARF64 in LLDB

2019-03-12 Thread Eric Christopher via lldb-dev
On Tue, Mar 12, 2019 at 1:43 PM Jan Kratochvil via lldb-dev wrote: > > On Mon, 11 Mar 2019 21:25:05 +0100, Jan Kratochvil via lldb-dev wrote: > > I think it is never needed in real world as long as one uses DWP and/or > > -fdebug-types-section. Red Hat is using neither (for DWZ postprocessing)

Re: [lldb-dev] Status of DWARF64 in LLDB

2019-03-11 Thread Eric Christopher via lldb-dev
On Mon, Mar 11, 2019 at 3:49 PM Adrian Prantl via lldb-dev wrote: > > > > On Mar 11, 2019, at 3:46 PM, Zachary Turner wrote: > > Given that: > > 1) LLVM doesn't produce DWARF64 > 2) GCC has to be patched to produce DWARF64 > 3) LLDB's support is only partial but is untested and appears to be

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

2019-01-30 Thread Eric Christopher via lldb-dev
On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev wrote: > > Bruce Hoult via llvm-dev writes: > > > How about: > > > > Require a rebase, followed by git merge --no-ff > > > > This creates a linear history, but with extra null merge commits > > delimiting each related series of patches. >

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-06-18 Thread Eric Christopher via lldb-dev
On Mon, Jun 18, 2018 at 9:57 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > > On Jun 18, 2018, at 9:54 AM, < > paul.robin...@sony.com> wrote: > > > >> Greg wrote: > >>> Pavel wrote: > >>> That said, having DWARF be able to represent the template member > >>> functions in an

Re: [lldb-dev] [llvm-dev] Adding DWARF5 accelerator table support to llvm

2018-01-17 Thread Eric Christopher via lldb-dev
FWIW I'm completely on board with everything Adrian has said in this thread :) -eric On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > > > As

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

2016-10-20 Thread Eric Christopher via lldb-dev
should get an email from it if anything > breaks. > > pl > > On 20 October 2016 at 00:24, Eric Christopher via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > > > > On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist <pen...@gmail.com> > wrote: >

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

2016-10-19 Thread Eric Christopher via lldb-dev
On Wed, Oct 19, 2016 at 4:21 PM Tim Hammerquist wrote: > On Wed, Oct 19, 2016 at 4:09 PM, Eric Christopher > wrote: > > > On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist wrote: > > I was mistaken. > > The system toolchain builds stage1

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

2016-10-19 Thread Eric Christopher via lldb-dev
On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist wrote: > I was mistaken. > > The system toolchain builds stage1 llvm, clang & co. > The system toolchain builds lldb containing the llvm/clang/etc bits. > The system toolchain builds gtest test programs. > The stage1 compiler

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

2016-10-19 Thread Eric Christopher via lldb-dev
On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist wrote: > The LLDB job in llvm.org will build a stage1 RA with > llvm+clang+libcxx+compiler-rt using the system compiler, and use the new > compiler to build lldb. > > By default, this is kicked off automatically when a clang

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

2016-10-19 Thread Eric Christopher via lldb-dev
>From chatting with Tim it sounds like at least one lldb bot uses the ToT compiler - we should probably verify that not only does it use that to build lldb but uses it for the tests. That'll get us at least some testing here. -eric On Wed, Oct 19, 2016 at 12:55 PM Greg Clayton via lldb-dev <

Re: [lldb-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

2016-06-30 Thread Eric Christopher via lldb-dev
Thanks a lot for spearheading this and seeing it move forward. It's absolutely appreciated. Thank you. -eric On Thu, Jun 30, 2016 at 1:23 PM Chandler Carruth via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello folks, > > As mentioned some time ago[1], we’ve had a long (looong) series of

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

2016-06-28 Thread Eric Christopher via lldb-dev
On Tue, Jun 28, 2016 at 12:22 PM Rafael Espíndola wrote: > > I think the main issue (besides users asking what's the big change in > > 4.0, which I agree is not a big problem) is that the bitcode > > compatibility policy is tied to the major version number. > > It is tied

Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

2016-06-14 Thread Eric Christopher via lldb-dev
On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> - Original Message - >> > From: "Hans Wennborg via cfe-dev" >> > To:

Re: [lldb-dev] [llvm-dev] GitHub anyone?

2016-06-04 Thread Eric Christopher via lldb-dev
On Fri, Jun 3, 2016, 10:06 PM Chris Lattner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On Jun 2, 2016, at 11:42 AM, via lldb-dev > wrote: > > > > Yeah, I get that and I actually don't mind keeping a linear history. > > But we definitely should branch for

Re: [lldb-dev] google/stable branch on git mirror?

2016-05-03 Thread Eric Christopher via lldb-dev
We aren't qualifying it on our side so it hasn't gotten a stable/testing set of branches. -eric On Tue, May 3, 2016 at 4:15 AM Tamas Berghammer via lldb-dev < lldb-dev@lists.llvm.org> wrote: > +Eric Christopher > > Adding Eric as he was the last person merging changes to

Re: [lldb-dev] [BUG] Many lookup failures

2015-11-30 Thread Eric Christopher via lldb-dev
On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > So be sure to enable -fno-limit-debug-info to make sure the compiler isn't > emitting lame debug info. > > Greg cannot be more wrong here. There are some limitations to be aware of when using limit debug