Re: [lldb-dev] Stopping "stop reason = exec"

That works, thanks Jim! Agreed that it is ugly though :-) -Chris > On Dec 4, 2017, at 6:18 PM, Jim Ingham wrote: > > Yup, apparently debugserver tells us the stop is for exec directly so we > don't treat it as a breakpoint hit. That sorta makes sense, you don't want > to trigger a breakpoin

Re: [lldb-dev] Stopping "stop reason = exec"

> On Dec 4, 2017, at 4:25 PM, Chris Lattner wrote: >> For macOS, you can also just do: >> >> (lldb) break set -n _dyld_start --skip-prologue 0 -s dyld >> Breakpoint 2: where = dyld`_dyld_start, address = 0x0001b19c >> (lldb) b com add -o continue >> either in your .lldbinit or in your deb

Re: [lldb-dev] Stopping "stop reason = exec"

> On Dec 4, 2017, at 3:50 PM, Jim Ingham wrote: > There isn't a setting to auto-continue from exec. Definitely should be. Yeah, I assumed that I could redefine my “r” alias to include this, but there is no flag to process launch. > > If somebody wants to try their hand at it, just add a se

[lldb-dev] Stopping "stop reason = exec"

Hi all, Is there anything I can put into my lldb init script to prevent LLDB from stopping on exec? Every time I run a program I get this super irritating behavior: Thanks for any help! -Chris Process 20310 launched: '/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swi

[lldb-dev] Moderating lldb-dev/lldb-commits mailing lists

Hi All, I’ve been moderating the lldb mailing list for a very long time now, but I don’t think it makes sense for me to continue. Is there anyone interested in taking over this (important to the community) responsibility? Thanks! -Chris ___ lldb-dev

Re: [lldb-dev] Code ownership resignation

On Nov 16, 2016, at 3:55 PM, Enrico Granata via lldb-dev wrote: > I would recommend that the community consider Jim Ingham for taking over data > formatters. He is already code owner for Objective-C runtime and ValueObject. > I'd like to recommend that the remaining part of Value* (Value.h/Value

Re: [lldb-dev] Final Result - GitHub Survey

On Nov 9, 2016, at 2:53 AM, Renato Golin via lldb-dev wrote: > Folks, > It's been one week after the initial results were shared and three > days after the last answer, so I think it's time to close down and > publish the final results. > > The ODF, XLS and CSV files are at: > > http://people.l

[lldb-dev] Relicensing discussion @ llvm-dev

Hi LLDB folks, FYI, I kicked off a thread about relicensing on LLVM. It impacts LLDB as well, but it would be great to keep the discussion centralized on one list: http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html -Chris ___ lldb-de

Re: [lldb-dev] LLDB Evolution

Can you just grep for “^“ or something? That seems like a straight-forward way to find lines that have a ton of leading indentation. -Chris > On Aug 27, 2016, at 9:28 AM, Zachary Turner wrote: > > It will probably be hard to find all the cases. Unfortunately

Re: [lldb-dev] LLDB Evolution

> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev > wrote: > > Back to the formatting issue, there's a lot of code that's going to look bad > after the reformat, because we have some DEEPLY indented code. LLVM has > adopted the early return model for this reason. A huge amount of o

Re: [lldb-dev] LLDB Evolution

> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev > wrote: > > On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > I've sampled the python code from the llvm repository, and it seems to > be using a mixture of 4-, 2-, and even 8- charact

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 3:40 PM, Zachary Turner via lldb-dev > wrote: > > > On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton > wrote: > > > - Will we stop putting m_ at the front of class ivars and g_ at > > the front of globals? > > I believe these make thing

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 11:36 AM, Zachary Turner wrote: > > I was thinking the same thing too. I figured this was just for the interim. > > Chris, did you mean to update the global LLVM style conventions? Yes, I meant that this should get updated: http://llvm.org/docs/CodingStandards.html#inclu

Re: [lldb-dev] LLDB Evolution

> On Aug 11, 2016, at 7:41 AM, Pavel Labath wrote: > > I just committed another header cleanup commit, which makes lldb > clang-format-immune ( = it still compiles after a full reformat) on > linux. Other OS's are still likely to have some missed dependencies. Nice! > However, when I tried ru

Re: [lldb-dev] LLDB Evolution

On Aug 9, 2016, at 8:42 AM, Zachary Turner via lldb-dev wrote: > #2 could potentially be improved by lit style tests. +1 to this. > Again, the real question is just how much effort are we actually prepared to > put into this? I'd love it if there were entire days or weeks that were just >

Re: [lldb-dev] LLDB Evolution

> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev > wrote: > > So perhaps it would be reasonable for us to standardize on something like > this: > > Main Module Header > Local/Private Headers > lldb/... > llvm/... > System #includes This makes sense to me, and matches what clang does

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

On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev wrote: > I think I agree with Chris with 3.10 being the worst possible outcome. > > I'd be interested to understand why you or Chris thing 3.10 is the worst > possible outcome. > > Chris has said it is because he thinks we'll never

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

> On Jun 28, 2016, at 8:40 AM, Hans Wennborg wrote: > >> I continue to think that 3.10 is the least defensible option out there. We >> have a time based release process with no mechanism or attempt to align >> behind “big” releases that could bring is to a 4.x number. You might as >> well c

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

On Jun 27, 2016, at 4:57 PM, Hans Wennborg wrote: >> Eh, if we're switching to a completely unrelated versioning scheme, it >> doesn't seem completely unreasonable. >> >> We could also count how many time-based releases we have had and use that... >> >> :: shrug :: >> >> I think counting from 4

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

On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev wrote: > That's what concerns me about going to the scheme Richard and Rafael > suggested, of bumping the major version each time: we'd release 4.0, > and would Tom's dot-release then be 4.1? That would be confusing to > those who are used t

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

> On Jun 19, 2016, at 12:25 AM, Hal Finkel wrote: > > a) LLVM has a time-based release cycle, not a schedule-based one. As such, a > simple and predictable version number makes sense. > b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its > centrality to the project in

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

> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev > wrote: > > On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev > mailto:cfe-...@lists.llvm.org>> wrote: >> I think that this is the right approach, and we happen to have a natural >> forcing function here: opaque pointer types. I

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

On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev wrote: > I think that this is the right approach, and we happen to have a natural > forcing function here: opaque pointer types. I think we should increment the > major version number when opaque pointer types are here, as it will be a > m

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

On Jun 6, 2016, at 10:07 AM, James Y Knight via cfe-dev wrote: > +1 to that. I would strongly suggest that we continue to commit to master > first, like we've always done in llvm. > More generally, I suggest that we keep a discussion about moving hosting and svn->git to *just* those topics. A

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

> 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 release. Given release branches, > there are a number of questions and tradeoffs about how to backport > changes from master/latest d

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

On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote: > > What exactly is the concrete benefit of monotonically increasing > revision numbers? It's completely foreign to git's architecture. > > Putting this requirement on git is going to severely limit how the > history is allowed to look. Maybe th

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

> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev > wrote: > There has been some discussion on IRC about SVN hosting and the perils > of doing it ourselves. The consensus on the current discussion was > that moving to a Git-only solution would have some disvantages, but > many advantages.

[lldb-dev] License & Patents discussion on llvm-dev

FYI, I just started a discussion on llvm-dev about the license & patents situation in the project, it also affects LLDB, so if you’re interested, please check it out there. -Chris ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/