[Lldb-commits] [lldb] 8aa07f8 - Remove the old SecTaskAccess entry from debugserver's plist

2020-03-16 Thread Jason Molenda via lldb-commits
Author: Jason Molenda Date: 2020-03-16T21:54:32-07:00 New Revision: 8aa07f81b85b7af4b0678a813dd4f5a98293b955 URL: https://github.com/llvm/llvm-project/commit/8aa07f81b85b7af4b0678a813dd4f5a98293b955 DIFF: https://github.com/llvm/llvm-project/commit/8aa07f81b85b7af4b0678a813dd4f5a98293b955.diff

[Lldb-commits] [PATCH] D75715: Switch TypeSystemClang over to CreateDeserialized() (NFC)

2020-03-16 Thread Adrian Prantl via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rG90a2fbdb044b: Switch to TypeSystemClang over to CreateDeserialized() (NFC) (authored by aprantl). Herald added projects: clang, LLDB. Herald added a subscriber: cfe-commits. Changed prior to commit:

[Lldb-commits] [PATCH] D76261: [lldb/PlatformMacOSX] Be more robust in computing the SDK path with xcrun

2020-03-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere planned changes to this revision. JDevlieghere added a comment. We should be able to avoid most of the post processing by just asking xcrun directly for the right SKD. I'm going to try to implement that and hopefully that removes some of the complexity here. CHANGES SINCE LAST

[Lldb-commits] [lldb] 90a2fbd - Switch to TypeSystemClang over to CreateDeserialized() (NFC)

2020-03-16 Thread Adrian Prantl via lldb-commits
Author: Adrian Prantl Date: 2020-03-16T18:11:36-07:00 New Revision: 90a2fbdb044bcf285646e79f3b096ccb196f6d02 URL: https://github.com/llvm/llvm-project/commit/90a2fbdb044bcf285646e79f3b096ccb196f6d02 DIFF: https://github.com/llvm/llvm-project/commit/90a2fbdb044bcf285646e79f3b096ccb196f6d02.diff

[Lldb-commits] [PATCH] D76261: [lldb/PlatformMacOSX] Be more robust in computing the SDK path with xcrun

2020-03-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 250659. JDevlieghere marked 5 inline comments as done. JDevlieghere added a comment. Use the same timeout as `UtilityExpressionTimeout`. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76261/new/ https://reviews.llvm.org/D76261 Files:

[Lldb-commits] [PATCH] D76261: [lldb/PlatformMacOSX] Be more robust in computing the SDK path with xcrun

2020-03-16 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments. Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp:225 + lldb_private::Status error = Host::RunShellCommand( + "xcrun -sdk macosx --show-sdk-path", FileSpec(), , , + _str, std::chrono::seconds(3)); Ah. We

[Lldb-commits] [PATCH] D76261: [lldb/PlatformMacOSX] Be more robust in computing the SDK path with xcrun

2020-03-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision. JDevlieghere added a reviewer: aprantl. Herald added a subscriber: mgorny. The current implementation isn't very resilient when it comes to the output of `xcrun`. Currently it cannot deal with: - Trailing newlines. - Leading newlines and errors/warnings

[Lldb-commits] [PATCH] D76111: Create basic SBEnvironment class

2020-03-16 Thread walter erquinigo via Phabricator via lldb-commits
wallace updated this revision to Diff 250649. wallace added a comment. address comments≈ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76111/new/ https://reviews.llvm.org/D76111 Files: lldb/bindings/headers.swig

[Lldb-commits] [PATCH] D76111: Create basic SBEnvironment class

2020-03-16 Thread walter erquinigo via Phabricator via lldb-commits
wallace updated this revision to Diff 250651. wallace added a comment. format Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76111/new/ https://reviews.llvm.org/D76111 Files: lldb/bindings/headers.swig lldb/bindings/interface/SBEnvironment.i

[Lldb-commits] [PATCH] D76111: Create basic SBEnvironment class

