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

[Kate Stone via lldb-dev]

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 examples where the 
automated approach is imperfect.

Kate Stone k8st...@apple.com
 Xcode Runtime Analysis Tools

> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Okay, sounds like a reasonable thing to try.  We can always review it if it 
> causes any real issues.
> 
>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner  wrote:
>> 
>> 
>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan  wrote:
>>> I tend to agree with Zachary on the overall principle – and I would be 
>>> willing to clang-format functions when I modify them.  I’m concerned about 
>>> a specific class of functions, though.  Let’s say I have a function that 
>>> has had lots of activity (I’m thinking of, for example, ParseType off in 
>>> the DWARF parser).  Unfortunately, such functions tend to be the ones that 
>>> benefit most from clang-format.
>>> 
>>> In such a function, there’s a lot of useful history available via svn blame 
>>> that helps when fixing bugs.  My concern is that if someone clang-formats 
>>> this function after applying the kth fix, suddenly I've lost convenient 
>>> access to that history.  It’s only available with a fair amount of pain, 
>>> and this pain increases as more fixes are applied because now I need to 
>>> interleave the info before and after reformatting.
>>> 
>>> Would it be reasonable to mark such functions as “Don’t clang-format”?  
>>> That could be also interpreted as a “// TODO add comments so what this does 
>>> is more understandable”
>> 
>> Well again by default it's only going to format the code you touch in yoru 
>> diff plus 1 or 2 surrounding lines.  So having it format an entire function 
>> is something you would have to explicitly go out of your way to do.  So it's 
>> a judgement call.  If you think the function would be better off 
>> clang-formatting the entire thing, do that.  If you just want to format the 
>> lines you're touching because you were in there anyway, that's the default 
>> behavior. 
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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 platform whose primary compiler is gcc and that isn’t very very old, 
> either demangler will be equivalent except for bugs.  The side effects of one 
> or the other are pretty much just that you get a different set of bugs.  So 
> we let the platform owners choose the version they think best.
> 
> Jim
> 
> 
>> On Mar 18, 2016, at 3:54 PM, Kate Stone > > wrote:
>> 
>> 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 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>>> Thanks Jim. This is very helpful. 
>>> We have double checked the libiberty we are building against which seems 
>>> already be updated two weeks ago so this bug might not been fixed yet. 
>>> Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow. 
>>> 
>>> Questions:
>>> 1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms? 
>>> 2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other 
>>> platform?
>>> 
>>> On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham >> > wrote:
>>> The code that has gotten itself into an infinite loop here is the libiberty 
>>> cp-demangle.c, which is part of the C++ runtime libraries for the system 
>>> you are on.  So we can't do anything to fix bugs with that.  You might make 
>>> sure there isn't a newer version of that than the one on your system, but 
>>> other than fixing the bugs in it yourself, there's not much we can do about 
>>> that one.
>>> 
>>> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will 
>>> do two things, it will trigger the FastDemangler that Kate wrote, and if 
>>> that succeeds, yay!  Otherwise it will fall back to another demangler that 
>>> comes along with the C++ standard libraries from the llvm project.  That 
>>> one, like the cp-demangle.c is very stack intensive, but it might not have 
>>> whatever bug you are triggering in the libiberty one.  And if it does have 
>>> crashing bugs somebody in the clang world could fix them...
>>> 
>>> Anyway, you might try that and see if you have any more luck.  IIRC, 
>>> FreeBSD uses the llvm one in favor of the libiberty one.
>>> 
>>> Jim
>>> 
>>> 
>>> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>>> > mailto:lldb-dev@lists.llvm.org>> wrote:
>>> >
>>> > This is crazy. I tried 10MB, not working, then 20MB still not working. I 
>>> > got around 80K frames stack overflow, this is clearly an infinitely loop 
>>> > in "d_print_comp":
>>> >
>>> > (gdb) bt
>>> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>>> > dc=0x7f3586743bb0) at cp-demangle.c:4324
>>> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
>>> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>>> > dc=0x7f3586743ca0) at cp-demangle.c:4489
>>> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
>>> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>>> > dc=0x7f3586744030) at cp-demangle.c:4489
>>> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, mod=) at cp-demangle.c:5539
>>> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
>>> > suffix=suffix@entry=0) at cp-demangle.c:5468
>>> > #7  0x7f35925556a1 in d_print_function_type 
>>> > (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, 
>>> > mods=0x7f358534a7b0, dc=0x7f3586744138) at cp-demangle.c:5609
>>> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
>>> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>>> > dc=0x7f3586744150) at cp-demangle.c:4434
>>> > .
>>> >
>>> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
>>> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
>>> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>>> > options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
>>> > #

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

[Kate Stone via lldb-dev]

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 support 
the full name mangling specification, so complex symbols often rely on falling 
back to cxa_demangle.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Make stacks bigger when making threads on linux?
> 
>> On Mar 17, 2016, at 1:39 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Seems like the crashes happens because of abi::__cxa_demangle() for mangled 
>> symbol name " 
>> _ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect".
>> 
>> This is blocking us from releasing our C++ debugging support. Anyone know of 
>> a quick workaround I can fix it locally? Thanks!
>> 
>> On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev  
>> wrote:
>> Bug ID   26978
>> Summary  LLDB stack overflow while dealing with symbols for a process on 
>> Linux   
>> Product  lldb
>> Version  3.8
>> Hardware PC
>> OS   Linux
>> Status   NEW
>> Severity release blocker
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org
>> Reporter jeffrey.fu...@gmail.com
>> CC   llvm-b...@lists.llvm.org
>> Classification   Unclassified
>> 
>> While using lldb to attach a process in our company on Linux, lldb segment
>> fault with a huge stack(more than 30K stack frames). I assume it crashes
>> because of stack overflow. Let me know what additional information you 
>> needed(I
>> have coredump):
>> 
>> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724b80) at cp-demangle.c:4286
>> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724bb0) at cp-demangle.c:4324
>> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
>> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724c70) at cp-demangle.c:4489
>> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
>> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724ca0) at cp-demangle.c:4493
>> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
>> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725030) at cp-demangle.c:4489
>> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mod=) at cp-demangle.c:5539
>> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
>> suffix=suffix@entry=0) at cp-demangle.c:5468
>> #10 0x7f28ce5366a1 in d_print_function_type 
>> (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
>> cp-demangle.c:5609
>> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
>> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725150) at cp-demangle.c:4434
>> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
>> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
>> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, 
>> options=> out>, dc=0x7f28c2725270) at cp-demangle.c:4793
>> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
>> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c27252a0) at cp-demangle.c:4493
>> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
>> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
>> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725330) at cp-demangle.c:4434
>> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
>> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@en

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

