Re: [Lldb-commits] [PATCH] D71372: [lldb] Add additional validation on return address in 'thread step-out'

Okay, I pushed a change to the test to only run on darwin. When you have a patch for the other systems, we can take that out again. Jim > On Dec 20, 2019, at 2:08 PM, Mark Mossberg via Phabricator > wrote: > > mossberg added a comment. > > Took a quick look, and I think the good news is th

Re: [Lldb-commits] [PATCH] D72391: [lldb] Add a display name to ClangASTContext instances

I think we should keep the pointer. You can easily cast the pointer & call functions on it in the expression parser. So if you have the log streaming as you are debugging and you see a log message that seems interesting, you can interrupt lldb and access the relevant context without having to

[Lldb-commits] [lldb] cd9e5c3 - Fix the macos build after D71575.

Author: Jim Ingham Date: 2020-01-15T18:13:44-08:00 New Revision: cd9e5c32302cd3b34b796683eedb072c6a1cfdc1 URL: https://github.com/llvm/llvm-project/commit/cd9e5c32302cd3b34b796683eedb072c6a1cfdc1 DIFF: https://github.com/llvm/llvm-project/commit/cd9e5c32302cd3b34b796683eedb072c6a1cfdc1.diff LO

Re: [Lldb-commits] LLDB Intel hardware breakpoints patch

Somebody will have to champion this patch for it to get into lldb. It has no test case, so it’s not acceptable as is. It should also be cleaned up so that it shares more code with the watchpoint implementation in the same file (for instance duplicating all the comments and logic to set a hardw

Re: [Lldb-commits] [PATCH] D72953: Fix the handling of unnamed bit-fields when parsing DWARF

> On Jan 17, 2020, at 2:24 PM, Raphael Isemann via Phabricator > wrote: > > teemperor added a comment. > > (Just some quick comments, will review this properly during normal working > hours) > > Without this fix debugging Clang with LLDB is essentially impossible, so I'm > in favour of lan

[Lldb-commits] [lldb] 89c8866 - Convert AssertTrue( A == B) to AssertEqual(A, B) in TestObjCStepping.py.

Author: Jim Ingham Date: 2020-01-22T13:20:15-08:00 New Revision: 89c8866c0417a415ab546aa870569308f15b0ec8 URL: https://github.com/llvm/llvm-project/commit/89c8866c0417a415ab546aa870569308f15b0ec8 DIFF: https://github.com/llvm/llvm-project/commit/89c8866c0417a415ab546aa870569308f15b0ec8.diff LO

[Lldb-commits] [lldb] 29c7e6c - Clang added a new feature to the ObjC compiler that will translate method

Author: Jim Ingham Date: 2020-01-23T12:41:14-08:00 New Revision: 29c7e6c8c97f6b1186f012d614e9a1100e8c06cb URL: https://github.com/llvm/llvm-project/commit/29c7e6c8c97f6b1186f012d614e9a1100e8c06cb DIFF: https://github.com/llvm/llvm-project/commit/29c7e6c8c97f6b1186f012d614e9a1100e8c06cb.diff LO

Re: [Lldb-commits] [lldb] r355466 - Replace debug-only assert with a plain old assert.

That shouldn't be ASAN specific, that should happen on and LLDB_CONFIGURATION_DEBUG build. If it only happens on ASAN builds, something else must be going wrong. BTW, those asserts only make sense if you can't re-enter the command interpreter while a command is active. In the case of a comman

Re: [Lldb-commits] [lldb] c25938d - Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols

Seems like your change is more informative. Could we just fix the tests? Jim > On Feb 4, 2020, at 11:18 AM, Adrian McCarthy via lldb-commits > wrote: > > I see why the behavior is different, but I'm not sure whether the new > behavior is wrong. > > The old code nested a bunch of if-success

Re: [Lldb-commits] [lldb] c25938d - Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols

The question isn't so much whether it makes a difference to the user than whether when somebody reports getting this error in a project that we can't get our hands on so all we have is the screen output (a very not uncommon circumstance for debuggers) the different error messages would be useful

<    8   9   10   11   12   13