2020-03-16 Thread walter erquinigo via Phabricator via lldb-commits
wallace updated this revision to Diff 250650. wallace added a comment. . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76111/new/ https://reviews.llvm.org/D76111 Files: lldb/bindings/headers.swig lldb/bindings/interface/SBEnvironment.i

[Lldb-commits] [PATCH] D75761: [lldb] Remove template parameters from FunctionTemplateDecl names

2020-03-16 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik updated this revision to Diff 250644. shafik marked 2 inline comments as done. shafik added a comment. Addressing minor comments CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75761/new/ https://reviews.llvm.org/D75761 Files:

[Lldb-commits] [PATCH] D76168: CPlusPlusNameParser does not handles templated operator< properly

2020-03-16 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added a comment. In D76168#1924539 , @hubert.reinterpretcast wrote: > I am not sure what the usage scenario is that this is meant to support. Is it > user input that tries to name a specialization of a template `operator<` > without separation

[Lldb-commits] [PATCH] D75929: [DebugInfo] Support DWARFv5 index sections.

2020-03-16 Thread Igor Kudrin via Phabricator via lldb-commits
ikudrin updated this revision to Diff 250537. ikudrin marked 10 inline comments as done. ikudrin added a comment. @jhenderson, thank you for the comments! - Made comments for `DWARFSectionKind`, `serializeSectionKind()` and `deserializeSectionKind()` in doxygen style. - Renamed function. -

[Lldb-commits] [PATCH] D75929: [DebugInfo] Support DWARFv5 index sections.

2020-03-16 Thread Igor Kudrin via Phabricator via lldb-commits
ikudrin added inline comments. Comment at: llvm/include/llvm/DebugInfo/DWARF/DWARFUnitIndex.h:116 + // This is a parallel array of raw section IDs for columns of unknown kinds. + // This array is created only if there are items in columns ColumnKinds with + //

[Lldb-commits] [PATCH] D74023: [RISCV] ELF attribute section for RISC-V

2020-03-16 Thread James Henderson via Phabricator via lldb-commits
jhenderson added inline comments. Comment at: llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp:1727 + + if (Tag % 2) +IsIntegerValue = false; I don't understand why this line changed, but more importantly, the `2` looks like a magic number and it is

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment. In D76188#1924840 , @mib wrote: > @labath Do you object if I land this patch to revert our CIs to green and > work on matching the symbol by address instead of name on a separate one ? Can we temporarily skip the test?

[Lldb-commits] [PATCH] D76163: [lldb/Reproducers] Decode run-length encoding in GDB replay server.

2020-03-16 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added inline comments. Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:1374 + // Number of time the previous character is repeated. + int repeat_count = *++c + 3 - ' '; + // We have the char_to_repeat and repeat_count. Now

[Lldb-commits] [PATCH] D76216: Improve step over performance

2020-03-16 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. This looks fine to me. The thread plans are self-healing, in the sense that they always check after every stop whether they are still relevant, (IsStale) and unship themselves if they aren't. For instance, if a step-over plan finds that the stack has unwound past

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. In D76188#1924083 , @labath wrote: > Being able to match multiple symbols sounds useful in its own right, but the > motivating case is a bit shady. `raise`, `__GI_raise` and `gsignal` are all > aliases to one another (they have

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib added a comment. @labath Do you object if I land this patch to revert our CIs to green and work on matching the symbol by address instead of name on a separate one ? Also do you know what's the "default" symbol I should look for with the assert frame recognizer ? Repository: rG LLVM

[Lldb-commits] [PATCH] D76011: Add a verification mechanism to CompilerType.

2020-03-16 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment. Thanks for sharing your thoughts! Moving to a type-safe subclass does make sense, I don't think that calling the verifier there is the best choice. For example, if I'm calling `CompilerType::GetPointerType(CompilerType pointee)` I'd want the resulting type verified,

[Lldb-commits] [PATCH] D76163: [lldb/Reproducers] Decode run-length encoding in GDB replay server.

2020-03-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rG88fbd8f9e790: [lldb/Reproducers] Decode run-length encoding in GDB replay server. (authored by JDevlieghere). Herald added a project: LLDB. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 250577. mib added a comment. Addressed Pavel's comment. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76188/new/ https://reviews.llvm.org/D76188 Files: lldb/include/lldb/Target/StackFrameRecognizer.h