[Kate Stone via lldb-dev]

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 support 
the full name mangling specification, so complex symbols often rely on falling 
back to cxa_demangle.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Make stacks bigger when making threads on linux?
> 
>> On Mar 17, 2016, at 1:39 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Seems like the crashes happens because of abi::__cxa_demangle() for mangled 
>> symbol name " 
>> _ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect".
>> 
>> This is blocking us from releasing our C++ debugging support. Anyone know of 
>> a quick workaround I can fix it locally? Thanks!
>> 
>> On Thu, Mar 17, 2016 at 12:25 PM, via lldb-dev  
>> wrote:
>> Bug ID   26978
>> Summary  LLDB stack overflow while dealing with symbols for a process on 
>> Linux   
>> Product  lldb
>> Version  3.8
>> Hardware PC
>> OS   Linux
>> Status   NEW
>> Severity release blocker
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org
>> Reporter jeffrey.fu...@gmail.com
>> CC   llvm-b...@lists.llvm.org
>> Classification   Unclassified
>> 
>> While using lldb to attach a process in our company on Linux, lldb segment
>> fault with a huge stack(more than 30K stack frames). I assume it crashes
>> because of stack overflow. Let me know what additional information you 
>> needed(I
>> have coredump):
>> 
>> #0  0x7f28ce530819 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724b80) at cp-demangle.c:4286
>> #1  0x7f28ce5321e6 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724bb0) at cp-demangle.c:4324
>> #2  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c10) at cp-demangle.c:4324
>> #3  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724c70) at cp-demangle.c:4489
>> #4  0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724c88) at cp-demangle.c:4923
>> #5  0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2724ca0) at cp-demangle.c:4493
>> #6  0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2724cd0) at cp-demangle.c:4324
>> #7  0x7f28ce532010 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725030) at cp-demangle.c:4489
>> #8  0x7f28ce535353 in d_print_mod (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mod=) at cp-demangle.c:5539
>> #9  0x7f28ce535dbe in d_print_mod_list (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=mods@entry=0x7f28c1f2ba30,
>> suffix=suffix@entry=0) at cp-demangle.c:5468
>> #10 0x7f28ce5366a1 in d_print_function_type 
>> (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, mods=0x7f28c1f2ba30, dc=0x7f28c2725138) at
>> cp-demangle.c:5609
>> #11 0x7f28ce53110c in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725138) at cp-demangle.c:4808
>> #12 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725150) at cp-demangle.c:4434
>> #13 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27251b0) at cp-demangle.c:4324
>> #14 0x7f28ce5336b3 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725108) at cp-demangle.c:4529
>> #15 0x7f28ce534448 in d_print_comp (dpi=0x7f28c2728c00, 
>> options=> out>, dc=0x7f28c2725270) at cp-demangle.c:4793
>> #16 0x7f28ce5319c0 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725288) at cp-demangle.c:4923
>> #17 0x7f28ce532056 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c27252a0) at cp-demangle.c:4493
>> #18 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c27252d0) at cp-demangle.c:4324
>> #19 0x7f28ce534448 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725318) at cp-demangle.c:4793
>> #20 0x7f28ce530a01 in d_print_comp (dpi=0x7f28c2728c00, options=17,
>> dc=0x7f28c2725330) at cp-demangle.c:4434
>> #21 0x7f28ce5321e6 in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@entry=17, dc=0x7f28c2725390) at cp-demangle.c:4324
>> #22 0x7f28ce53123b in d_print_comp (dpi=dpi@entry=0x7f28c2728c00,
>> options=options@en

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

