Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

I reverted things in r344318 now. > On Oct 10, 2018, at 5:02 PM, Jim Ingham wrote: > > Thanks for looking into this! > > When I was first working on inlined stepping, I found a bunch of cases where > the line table info and the ranges for the inlined subroutines disagreed. I > remember see

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

1) So I went and figured out why the lldb testcase at hand fails. - It seems the debugger stepping logic will follow the program along until it finds a new source location. However if that new source location is part of a new DW_AT_abstract_location it is ignored in the step over mode. - In the

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

> On Oct 10, 2018, at 12:18 PM, via llvm-commits > wrote: > > > >> -Original Message- >> From: jing...@apple.com [mailto:jing...@apple.com] >> Sent: Wednesday, October 10, 2018 2:20 PM >> To: Vedant Kumar >> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun >> S

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

> On Oct 10, 2018, at 12:18 PM, via llvm-commits > wrote: > > > >> -Original Message- >> From: jing...@apple.com [mailto:jing...@apple.com] >> Sent: Wednesday, October 10, 2018 2:20 PM >> To: Vedant Kumar >> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun >> S

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

So I haven't worked much on debug info, but here's the explanation for my patches: My original motivation was getting rid of code some code in the llvm codegen that for spills and reloads just picked the next debug location around. That just seemed wrong to me, as spills and reloads really are b

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

So what should we do? Revert the llvm commit, fix the LLDB test, xfail on lldb? I'd be fine with any but don't want to learn how lldb tests work at this moment... > On Oct 5, 2018, at 4:11 PM, Vedant Kumar via llvm-commits > wrote: > > Sadly, after this commit TestDataFormatterLibcxxList.py s

Re: [lldb-dev] [llvm-dev] [Release-testers] [5.0.0 Release] Release Candidate 2 tagged

+CC Alina Maybe the bitcode is generated too aggressively and we should find ways to disable the Bitcode tests if the host CPU isn't new enough (or alternatively disable the bitcode tests by default and only enable them when someone asks for them via TEST_SUITE_SUBDIRS?) - Matthias > On Aug 1

Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

> On May 31, 2017, at 4:06 AM, Pavel Labath wrote: > > Thank you all for the pointers. I am going to look at these to see if > there is anything that we could reuse, and come back. In the mean > time, I'll reply to Mathiass's comments: > > On 26 May 2017 at 19:11, Matthias Braun wrote: >>> Bas

Re: [lldb-dev] [llvm-dev] Running lit (googletest) tests remotely

> On May 26, 2017, at 8:17 AM, Pavel Labath via llvm-dev > wrote: > > Hello all, > > we are trying to convert some of the lldb tests to lit (for these > specific tests we are using the googletest format). One of our > requirements is that we are able to run these tests remotely, so that > we a

Re: [lldb-dev] [llvm-dev] [4.0.0] Release notes nag email

> On Feb 9, 2017, at 1:46 PM, Hans Wennborg via llvm-dev > wrote: > > Dear everyone, > > It's time for the six-monthly release notes nag email in preparation > for the upcoming release. > > As usual, the release notes are almost empty. Please help fill them > with the work you've done in the

Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook

> On Jun 30, 2016, at 6:05 PM, Robinson, Paul via llvm-dev > wrote: > > > > From: Renato Golin [mailto:renato.go...@linaro.org] > Sent: Thursday, June 30, 2016 4:15 PM > To: Robinson, Paul > Cc: Clang Dev; LLDB Dev; LLVM Dev; Reid Kleckner; > llvm-foundat...@lists.llvm.org > Subject: RE: [c

Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook

> On Jun 30, 2016, at 4:14 PM, Renato Golin via llvm-dev > wrote: > > > On 30 Jun 2016 10:20 p.m., "Robinson, Paul" > wrote: > > We've since stopped creating the tags, and gotten used to not having > > them. We do the 'rev-list --count' trick which mainly gets

Re: [lldb-dev] [llvm-dev] Sequential ID Git hook

I assumed we want ids for the umbrella repository to ease bisection and having something to print as a version identifier, but do we really need them for the other repositories? I also still don't see why `git rev-list --count --all` does not work. Sure the count is only per branch, but why wou

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

I really liked the the solution proposed earlier in this thread: Do nothing server side, but instead use `git rev-list --count master` on the client side (which takes 0.9s on my machine) to get the number of the commit. So nothing to do on the ID part IMO. As for updating the meta repository: We

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

> On Jun 6, 2016, at 1:29 PM, Richard Smith via llvm-dev > wrote: > > On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" > wrote: > > > > I'd suggest a workflow like the following: > > > > - developer commits locally to a feature/bug dev branch. You can commit

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

So here's a straw-man proposal for a github migration: 1. Register an official github project with the llvm foundation. 2. Setup another (read-only) mirror of llvm.org/git at this github project 3. Make sure we have ala llvm-project-submodules setup in the official account. (Optional or necessary

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

> On May 31, 2016, at 3:01 PM, Joerg Sonnenberger via llvm-dev > wrote: > > On Tue, May 31, 2016 at 02:43:02PM -0700, Matthias Braun wrote: >> >>> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev >>> wrote: >>> >>> On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote:

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

> On May 31, 2016, at 2:05 PM, Joerg Sonnenberger via llvm-dev > wrote: > > On Tue, May 31, 2016 at 01:45:30PM -0700, Matthias Braun wrote: >> To be more exact here: I usually do not checkout llvm svn at a higher >> level because that forces me back to svn (which last time I used it did >> not

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

> On May 31, 2016, at 1:42 PM, Matthias Braun wrote: > >> >> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev >> wrote: >> >> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote: >>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev >>> wrote:

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

> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev > wrote: > > On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote: >> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev >> wrote: >>> Folks, >>> >>> There has been some discussion on IRC about SVN host

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

Strong +1 to move to an external hosted git sooner rather than later! 1) I personally had very good experiences with git submodules. They are certainly harder to get used to as you have to learn a bunch of extra magic on top of the already magical git: i.e. "git clone --recurse-submodules", then