[Lldb-commits] [lldb] 88fbd8f - [lldb/Reproducers] Decode run-length encoding in GDB replay server.

2020-03-16 Thread Jonas Devlieghere via lldb-commits
Author: Jonas Devlieghere Date: 2020-03-16T08:47:39-07:00 New Revision: 88fbd8f9e79096da4d013f826fc8b4f0eea1ef66 URL: https://github.com/llvm/llvm-project/commit/88fbd8f9e79096da4d013f826fc8b4f0eea1ef66 DIFF:

[Lldb-commits] [lldb] e2d8aa6 - [lldb] Re-add nullptr check to IRForTarget::RewriteObjCConstString log statement

2020-03-16 Thread Raphael Isemann via lldb-commits
Author: Raphael Isemann Date: 2020-03-16T16:28:36+01:00 New Revision: e2d8aa6bf774ef29e134c40f886c7bb5f970 URL: https://github.com/llvm/llvm-project/commit/e2d8aa6bf774ef29e134c40f886c7bb5f970 DIFF:

[Lldb-commits] [PATCH] D76168: CPlusPlusNameParser does not handles templated operator< properly

2020-03-16 Thread Hubert Tong via Phabricator via lldb-commits
hubert.reinterpretcast added a comment. I am not sure what the usage scenario is that this is meant to support. Is it user input that tries to name a specialization of a template `operator<` without separation to prevent tokenization as `operator<<`? I think that case should qualify as user

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 250557. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76188/new/ https://reviews.llvm.org/D76188 Files: lldb/include/lldb/Target/StackFrameRecognizer.h lldb/packages/Python/lldbsuite/test/lldbutil.py

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib marked 6 inline comments as done. mib added a comment. I'll investigate matching the symbol by address instead of name, but I still think having the ability to register a recognizer with multiple symbols can be useful. In D76188#1924083 , @labath

[Lldb-commits] [PATCH] D75979: [lldb] Remove unimplemented StackFrame::BehavesLikeZerothFrame

2020-03-16 Thread Tatyana Krasnukha via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rG332edcc6bd1d: [lldb] Remove unimplemented StackFrame::BehavesLikeZerothFrame (authored by tatyana-krasnukha). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[Lldb-commits] [PATCH] D75975: [lldb] Copy m_behaves_like_zeroth_frame on stack frame update

2020-03-16 Thread Tatyana Krasnukha via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rG0a840ef80059: [lldb] Copy m_behaves_like_zeroth_frame on stack frame update (authored by tatyana-krasnukha). Changed prior to commit: https://reviews.llvm.org/D75975?vs=249561=250549#toc Repository:

[Lldb-commits] [lldb] 0a840ef - [lldb] Copy m_behaves_like_zeroth_frame on stack frame update

2020-03-16 Thread Tatyana Krasnukha via lldb-commits
Author: Tatyana Krasnukha Date: 2020-03-16T16:20:11+03:00 New Revision: 0a840ef80059c761109f5988590a3616c00906a1 URL: https://github.com/llvm/llvm-project/commit/0a840ef80059c761109f5988590a3616c00906a1 DIFF:

[Lldb-commits] [lldb] 332edcc - [lldb] Remove unimplemented StackFrame::BehavesLikeZerothFrame

2020-03-16 Thread Tatyana Krasnukha via lldb-commits
Author: Tatyana Krasnukha Date: 2020-03-16T16:20:12+03:00 New Revision: 332edcc6bd1dc1fd8fc33a0fb2f215a996d967fa URL: https://github.com/llvm/llvm-project/commit/332edcc6bd1dc1fd8fc33a0fb2f215a996d967fa DIFF:

[Lldb-commits] [lldb] c5ff3df - [lldb] Hardcode target in dwo-type-in-main-file.s test