[Kate Stone via lldb-dev]

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 is very helpful. 
> We have double checked the libiberty we are building against which seems 
> already be updated two weeks ago so this bug might not been fixed yet. 
> Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow. 
> 
> Questions:
> 1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms? 
> 2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other 
> platform?
> 
>> On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham  wrote:
>> The code that has gotten itself into an infinite loop here is the libiberty 
>> cp-demangle.c, which is part of the C++ runtime libraries for the system you 
>> are on.  So we can't do anything to fix bugs with that.  You might make sure 
>> there isn't a newer version of that than the one on your system, but other 
>> than fixing the bugs in it yourself, there's not much we can do about that 
>> one.
>> 
>> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will 
>> do two things, it will trigger the FastDemangler that Kate wrote, and if 
>> that succeeds, yay!  Otherwise it will fall back to another demangler that 
>> comes along with the C++ standard libraries from the llvm project.  That 
>> one, like the cp-demangle.c is very stack intensive, but it might not have 
>> whatever bug you are triggering in the libiberty one.  And if it does have 
>> crashing bugs somebody in the clang world could fix them...
>> 
>> Anyway, you might try that and see if you have any more luck.  IIRC, FreeBSD 
>> uses the llvm one in favor of the libiberty one.
>> 
>> Jim
>> 
>> 
>> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>> >  wrote:
>> >
>> > This is crazy. I tried 10MB, not working, then 20MB still not working. I 
>> > got around 80K frames stack overflow, this is clearly an infinitely loop 
>> > in "d_print_comp":
>> >
>> > (gdb) bt
>> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743bb0) at cp-demangle.c:4324
>> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
>> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743ca0) at cp-demangle.c:4489
>> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
>> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744030) at cp-demangle.c:4489
>> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mod=) at cp-demangle.c:5539
>> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
>> > suffix=suffix@entry=0) at cp-demangle.c:5468
>> > #7  0x7f35925556a1 in d_print_function_type 
>> > (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, 
>> > mods=0x7f358534a7b0, dc=0x7f3586744138) at cp-demangle.c:5609
>> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
>> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744150) at cp-demangle.c:4434
>> > .
>> >
>> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
>> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
>> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
>> > #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
>> > #79594 0x7f3592555f53 in d_demangle_callback (options=17, 
>> > opaque=0x7f3586742cc0, callback=0x7f359254b820 
>> > , dc=0x7f3586744468) at 
>> > cp-demangle.c:4063
>> > #79595 0x7f3592555f53 in d_demangle_callback (mangled=,
>> > mangled@entry=0x0, callback=callback@entry=0x7f359254b820 
>> > , opaque=opaque@entry=0x7f3586747db0, 
>> > options=17) at cp-demangle.c:5865
>> > #79596 0x7f359255609f in __cxa_demangle (options=17, palc=> > pointer>, mangled=0x0) at cp-demangle.c:5886
>> >
>> > #79597 0x7f359255609f in __cxa_demangle 
>> > (mangled_name=mangled_name@entry=0x7f3570e3d460 
>> > "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1

[lldb-dev] Location for system-wide plugins

[Kate Stone via lldb-dev]

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 to add files to LLDB that are dynamically loaded without meaning to 
(notably ASAN enabled libraries that then terminate the LLDB process 
immediately because the ASAN runtime isn't present.)

http://reviews.llvm.org/D19516

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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 
>  wrote:
> 
>> 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. Furthermore, not hosting our own repos would save us
>> a lot of headaches, admin costs and timed out connections.
> 
> Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
> some point, despite the fact that I continue to dislike git as a tool and 
> consider monotonicly increasing version numbers to be hugely beneficial.
> 
> The killer feature to me is the community aspects of github, allowing people 
> to get involved in the project more easily and make “drive by” contributions 
> through the pull request model.  Github also has a very scriptable interface, 
> allowing integration of external bug trackers etc into the workflow (which is 
> good, because its bugtracker is anemic).
> 
>> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
>> etc. Not only this incurs in additional admin cost, but it also gets
>> outdated, locally modified, and it needs to be backed up, etc. GitHub
>> gives all that for us for free.
> 
> Yes, it would be great to get out of this business.
> 
>> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
>> we can also use GitHub's system to manage releases (it's actually
>> quite good for that).
> 
> If we made this change, I think we should only change one thing at a time: 
> change source hosting, but not phabricator or the bug tracker.  We could then 
> discuss moving off phabricator to the github PR model, etc.
> 
>> 6. GitHub has automated testing of merge requests, meaning we can have
>> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
>> own validation hooks.
> 
> This works pretty well.  The major problem is with tests that are flakey.
> 
> -Chris
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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:12 PM, Chris Bieneman via lldb-dev 
>  wrote:
> 
> One more thing I want to note on this thread.
> 
> For anyone looking at the patches. I’ve intentionally tried to make them 
> minimal. After the patches have landed and stayed on trunk without issue for 
> a while I’ll start doing cleanup around all the CMake version checks.
> 
> I’d like to not open the flood gates on those kinds of cascading changes in 
> case these patches need to be reverted for some reason.
> 
> Thanks,
> -Chris
> 
>> On May 31, 2016, at 11:22 AM, Chris Bieneman via lldb-dev 
>>  wrote:
>> 
>> Just an FYI. Later today I’ll be updating the CMake minimum version to 
>> 3.4.3. In advance of the transition I’ve posted a bunch of patches:
>> 
>> LLVM: http://reviews.llvm.org/D20822
>> Clang: http://reviews.llvm.org/D20823
>> Compiler-RT: http://reviews.llvm.org/D20824
>> LLDB: http://reviews.llvm.org/D20826
>> libcxx: http://reviews.llvm.org/D20828
>> libcxxabi: http://reviews.llvm.org/D20829
>> 
>> I will commit the patches early this afternoon. 
>> 
>> I received a lot of responses from bot owners on my last thread 
>> (http://lists.llvm.org/pipermail/llvm-dev/2016-May/100058.html), so I think 
>> we’ll be in good shape, but I will be watching closely.
>> 
>> If you maintain a bot that *hasn’t* yet been updated please contact me right 
>> away so that we can coordinate.
>> 
>> Thanks,
>> -Chris
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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 
 Xcode Low Level Tools

> On Jun 30, 2016, at 1:18 PM, Jim Grosbach via lldb-dev 
>  wrote:
> 
> Thanks, Chandler, for all your work on this. I’m glad to see this moving 
> forward.
> 
> -Jim
> 
>> On Jun 30, 2016, at 11:55 AM, Chandler Carruth via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>> 
>> Hello folks,
>> 
>> As mentioned some time ago[1], we’ve had a long (looong) series of 
>> discussions about establishing a code-of-conduct for the LLVM project as a 
>> whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 
>>  code review.
>> 
>> The discussion has largely died down for some time, and towards the end 
>> there has been pretty wide support for the draft wording we have now. It 
>> isn’t perfect, and there are still some important questions around forming 
>> the advisory committee to handle reporting, but I think the wording is at a 
>> good point of compromise in a challenging area.
>> 
>> Based on the support, I’m going to land the patch that adds the draft. I’m 
>> hoping this will immediately provide good advice and guidance, and I’m 
>> hoping to see motion on setting up a reasonable advisory committee and 
>> resolving any issues around reporting so we can make this an official part 
>> of the community.
>> 
>> I sending this as a heads up so folks are aware, not to start a new 
>> discussion thread. There are existing discussion threads[2] on llvm-dev if 
>> folks want to join in active discussion or we can start fresh ones, but I 
>> would encourage people to carefully read the discussion that has already 
>> taken place to avoid revisiting areas that have already been heavily 
>> discussed.
>> 
>> Also, many thanks to the folks who provided all their opinions on the 
>> mailing list threads and in person in long discussions about this topic.
>> 
>> Thanks,
>> -Chandler
>> 
>> [1]: Prior announcements:
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html 
>> 
>> http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html 
>> 
>> http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html 
>> 
>> http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html 
>> 
>> 
>> [2]: Existing threads:
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html 
>> 
>> http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html 
>> 
>> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html
>>  
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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 behavior was as follows:

The Return key is treated as a line-break except at the end of the input 
buffer, where a completeness test is applied

This worked well enough when writing code, and makes it trivial to insert new 
lines above code you've already typed. Just use cursor navigation to move up 
and type freely. Where it was awkward is that the gesture to insert a line 
break and end editing is conflated for most people. Sometimes you want Return 
to end the editing session and other times you want to insert a line break.

This patch proposes a change in the behavior as follows:

The Return key is treated as the end of editing except at the end of the input 
buffer, where a completeness test is applied
The Meta+Return sequence is always treated as a line break. This is consistent 
with conventions in Facebook and elsewhere since Alt/Option+Return is often 
mapped to Meta+Return. The unfortunate exception is on macOS where this *can* 
be the case, but isn't by default. Sigh.

Note that by design both before and after the patch pasting a Return character 
always introduces a line break.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Help text overhaul

[Kate Stone via lldb-dev]

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 address all 
of the above while keeping the text relatively terse.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

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 
 Xcode Low Level Tools

> On Jul 18, 2016, at 2:29 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hi,
> 
> This is probably some interaction between LLDB *and* your terminal.
> Hard to say why without knowing your environment. Could you check how
> is your terminal configured (unicode yes/no, which emulation mode,
> codepage, ...). Also try running "env" in your terminal and check for
> anything out of place there. If you send these items over, someone
> might be able to help.
> 
> good luck,
> pl
> 
> 
> On 17 July 2016 at 18:40, Yury Meshkov via lldb-dev
>  wrote:
>> Hi All,
>> 
>> After recent upgrade when I launch lldb and type any command I see something
>> like this:
>> (lldb) \U+73464\U+7346A\U+7340A\U+7340A
>> 
>> I can't even exit from lldb. I have to kill it in another terminal. Not sure
>> if it is relevant but I am using arch linux. No any other app behaves like
>> that. Is this lldb bug or something wrong with my terminal settings?
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Leaks from static variables

[Kate Stone via lldb-dev]

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 there are specific 
scenarios where a long-lived process leaks significant content that isn’t an 
effective cache for subsequent use, please outline how that manifests.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> It looks like the debugger initializes static variables in llvm (see:
> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
> 
> Does this cause memory leaks? I'd assumed that it's necessary to call
> llvm_shutdown() somewhere to avoid this kind of leak.
> 
> Is there a buildbot I can check that tests an address-sanitized version of
> lldb?
> 
> thanks,
> vedant
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Leaks from static variables

[Kate Stone via lldb-dev]

Agreed that it’s a defect and should be addressed.  It mostly a question of 
prioritization relative to other work, so knowing about a specific scenario 
where this is a pressing issue would be valuable.

Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
 Xcode Low Level Tools

> On Aug 1, 2016, at 3:25 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> If you're linking against liblldb you can't rely on the os cleaning up 
> because you could unload liblldb before shutting down the process.
> 
> Also it's good practice to do explicit cleanup since 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 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 there are 
> specific scenarios where a long-lived process leaks significant content that 
> isn’t an effective cache for subsequent use, please outline how that 
> manifests.
> 
> Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
>  Xcode Low Level Tools
> 
> 
>> On Aug 1, 2016, at 2:40 PM, Vedant Kumar via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
> 
>> Hi lldb-dev,
>> 
>> It looks like the debugger initializes static variables in llvm (see:
>> SystemInitializerFull::Initialize()), but, AFAICT, it never cleans them up.
>> 
>> Does this cause memory leaks? I'd assumed that it's necessary to call
>> llvm_shutdown() somewhere to avoid this kind of leak.
>> 
>> Is there a buildbot I can check that tests an address-sanitized version of
>> lldb?
>> 
>> thanks,
>> vedant
> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB Evolution

[Kate Stone via lldb-dev]

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 addition to 
the original macOS implementation the Linux LLDB port is in active use and 
Windows support has made significant strides.  IDE and editor integration via 
both SB APIs and MI have made LLDB available to even more users.  It’s 
definitely a project every contributor can be proud of and I’d like to take a 
moment to thank everyone who has been involved in one way or another.

It’s also a project that shows some signs of strain due to its rapid growth.  
We’ve accumulated some technical debt that must be paid off, and in general it 
seems like a good time to reflect on where we'll be headed next.  We’ve 
outlined a few goals for discussion below as well as one more short-term 
action.  Discussion is very much encouraged.

Forward-Looking Goals

   1.   Testing Strategy Evaluation

Keeping our code base healthy is next to impossible without a robust testing 
strategy.  Our existing suite of tests is straightforward to run locally, and 
serves as a foundation for continuous integration.  That said, it is definitely 
not exhaustive.  Obvious priorities for improvement include gathering coverage 
information, investing in more conventional unit tests in addition to the suite 
of end-to-end tests, and introducing tests in code bases where we depend on 
debugger-specific behavior (e.g.: for expression evaluation.)

   2.   C++ Module Support

LLDB takes advantage of Clang modules for type information and expression 
evaluation.  This has been used extensively for C and Objective-C scenarios, 
but Clang C++ module support is now mature enough that we can extend our 
support accordingly.  Fully embracing C++ modules will enable LLDB expressions 
to take advantage of template declarations and other constructs that are better 
represented by declarations than the artifacts produced during compilation.

   3.   Establishing Language Integration Standards

As more languages build on LLDB’s foundation the project runs the risk of 
growing deep dependencies on a wide variety of compilers and runtimes.  The 
community needs to engage in a constructive conversation about how best to keep 
the core of LLDB clean and allow language support to be plugged in.  Whether 
this should occur at compile-time or runtime and how best to organize 
repositories and branches to meet the needs of our diverse community will be an 
ongoing topic of discussion.

   4.   Good Citizenship in the LLVM Community

Last, but definitely not least, LLDB should endeavor to be a good citizen of 
the LLVM community.  We should encourage developers to think of the technology 
stack as a coherent effort, where common code should be introduced at an 
appropriate level in the stack.  Opportunities to factor reusable aspects of 
the LLDB code base up the stack into LLVM will be pursued.

One arbitrary source of inconsistency at present is LLDB’s coding standard.  
That brings us to…

Near-Term Goal: Standardizing on LLVM-style clang-format Rules

We’ve heard from several in the community that would prefer to have a single 
code formatting style to further unify the two code bases.  Using clang-format 
with the default LLVM conventions would simplify code migration, editor 
configuration, and coding habits for developers who work in multiple LLVM 
projects.  There are non-trivial implications to reformatting a code base with 
this much history.  It can obfuscate history and impact downstream projects by 
complicating merges.  Ideally, it should be done once with as much advance 
notice as is practical.  Here’s the timeline we’re proposing:

Today - mechanical reformatting proposed, comment period begins

To get a preview of what straightforward reformatting of the code looks like, 
just follow these steps to get a clean copy of the repository and reformat it:
Check out a clean copy of the existing repository
Edit .clang-format in the root of the tree, remove all but the line 
“BasedOnStyle: LLVM”
Change your current working directory to the root of the tree to reformat
Double-check to make sure you did step 3 ;-)
Run the following shell command: "find . -name "*.[c,cpp,h] -exec clang-format 
-i {} +"

Aug 20th - comment period closes, final schedule proposed
TBD (early September?) - patches land in svn

The purpose of the comment period is to review the straightforward diffs to 
identify areas where comment pragmas should be used to avoid undesirable 
formatting (tables laid out in code are a classic example.)  It’s also a time 
when feedback on the final timetable can be discussed, and any unforeseen 
implications can be discovered.  We understand that LLDB tends toward 
relatively long names that may not always work well with the LLVM convention of 
wrapping 

Re: [lldb-dev] LLDB Evolution

[Kate Stone via lldb-dev]

Great catch!  If refactoring along those lines doesn’t clean up 100% of the 
cases then it’s worth explicitly breaking up groups of #include directives with 
comments.  clang-format won’t reorder any non-contiguous groups and it’s a 
great way to explicitly call out dependencies.

Ideally we should be focused on committing changes along these lines so that 
there’s no post-format tweaking required to build cleanly again.

Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
 Xcode Low Level Tools

> On Aug 9, 2016, at 1:03 PM, Zachary Turner  wrote:
> 
> I ran clang-format and tried to build and got a bunch of compiler errors.  
> Most of them are order of include errors.  I fixed everything in the attached 
> patch.  I doubt this will apply cleanly for anyone unless you are at the 
> exact same revision as me, but at least you can look at it and get an idea of 
> what had to change.
> 
> The #include win32.h thing is really annoying and hard for people to remember 
> the right incantation.  I'm going to make a file called Host/PosixApi.h which 
> you can just include, no matter what platform you're on, and everything will 
> just work.  That should clean up a lot of this nonsense.
> 
> On Tue, Aug 9, 2016 at 11:10 AM Zachary Turner  <mailto:ztur...@google.com>> wrote:
> Another thing worth thinking about for the long term is library layering and 
> breaking the massive dependency cycle in LLDB.  Every library currently 
> depends on every other library.  This isn't good for build times, code size, 
> or reusability (especially where size matters like in lldb-server).  I think 
> the massive Python dependency was removed after my work earlier this year.  
> But I'm not sure what the status of that is now, and there's still the rest 
> of LLDB.
> 
> In the future it would be nice to have a modules build of LLDB.  And sure, we 
> could just have liblldb be one giant module, but that seems to kind of defeat 
> the purpose of modules in the first 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, 2016 at 2:40 PM Kate Stone via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Near-Term Goal: Standardizing on LLVM-style clang-format Rules
> 
> We’ve heard from several in the community that would prefer to have a single 
> code formatting style to further unify the two code bases.  Using 
> clang-format with the default LLVM conventions would simplify code migration, 
> editor configuration, and coding habits for developers who work in multiple 
> LLVM projects.  There are non-trivial implications to reformatting a code 
> base with this much history.  It can obfuscate history and impact downstream 
> projects by complicating merges.  Ideally, it should be done once with as 
> much advance notice as is practical.  Here’s the timeline we’re proposing:
> 
> Today - mechanical reformatting proposed, comment period begins
> 
> To get a preview of what straightforward reformatting of the code looks like, 
> just follow these steps to get a clean copy of the repository and reformat it:
> Check out a clean copy of the existing repository
> Edit .clang-format in the root of the tree, remove all but the line 
> “BasedOnStyle: LLVM”
> Change your current working directory to the root of the tree to reformat
> Double-check to make sure you did step 3 ;-)
> Run the following shell command: "find . -name "*.[c,cpp,h] -exec 
> clang-format -i {} +"
> 
> Aug 20th - comment period closes, final schedule proposed
> TBD (early September?) - patches land in svn
> 
> The purpose of the comment period is to review the straightforward diffs to 
> identify areas where comment pragmas should be used to avoid undesirable 
> formatting (tables laid out in code are a classic example.)  It’s also a time 
> when feedback on the final timetable can be discussed, and any unforeseen 
> implications can be discovered.  We understand that LLDB tends toward 
> relatively long names that may not always work well with the LLVM convention 
> of wrapping at 80 columns.  Worst case scenarios will be evaluated to 
> determine the desired course of action.
> 
> One thing we will need to take a look at is functions which have a very deep 
> indentation level. They have the potential to be made really ugly by 
> clang-format.  The default indentation will be reduced from 4 to 2, so that 
> will help, but I recall we had some lines that began very far to the right.  
> 
> Here's a little bash command shows all lines with >= 50 leading

Re: [lldb-dev] LLDB Evolution

[Kate Stone via lldb-dev]

Agreed that better layering and modularization is a worthwhile longer-term 
goal.  These kinds of changes should be researched and proposed for discussion 
because code reorganization can be extremely disruptive (which is why we opened 
this comment period for the proposed reformatting!)  I’d generally argue for 
focusing on breaking out larger blocks of functionality where focused testing 
will yield results rather than a lot of fine-grained change.

Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
 Xcode Low Level Tools

> On Aug 9, 2016, at 11:10 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Another thing worth thinking about for the long term is library layering and 
> breaking the massive dependency cycle in LLDB.  Every library currently 
> depends on every other library.  This isn't good for build times, code size, 
> or reusability (especially where size matters like in lldb-server).  I think 
> the massive Python dependency was removed after my work earlier this year.  
> But I'm not sure what the status of that is now, and there's still the rest 
> of LLDB.
> 
> In the future it would be nice to have a modules build of LLDB.  And sure, we 
> could just have liblldb be one giant module, but that seems to kind of defeat 
> the purpose of modules in the first 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, 2016 at 2:40 PM Kate Stone via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Near-Term Goal: Standardizing on LLVM-style clang-format Rules
> 
> We’ve heard from several in the community that would prefer to have a single 
> code formatting style to further unify the two code bases.  Using 
> clang-format with the default LLVM conventions would simplify code migration, 
> editor configuration, and coding habits for developers who work in multiple 
> LLVM projects.  There are non-trivial implications to reformatting a code 
> base with this much history.  It can obfuscate history and impact downstream 
> projects by complicating merges.  Ideally, it should be done once with as 
> much advance notice as is practical.  Here’s the timeline we’re proposing:
> 
> Today - mechanical reformatting proposed, comment period begins
> 
> To get a preview of what straightforward reformatting of the code looks like, 
> just follow these steps to get a clean copy of the repository and reformat it:
> Check out a clean copy of the existing repository
> Edit .clang-format in the root of the tree, remove all but the line 
> “BasedOnStyle: LLVM”
> Change your current working directory to the root of the tree to reformat
> Double-check to make sure you did step 3 ;-)
> Run the following shell command: "find . -name "*.[c,cpp,h] -exec 
> clang-format -i {} +"
> 
> Aug 20th - comment period closes, final schedule proposed
> TBD (early September?) - patches land in svn
> 
> The purpose of the comment period is to review the straightforward diffs to 
> identify areas where comment pragmas should be used to avoid undesirable 
> formatting (tables laid out in code are a classic example.)  It’s also a time 
> when feedback on the final timetable can be discussed, and any unforeseen 
> implications can be discovered.  We understand that LLDB tends toward 
> relatively long names that may not always work well with the LLVM convention 
> of wrapping at 80 columns.  Worst case scenarios will be evaluated to 
> determine the desired course of action.
> 
> One thing we will need to take a look at is functions which have a very deep 
> indentation level. They have the potential to be made really ugly by 
> clang-format.  The default indentation will be reduced from 4 to 2, so that 
> will help, but I recall we had some lines that began very far to the right. 
> 
> Here's a little bash command shows all lines with >= 50 leading spaces, 
> sorted in descending order by number of leading spaces.
> 
> grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n", 
> $0, t-length($0));}' |  sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; { if 
> ($3 >= 50) print $0 }' 
> 
> It's less useful than I was hoping because most of the lines are noise (line 
> breaking in a function parameter list).
> 
> If there were a way to detect indentation level that would be better.  Mostly 
> just to identify places that we should manually inspect after running 
> clang-format.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] CORRECTION: LLDB Evolution

