Re: [lldb-dev] Connecting to lldb-rpc-server

The RPC mechanism used in Xcode 8 is not a part of the open source LLDB project and should be treated as an implementation detail of Xcode. What are you trying to accomplish? Kate Stone k8st...@apple.com  Xcode Low Level Tools > On Oct 6, 2016, at 6:11 PM, Rex Fenle

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev > wrote: > > Maybe I have that incorrectly, this does seem to work when using lldb from > Xcode's console. This doesn't work when typing `lldb` into the terminal and > using it from there. I assumed the two were the same. The same underly

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

The storm of commit messages might be a subtle clue, but here it is officially: the reformatting is complete and I’ve verified that no tests regressed locally in our macOS suite. Please begin any validation process you’ve signed up for on another platform, and if changes are necessary go ahead

[lldb-dev] LLDB REFORMATTING IN PROGRESS

As has been discussed over the past few weeks the reformatting of the LLDB code base will take place shortly, followed by validation before committing these changes. Please suspend all commit activity. Any intervening commits will be reverted until the all-clear is given. Kate Stone k8st...@a

Re: [lldb-dev] LLDB Evolution: Next Phase

<mailto:k8st...@apple.com>  Xcode Low Level Tools > On Sep 6, 2016, at 5:06 AM, Ed Maste wrote: > > On 3 September 2016 at 00:30, Kate Stone via lldb-dev > wrote: >> As a reminder, any pending commits you might have planned for LLDB this >> weekend must not break

Re: [lldb-dev] LLDB Evolution: Next Phase

> > Kate Stone k8st...@apple.com <mailto:k8st...@apple.com> >  Xcode Low Level Tools > >> On Aug 18, 2016, at 11:15 AM, Kate Stone via lldb-dev >> mailto:lldb-dev@lists.llvm.org>> wrote: >> >> If there’s consensus on a reasonable automated for

[lldb-dev] LLDB Evolution: Next Phase

swift-lldb repository on GitHub. Any concerns? Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>  Xcode Low Level Tools > On Aug 18, 2016, at 11:15 AM, Kate Stone via lldb-dev > wrote: > > If there’s consensus on a reasonable automated formatting solution for Python &g

Re: [lldb-dev] LLDB Evolution

If there’s consensus on a reasonable automated formatting solution for Python then I’m fine with going ahead and doing so at the same time. The PEP-8 standard would leave Python code with 4-space indentation, and impart a consistent look to our code. Earlier this week I verified that our curre

Re: [lldb-dev] LLDB Evolution

100% agreed, though we do want to avoid multiple formatting passes over time if at all possible. Having exceptions to the comment formatting rules for the entire test suite subtree is acceptable – presuming we aren’t planning to come back and do another pass where we revisit that decision in th

[lldb-dev] CORRECTION: LLDB Evolution

" {}" }' {} \; | sort -nr Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>  Xcode Low Level Tools > On Aug 8, 2016, at 2:40 PM, Kate Stone via lldb-dev > wrote: > > LLDB has come a long way since the project was first announced. As a robust > debugge

Re: [lldb-dev] LLDB Evolution

7;s difficult / impossible right now. > > On Tue, Aug 9, 2016 at 10:00 AM Zachary Turner <mailto:ztur...@google.com>> wrote: > On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > Near-Term Goal: Standardizing on LLVM

Re: [lldb-dev] LLDB Evolution

t place. > > For unit tests in particular, it's nice to be able to link in just the set of > things you need, and that's difficult / impossible right now. > > On Tue, Aug 9, 2016 at 10:00 AM Zachary Turner <mailto:ztur...@google.com>> wrote: > On Mon, Aug 8

[lldb-dev] LLDB Evolution

LLDB has come a long way since the project was first announced. As a robust debugger for C-family languages and Swift, LLDB is constantly in use by millions of developers. It has also become a foundation for bringing up debugger support for other languages like Go and RenderScript. In additio

Re: [lldb-dev] Leaks from static variables

nce its not always just a > simple matter of releasing resources, sometimes actual shutdown code needs to > be interspersed with the cleanup > On Mon, Aug 1, 2016 at 3:15 PM Kate Stone via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > Greg Clayton will almost certainly

Re: [lldb-dev] Leaks from static variables

Greg Clayton will almost certainly want to weigh in here when he returns next week. Generally speaking, we’ve had a long tail of issues that only show up during teardown that we’re avoiding. Leaking resources that will be reclaimed by the OS when the process terminates is a non-issue. If ther

Re: [lldb-dev] Typing in lldb is broken

Agreed. LLDB uses some odd tricks in order to coerce libedit into displaying a different colored prompt, so these extra characters are doubtless a symptom of attempting to use ANSI cursor movement that is being misinterpreted by your terminal emulation. Kate Stone k8st...@apple.com

[lldb-dev] Help text overhaul

I’ve posted a new Phabricator review discussing this change @ http://reviews.llvm.org/D22286 . Comments welcome! LLDB help content has accumulated over time without a recent attempt to review it for consistency, accuracy, and clarity. This patch attempts to addr

[lldb-dev] Proposed change in multi-line edit behavior (Return = end/append, Meta+Return = line break)

I’ve posted a new Phabricator review discussing this change @ http://reviews.llvm.org/D22284. Comments welcome! Editing multi-line content in a terminal environment involves a lot of trade-offs. When LLDB's multi-line editing support was first introduced for expressions / REPL contexts the beh

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

Likewise. The clearly stated intended consequences are well worth promoting, and any unintended consequences can be addressed with good judgement and ongoing revision. Thank you for your efforts to make sure LLVM remains friendly and inclusive. Kate Stone k8st...@apple.com

Re: [lldb-dev] TODAY! Updating to CMake 3.4.3

Have you investigated the impact of the merge downstream to the Swift enabled LLDB in GitHub? It's staged, so we shouldn't do it immediately but it would be helpful to know what to expect. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On May 31, 2016, at 12:

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

Likewise, I'd definitely be in favor of doing so. It would be great to have the entire LLDB development community on GitHub instead of the current story. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On May 31, 2016, at 1:16 PM, Chris Lattner via lldb-dev >

[lldb-dev] Location for system-wide plugins

I’ve put a trivial patch up for review on Phabricator that will change the system-wide directory for LLDB plugins from /usr/lib/lldb to /usr/lib/lldb/plugins. This is just a heads-up for anyone who depends on the existing path. Recursively scanning /usr/lib/lldb alone has made it far too easy

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

Not all platforms use the same C++ name mangling. Clang follows the Itanium ABI specification which is what both the built-in LLDB demanglers understand. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev > wrote: > > Thanks Jim. This

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

The cxa_demangle implementation definitely consumes stack aggressively, especially when compiled -O0. I’d definitely recommend an 8MB+ stack for any thread that may wind up demangling arbitrary C++ symbols. The new “fast demangler” is much more conservative with stack space but doesn’t yet sup

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

The cxa_demangle implementation definitely consumes stack aggressively, especially when compiled -O0. I’d definitely recommend an 8MB+ stack for any thread that may wind up demangling arbitrary C++ symbols. The new “fast demangler” is much more conservative with stack space but doesn’t yet sup

Re: [lldb-dev] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

Yes, IIRC it’s the Microsoft compiler that uses a different mangling. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On Mar 18, 2016, at 4:14 PM, Jim Ingham wrote: > > Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you are > on a platfor

Re: [lldb-dev] clang-format now supports return type on separate line

Agreed. My guidance has been that we go ahead and require submitters to use clang-format for patches, but to acknowledge that there may be cases where this produces undesirable results. Manual formatting to correct these issues is acceptable and should lead to discussions about concrete exampl