2020-03-16 Thread Pavel Labath via lldb-commits
Author: Pavel Labath Date: 2020-03-16T13:25:10+01:00 New Revision: c5ff3df839321847ab7558ffb292f725d0356dfe URL: https://github.com/llvm/llvm-project/commit/c5ff3df839321847ab7558ffb292f725d0356dfe DIFF: https://github.com/llvm/llvm-project/commit/c5ff3df839321847ab7558ffb292f725d0356dfe.diff

[Lldb-commits] [lldb] 5abfa32 - [lldb/DWARF] Fix crash when a dwo compile unit refers to a non-dwo type

2020-03-16 Thread Pavel Labath via lldb-commits
Author: Pavel Labath Date: 2020-03-16T12:12:59+01:00 New Revision: 5abfa3226da67cf00cefe6365ec62049a7592e61 URL: https://github.com/llvm/llvm-project/commit/5abfa3226da67cf00cefe6365ec62049a7592e61 DIFF: https://github.com/llvm/llvm-project/commit/5abfa3226da67cf00cefe6365ec62049a7592e61.diff

[Lldb-commits] [PATCH] D76216: Improve step over performance

2020-03-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a reviewer: jingham. labath added a comment. This seems reasonable, but let's wait for Greg and Jim's oppinions. Comment at: lldb/source/Target/ThreadPlanStepOverRange.cpp:176 +// rely on that breakpoint to trigger once we return to the range. +if

[Lldb-commits] [PATCH] D76167: [lldb/Utils] Use PYTHON_EXECUTABLE to configurelldb-dotest's shebang

2020-03-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. I've been working around this by manually specifying the interpreter for a while now I didn't occur to me that the fix is that simple. :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76167/new/

[Lldb-commits] [PATCH] D76188: [lldb/Target] Support more than 2 symbols in StackFrameRecognizer

2020-03-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. Being able to match multiple symbols sounds useful in its own right, but the motivating case is a bit shady. `raise`, `__GI_raise` and `gsignal` are all aliases to one another (they have the same address). The reason you're sometimes getting `gsignal` here is not

[Lldb-commits] [PATCH] D76168: CPlusPlusNameParser does not handles templated operator< properly

2020-03-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment. The approach seems reasonable to me. Comment at: lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp:153-155 + // We expect these cases to fail until we turn on C++2a + // {"A::operator<=>", "A", "operator<=>"}, + //

[Lldb-commits] [PATCH] D75761: [lldb] Fix to get the AST we generate for function templates to be closer to what clang generates and expects

2020-03-16 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor accepted this revision. teemperor added a comment. LGTM Comment at: lldb/test/API/lang/cpp/template-function/TestTemplateFunctions.py:37 + self.expect_expr("var(1)", result_type="int", result_value="10") + self.expect_expr("var(1,2)",

[Lldb-commits] [PATCH] D75761: [lldb] Fix to get the AST we generate for function templates to be closer to what clang generates and expects

2020-03-16 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment. (Also my nit pick about the revision title is still stands) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75761/new/ https://reviews.llvm.org/D75761 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D76216: Improve step over performance

2020-03-16 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin marked an inline comment as done. jarin added inline comments. Comment at: lldb/source/Target/ThreadPlanStepOverRange.cpp:176 +// rely on that breakpoint to trigger once we return to the range. +if (m_next_branch_bp_sp) + return false;

[Lldb-commits] [PATCH] D73534: [DebugInfo] Enable the debug entry values feature by default

2020-03-16 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment. FYI: See also https://reviews.llvm.org/D76164 CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73534/new/ https://reviews.llvm.org/D73534 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D73534: [DebugInfo] Enable the debug entry values feature by default

2020-03-16 Thread Djordje Todorovic via Phabricator via lldb-commits
djtodoro added a comment. Why reverting this one? Is it a different assertion? The D75036 was the problem with the previous issue reported. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73534/new/ https://reviews.llvm.org/D73534

[Lldb-commits] [PATCH] D76216: Improve step over performance

2020-03-16 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin created this revision. jarin added reviewers: clayborg, labath. jarin added a project: LLDB. Herald added a subscriber: lldb-commits. This patch improves step over performance for the case when we are stepping over a call with a next-branch-breakpoint (see