[Kate Stone via lldb-dev]

Note that step 5 below is wildly inaccurate, a placeholder while drafting the 
note.  The actual command to reformat should be:

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.cpp" \) -exec 
clang-format -i {} +

If you’re curious where the longest lines in the original or resulting source 
come from you can try the following in an unformatted or post-formatting 
repository:

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.cpp" \) -exec awk '{ if 
(length($0) > max) max = length($0) } END { print max " {}" }' {} \; | 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 
> 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 addition 
> to the original macOS implementation the Linux LLDB port is in active use and 
> Windows support has made significant strides.  IDE and editor integration via 
> both SB APIs and MI have made LLDB available to even more users.  It’s 
> definitely a project every contributor can be proud of and I’d like to take a 
> moment to thank everyone who has been involved in one way or another.
> 
> It’s also a project that shows some signs of strain due to its rapid growth.  
> We’ve accumulated some technical debt that must be paid off, and in general 
> it seems like a good time to reflect on where we'll be headed next.  We’ve 
> outlined a few goals for discussion below as well as one more short-term 
> action.  Discussion is very much encouraged.
> 
> Forward-Looking Goals
> 
>1. Testing Strategy Evaluation
> 
> Keeping our code base healthy is next to impossible without a robust testing 
> strategy.  Our existing suite of tests is straightforward to run locally, and 
> serves as a foundation for continuous integration.  That said, it is 
> definitely not exhaustive.  Obvious priorities for improvement include 
> gathering coverage information, investing in more conventional unit tests in 
> addition to the suite of end-to-end tests, and introducing tests in code 
> bases where we depend on debugger-specific behavior (e.g.: for expression 
> evaluation.)
> 
>2. C++ Module Support
> 
> LLDB takes advantage of Clang modules for type information and expression 
> evaluation.  This has been used extensively for C and Objective-C scenarios, 
> but Clang C++ module support is now mature enough that we can extend our 
> support accordingly.  Fully embracing C++ modules will enable LLDB 
> expressions to take advantage of template declarations and other constructs 
> that are better represented by declarations than the artifacts produced 
> during compilation.
> 
>3. Establishing Language Integration Standards
> 
> As more languages build on LLDB’s foundation the project runs the risk of 
> growing deep dependencies on a wide variety of compilers and runtimes.  The 
> community needs to engage in a constructive conversation about how best to 
> keep the core of LLDB clean and allow language support to be plugged in.  
> Whether this should occur at compile-time or runtime and how best to organize 
> repositories and branches to meet the needs of our diverse community will be 
> an ongoing topic of discussion.
> 
>4. Good Citizenship in the LLVM Community
> 
> Last, but definitely not least, LLDB should endeavor to be a good citizen of 
> the LLVM community.  We should encourage developers to think of the 
> technology stack as a coherent effort, where common code should be introduced 
> at an appropriate level in the stack.  Opportunities to factor reusable 
> aspects of the LLDB code base up the stack into LLVM will be pursued.
> 
> One arbitrary source of inconsistency at present is LLDB’s coding standard.  
> That brings us to…
> 
> Near-Term Goal: Standardizing on LLVM-style clang-format Rules
> 
> We’ve heard from several in the community that would prefer to have a single 
> code formatting style to further unify the two code bases.  Using 
> clang-format with the default LLVM conventions would simplify code migration, 
> editor configuration, and coding habits for developers who work in multiple 
> LLVM projects.  There are non-trivial implications to reformatting a code 
> base with this much history.  It can obfuscate history and impact downstream 
> projects by complicating merges.  Ideally, it should be done once with as 
> much advance notice as is practical.  Here’s the timeline we’re proposi

Re: [lldb-dev] LLDB Evolution

[Kate Stone via lldb-dev]

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 the near future.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Aug 11, 2016, at 9:57 AM, Chris Lattner via lldb-dev 
>  wrote:
> 
> 
>> 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 running the test suite I got about 150 failures.
>> Based on a sample of the errors, it looks like the problem is that
>> clang format messes up the "// Place breakpoint here" annotations we
>> use in the tests.
>> Therefore, I propose to apply the clang-format to the lldb source code
>> only as a first step. After that, as a second step, we can go through
>> the tests and fix them up so that the comment markers are where we
>> expect them to be.
> 
> Personally, I think that reformatting is most valuable for the debugger code 
> itself.  The testsuite following standards seems like a separable issue, and 
> much lower priority.
> 
> -Chris
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Evolution

[Kate Stone via lldb-dev]

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 current 
repository builds and passes tests cleanly under the following conditions:

LLVM-style default .clang-format specified at the root of the tree:

BasedOnStyle: LLVM

Formatting disabled using .clang-format in packages/Python/lldbsuite.  It’s not 
just a matter of comment style and location driving tests.  The tests 
themselves are exercising debugging functionality driven by debug information 
line tables.  Debugging behavior can and will change when using line-oriented 
requests (breakpoint on a particular line, step over a particular line, etc.):

DisableFormat: true

# Disabling formatting doesn't implicitly disable include sorting
SortIncludes: false

Formatting automatically applied for all .c, .h, and .cpp sources in the tree

I’ll run the full suite again following reformatting using autopep8 
 for all .py files.

Thanks to everyone who has chimed in with suggestions, and with contributions 
to ensure that include ordering doesn’t become an issue on other platforms.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> 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- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
> 
> 
> (Comment from the peanut gallery...)
> 
> Python does have a language-level style guide (PEP-8):
> 
> https://www.python.org/dev/peps/pep-0008/ 
> 
> 
> If code is going to be reformatted, then it may be best to try to converge on 
> exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an 
> active contributor), but someone with Python background, anything that 
> diverges from standard Python style seems jarring (at least to me).
> 
>  
> It will take some editor tweaking to make it use the correct indent
> for different files, but it should be manageable.
> 
> pl
> 
> On 12 August 2016 at 18:13, Jim Ingham  > wrote:
> >
> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev 
> >> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>
> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> >> mailto:lldb-dev@lists.llvm.org>> wrote:
> >>> I recommend approaching this in three steps:
> >>>
> >>> 1) get the less-controversial changes done that Greg was outlining.
> >>> 2) start a discussion in the llvm community about the concept of a
> >>> member/global prefix.
> >>> 2a) the community could agree that llvm-as-a-whole should move to prefixes
> >>> or otherwise change the camel case policy.
> >>> 2b) the community could agree that the existing policies are preferred
> >>> 3) LLDB moves to whatever is the end result of the discussion.
> >>>
> >>> I guess what I’m saying is that since the opinions about this are very
> >>> strong, and because we haven’t really had that debate in the LLVM 
> >>> community,
> >>> that it would be bad to proactively move to the LLVM style, simply to have
> >>> to move back later.  Iff the (sure to be extensive) community discussion
> >>> settles on the idea that prefixes are the wrong thing, then LLDB should
> >>> remove them to be consistent.
> >>>
> >>> -Chris
> >>
> >> +1
> >>
> >>
> >>
> >> In terms of the formatting of tests, I did some more research on this.
> >> I think the changes needed to be made to the test suite are generally
> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
> >> does prevent clang-format from breaking the comment, but it does not
> >> prevent it from moving the whole comment to a new line. That said,
> >> when I reformatted the test sources with CommentPragmas set, the
> >> number of failures went down to 80 (from about 150)...
> >>
> >> I believe we should still perform the reformatting of the tests, at
> >> least to standardize on the 2 space indent (in fact we should consider
> >> doing the same for the python code as well, I don't know what's the
> >> situation there in llvm land), but it can be done later. It will make
> >> the period while the code is in flux longer, but hopefully not too
> >> long. Also the modifications will be independent of the main reformat,
> >> so it will still be true that a single source file only got
> >> reformatted once.
> >>
> >
> > My eyes put in a vote for not reformatting the Python to 2 space tabs. In 
> > C++, most IDE's do smart things with double-

[lldb-dev] LLDB Evolution: Next Phase

[Kate Stone via lldb-dev]

Following up from yesterday, everything now builds and runs cleanly with the 
configuration described below on macOS.  I did have to make one set of minor 
changes to preserve #include ordering, but that’s already committed to trunk so 
there are no true blockers at this point.  To keep pushing forward I’d like to 
propose the following final schedule for comment:

Today-Sept 4th  Any final changes to prevent automatic formatting (see existing 
uses of // clang-format off and // clang-format on in source for  reference.
Sept 5thTrunk closes for commits while reformatting 
takes place and is validated before re-opening trunk.

Following the reformatting trying to merge the resulting diff will be a 
nightmare for anyone with their own long-lived branch or fork of the project.  
We’ll include a commit message describing the situation, but the sanest move is 
almost certainly to merge all diffs up to the formatting exercise and then 
simply format your own branch independently in lieu of actually attempting the 
merge.  We will ensure that nothing takes place in that commit aside from the 
automated formatting.

We’ll be following the same strategy with the 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 
> 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 current 
> repository builds and passes tests cleanly under the following conditions:
> 
> LLVM-style default .clang-format specified at the root of the tree:
> 
> BasedOnStyle: LLVM
> 
> Formatting disabled using .clang-format in packages/Python/lldbsuite.  It’s 
> not just a matter of comment style and location driving tests.  The tests 
> themselves are exercising debugging functionality driven by debug information 
> line tables.  Debugging behavior can and will change when using line-oriented 
> requests (breakpoint on a particular line, step over a particular line, etc.):
> 
> DisableFormat: true
> 
> # Disabling formatting doesn't implicitly disable include sorting
> SortIncludes: false
> 
> Formatting automatically applied for all .c, .h, and .cpp sources in the tree
> 
> I’ll run the full suite again following reformatting using autopep8 
> <https://pypi.python.org/pypi/autopep8> for all .py files.
> 
> Thanks to everyone who has chimed in with suggestions, and with contributions 
> to ensure that include ordering doesn’t become an issue on other platforms.
> 
> Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
>  Xcode Low Level Tools
> 
>> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> 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- character indent, with 4
>> being the most prevalent. So, I think we can safely stay with status
>> quo.
>> 
>> 
>> (Comment from the peanut gallery...)
>> 
>> Python does have a language-level style guide (PEP-8):
>> 
>> https://www.python.org/dev/peps/pep-0008/ 
>> <https://www.python.org/dev/peps/pep-0008/>
>> 
>> If code is going to be reformatted, then it may be best to try to converge 
>> on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an 
>> active contributor), but someone with Python background, anything that 
>> diverges from standard Python style seems jarring (at least to me).
>> 
>>  
>> It will take some editor tweaking to make it use the correct indent
>> for different files, but it should be manageable.
>> 
>> pl
>> 
>> On 12 August 2016 at 18:13, Jim Ingham > <mailto:jing...@apple.com>> wrote:
>> >
>> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev 
>> >> mailto:lldb-dev@lists.llvm.org>> wrote:
>> >>
>> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
>> >> mailto:lldb-dev@lists.llvm.org>> wrote:
>> >>> I recommend approaching this in three steps:
>> >>>
>> >>> 1) get the less-controversial changes done that Greg was outlining.
>> >>> 2) start a discussion in the llvm community about the concept of a
>> >>> m

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

[Kate Stone via lldb-dev]

As a reminder, any pending commits you might have planned for LLDB this weekend 
must not break any of the bots we’re using to validate the health of the source 
tree.  Thanks to everyone who nominated a validation process for the pending 
reformatting.  We’ll assume that each of these validation efforts will proceed 
in parallel following the reformatting commit.

A few quick comments on how that process will work:

The reformatting will take place one day later than originally scheduled on 
September 6th in observance of the North American holiday on Monday.
Tuesday morning the .clang-format changes will go in as one commit, and nothing 
else should follow it until the reformatting is complete.  The reformatting 
changes will be the very next commit and will go in as one large change to 
facilitate the use of tools like git hyper-blame.
I’ll verify that no tests are broken on macOS before committing, because the 
reformatting commit will not be reverted.
Anything that does break on another platform should be fixed with a subsequent 
commit on top of the reformatted code.

Have a fantastic weekend, and for those in the that observe it, a pleasant 
Labor/Labour Day!

Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
 Xcode Low Level Tools

> On Aug 19, 2016, at 2:10 PM, Kate Stone  wrote:
> 
> Following up from yesterday, everything now builds and runs cleanly with the 
> configuration described below on macOS.  I did have to make one set of minor 
> changes to preserve #include ordering, but that’s already committed to trunk 
> so there are no true blockers at this point.  To keep pushing forward I’d 
> like to propose the following final schedule for comment:
> 
> Today-Sept 4thAny final changes to prevent automatic formatting (see 
> existing uses of // clang-format off and // clang-format on in source for  
> reference.
> Sept 5th  Trunk closes for commits while reformatting 
> takes place and is validated before re-opening trunk.
> 
> Following the reformatting trying to merge the resulting diff will be a 
> nightmare for anyone with their own long-lived branch or fork of the project. 
>  We’ll include a commit message describing the situation, but the sanest move 
> is almost certainly to merge all diffs up to the formatting exercise and then 
> simply format your own branch independently in lieu of actually attempting 
> the merge.  We will ensure that nothing takes place in that commit aside from 
> the automated formatting.
> 
> We’ll be following the same strategy with the 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 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> 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 
>> current repository builds and passes tests cleanly under the following 
>> conditions:
>> 
>> LLVM-style default .clang-format specified at the root of the tree:
>> 
>> BasedOnStyle: LLVM
>> 
>> Formatting disabled using .clang-format in packages/Python/lldbsuite.  It’s 
>> not just a matter of comment style and location driving tests.  The tests 
>> themselves are exercising debugging functionality driven by debug 
>> information line tables.  Debugging behavior can and will change when using 
>> line-oriented requests (breakpoint on a particular line, step over a 
>> particular line, etc.):
>> 
>> DisableFormat: true
>> 
>> # Disabling formatting doesn't implicitly disable include sorting
>> SortIncludes: false
>> 
>> Formatting automatically applied for all .c, .h, and .cpp sources in the tree
>> 
>> I’ll run the full suite again following reformatting using autopep8 
>> <https://pypi.python.org/pypi/autopep8> for all .py files.
>> 
>> Thanks to everyone who has chimed in with suggestions, and with 
>> contributions to ensure that include ordering doesn’t become an issue on 
>> other platforms.
>> 
>> Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
>>  Xcode Low Level Tools
>> 
>>> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> 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 th

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

[Kate Stone via lldb-dev]

This has been in the works long enough to get plans together.  If the current 
state of a bot suggests that manual validation is required then that’s what I’d 
recommend.  That’s the unfortunate current state of affairs with the Green 
Dragon bots, for example.

Kate Stone k8st...@apple.com <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 any of the bots we’re using to validate the health of
>> the source tree.
> 
> Given the current non-functional state of the bots, what is the plan
> for proceeding with the formatting change? For FreeBSD the bot was
> building lldb but not running the tests and I was planning to manually
> validate the tests.
> 
> For reference at r280675 on my FreeBSD desktop there are a few tests
> that report errors (the libstdcpp ones, as FreeBSD 10 and later use
> libc++), two that abort with an assertion ("Breakpoint update
> failed!"), and three that sometimes time out (test_asm_int_3,
> test_iter_registers_dwarf, test_with_dsym_and_python_api_dwarf).

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB REFORMATTING IN PROGRESS

[Kate Stone via lldb-dev]

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...@apple.com 
 Xcode Low Level Tools

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

[Kate Stone via lldb-dev]

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 and land them 
individually.

From the commit message:

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname 
"*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} 
+ ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

Thanks for your collective support and assistance in preparing for this change.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Sep 6, 2016, at 10:24 AM, Kate Stone  wrote:
> 
> 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...@apple.com 
>  Xcode Low Level Tools
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Kate Stone via lldb-dev]

> 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 underlying debugger is used in both cases.  There can be subtle 
reasons for differences in behavior in the different contexts, but I don’t see 
how they’d apply here.  Let’s get to a specific scenario and ensure that we can 
resolve that for you.

> On a separate note, --top-level doesn't seem to work for swift (from Xcode 
> console lldb). We need it to work with swift for the scripts we'll be writing.
> (lldb) expr -l swift --top-level -- let i = 10
> 
> expr -l swift --top-level -- let a = i
> 
> error: :3:9: error: use of unresolved identifier 'i'
> 
The --top-level option isn’t meaningful for Swift, so it’s completely ignored.  
The less ambiguous nature of the language allows us to automatically determine 
what are top-level constructs and what’s intended to be evaluated in scope.  We 
introduced --top-level for Objective-C / C++ primarily to enable declaring 
functions and anything else that literally cannot be written in a local scope.

In your particular example the reason you can’t refer to “i” is completely 
unrelated.  Conceptually, every expression you evaluate is wrapped in its own 
scope.  So your two subsequent expressions act like this construct :

do {
let i = 10
}
do {
let a = i
}

As you can see, “i” is defined in this expression scope and then goes out of 
scope immediately after execution.  This is useful when you want to write a 
multi-line expression that introduces declarations for immediate use without 
having them cluttering up your namespace afterwards.  The convention used by 
LLDB for any declaration that you intend to use in later expressions is to 
prefix the name with a dollar sign.  So you can do the following:

(lldb) expr -l swift -- let $i = 10
(lldb) expr -l swift -- let $a = i

… and both “$a” and “$i" will be available in subsequent expressions.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley  > wrote:
> Jim,
> 
> That doesn't seem to work for us. We're using lldb packaged with Xcode 8 fyi.
> (lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
> "This is a string"];
> 
> 
> 
> ; Function Attrs: nounwind
> 
> define internal void @_GLOBAL__sub_I__null_() #0 section 
> "__TEXT,__StaticInit,regular,pure_instructions" {
> 
>   call void @__cxx_global_var_init()
> 
>   ret void
> 
> }
> 
> 
> On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham  > wrote:
> This isn't an issue with ObjC support in general, but rather shows that ObjC 
> string constants are odd beasts.  You can work around this pretty easily by 
> making dynamic strings:
> 
> (lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
> "This is a string"];
> (lldb) expr string
> (__NSCFString *) $0 = 0x0001002001b0 @"This is a string"
> 
> Please file a bug about the problem with ObjC constant strings.
> 
> Jim
> 
> 
> > On Oct 4, 2016, at 3:57 PM, Rex Fenley via lldb-dev 
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Hey lldb team!
> >
> > I'm trying to use `expr --top-level` from lldb in Xcode but it throws 
> > errors like the following:
> >
> > (lldb) expression --top-level -- NSString *str = @"This is a string";
> > Error [IRForTarget]: Couldn't replace an Objective-C constant string with a 
> > dynamic string
> > error: cannot import unsupported AST node ObjCStringLiteral
> > error: The expression could not be prepared to run in the target
> >
> > It seems like top-level only supports raw C code and not Objective-C. Is 
> > there an option we can set to support this? Is there somewhere in lldb's 
> > source code that could help point us to fixing this?
> >
> > Thank you, you guys rule!
> >
> > --
> > Rex Fenley  |  IOS DEVELOPER
> >
> >
> > Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> > 
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.o

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

[Kate Stone via lldb-dev]

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 Fenley via lldb-dev  
> wrote:
> 
> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having trouble.
> 
> This doesn't seem to work to list the hosts.
> rpcinfo -p lldb-rpc-server
> 
> Can't contact rpcbind on lldb-rpc-server
> 
> 
> rpcinfo: RPC: Unknown host
> 
> Am I doing this correctly?
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev