[Lldb-commits] [PATCH] D67390: [LLDB][ELF] Load both, .symtab and .dynsym sections

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

kwk added a comment.

@clayborg are you on IRC?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67390/new/

https://reviews.llvm.org/D67390



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

[Lldb-commits] [lldb] r372203 - [lldb] Print better diagnostics for user expressions and modules

[Raphael Isemann via lldb-commits]

Author: teemperor
Date: Wed Sep 18 01:53:35 2019
New Revision: 372203

URL: http://llvm.org/viewvc/llvm-project?rev=372203&view=rev
Log:
[lldb] Print better diagnostics for user expressions and modules

Summary:
Currently our expression evaluators only prints very basic errors that are not 
very useful when writing complex expressions.

For example, in the expression below the user made a type error, but it's not 
clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```

This patch enables full Clang diagnostics in our expression evaluator. After 
this patch the diagnostics for the expression look like this:

```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: :1:54: invalid operands to binary expression ('int' 
and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
   ~~^~~~
```

To make this possible, we now emulate a user expression file within our 
diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.

Note that the diagnostics that refer to declarations from the debug information 
(e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated 
with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as 
they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should 
be enough to explain the issue).

Fixes rdar://24306342

Reviewers: JDevlieghere, aprantl, shafik, #lldb

Reviewed By: JDevlieghere, #lldb

Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, 
lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65646

Added:
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/

lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile

lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py

lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/main.cpp
Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods.py
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h

lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.h
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h

Added: 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile?rev=372203&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile
 Wed Sep 18 01:53:35 2019
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py?rev=372203&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
 Wed Sep 18 01:53:35 2019
@@ -0,0 +1,113 @@
+"""
+Test the diagnostics emitted by our embeded Clang instance that parses 
expressions.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class ExprDiagnosticsTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+self.main_source = "main.cpp"
+self.main_source_spec = lldb.SBFileSpec(self.main_source)
+
+def test_source_and_caret_printing(self):
+"""Test that the source and caret positions LLDB prints are correct"""
+self.build()
+
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+  

[Lldb-commits] [PATCH] D65646: [lldb] Print better diagnostics for user expressions and modules

[Raphael Isemann via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372203: [lldb] Print better diagnostics for user expressions 
and modules (authored by teemperor, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65646?vs=220439&id=220623#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65646/new/

https://reviews.llvm.org/D65646

Files:
  cfe/trunk/include/clang/Basic/DiagnosticOptions.def
  cfe/trunk/lib/Frontend/TextDiagnostic.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
  
lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods.py
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionSourceCode.h
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h

Index: cfe/trunk/lib/Frontend/TextDiagnostic.cpp
===
--- cfe/trunk/lib/Frontend/TextDiagnostic.cpp
+++ cfe/trunk/lib/Frontend/TextDiagnostic.cpp
@@ -683,8 +683,9 @@
   if (DiagOpts->ShowColors)
 OS.resetColor();
 
-  printDiagnosticLevel(OS, Level, DiagOpts->ShowColors,
-   DiagOpts->CLFallbackMode);
+  if (DiagOpts->ShowLevel)
+printDiagnosticLevel(OS, Level, DiagOpts->ShowColors,
+ DiagOpts->CLFallbackMode);
   printDiagnosticMessage(OS,
  /*IsSupplemental*/ Level == DiagnosticsEngine::Note,
  Message, OS.tell() - StartOfLocationInfo,
Index: cfe/trunk/include/clang/Basic/DiagnosticOptions.def
===
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.def
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.def
@@ -49,6 +49,7 @@
 DIAGOPT(PedanticErrors, 1, 0)   /// -pedantic-errors
 DIAGOPT(ShowColumn, 1, 1)   /// Show column number on diagnostics.
 DIAGOPT(ShowLocation, 1, 1) /// Show source location information.
+DIAGOPT(ShowLevel, 1, 1)/// Show diagnostic level.
 DIAGOPT(AbsolutePath, 1, 0) /// Use absolute paths.
 DIAGOPT(ShowCarets, 1, 1)   /// Show carets in diagnostics.
 DIAGOPT(ShowFixits, 1, 1)   /// Show fixit information.
Index: lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
+++ lldb/trunk/packages/Python/lldbsuite/test/commands/expression/diagnostics/TestExprDiagnostics.py
@@ -0,0 +1,113 @@
+"""
+Test the diagnostics emitted by our embeded Clang instance that parses expressions.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class ExprDiagnosticsTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+
+self.main_source = "main.cpp"
+self.main_source_spec = lldb.SBFileSpec(self.main_source)
+
+def test_source_and_caret_printing(self):
+"""Test that the source and caret positions LLDB prints are correct"""
+self.build()
+
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(self,
+  '// Break here', self.main_source_spec)
+frame = thread.GetFrameAtIndex(0)
+
+# Test that source/caret are at the right position.
+value = frame.EvaluateExpression("unknown_identifier")
+self.assertFalse(value.GetError().Success())
+# We should get a nice diagnostic with a caret pointing at the start of
+# the identifier.
+self.assertIn("\nunknown_identifier\n^\n", value.GetError().GetCString())
+self.assertIn(":1:1", value.GetError().GetCString())
+
+# Same as above but with the identifier in the middle.
+value = frame.EvaluateExpression("1 + unknown_identifier  ")
+self.assertFalse(value.GetError().Success())
+self.assertIn("\n1 + unknown_identifier", value.GetError().GetCString())
+self.assertIn("\n^\n", value.GetError().GetCString())

[Lldb-commits] [lldb] r372210 - [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Wed Sep 18 03:20:28 2019
New Revision: 372210

URL: http://llvm.org/viewvc/llvm-project?rev=372210&view=rev
Log:
[lldb][CMake] Infer `Clang_DIR` if not passed explicitly

Summary:
If we only get `LLVM_DIR` and find Clang in the same provided build-tree, 
automatically infer `Clang_DIR` like this:

```
LLVM_DIR = /path/to/build-llvm/lib/cmake/llvm
Clang_DIR = /paht/to/build-llvm/lib/cmake/clang
```

Reviewers: JDevlieghere, jingham, xiaobai, compnerd, labath

Reviewed By: JDevlieghere, labath

Subscribers: mgorny, lldb-commits, #lldb

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D65798

Modified:
lldb/trunk/cmake/modules/LLDBStandalone.cmake
lldb/trunk/docs/resources/build.rst

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=372210&r1=372209&r2=372210&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Wed Sep 18 03:20:28 2019
@@ -1,7 +1,7 @@
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang 
NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")

Modified: lldb/trunk/docs/resources/build.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/resources/build.rst?rev=372210&r1=372209&r2=372210&view=diff
==
--- lldb/trunk/docs/resources/build.rst (original)
+++ lldb/trunk/docs/resources/build.rst Wed Sep 18 03:20:28 2019
@@ -120,10 +120,11 @@ Standalone builds
 *
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
@@ -139,15 +140,15 @@ Clang. Then we build the ``ALL`` target
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ninja \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   [] /path/to/llvm-project/lldb
   > ninja lldb
 
@@ -320,7 +321,6 @@ Build LLDB standalone for development wi
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb


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

[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372210: [lldb][CMake] Infer `Clang_DIR` if not passed 
explicitly (authored by stefan.graenitz, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65798?vs=214139&id=220643#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65798/new/

https://reviews.llvm.org/D65798

Files:
  lldb/trunk/cmake/modules/LLDBStandalone.cmake
  lldb/trunk/docs/resources/build.rst


Index: lldb/trunk/docs/resources/build.rst
===
--- lldb/trunk/docs/resources/build.rst
+++ lldb/trunk/docs/resources/build.rst
@@ -120,10 +120,11 @@
 *
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
@@ -139,15 +140,15 @@
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ninja \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   [] /path/to/llvm-project/lldb
   > ninja lldb
 
@@ -320,7 +321,6 @@
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb
Index: lldb/trunk/cmake/modules/LLDBStandalone.cmake
===
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake
@@ -1,7 +1,7 @@
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
-find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
-find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
+find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
+find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang 
NO_CMAKE_FIND_ROOT_PATH)
 
 # We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building 
SVNVersion.inc
 set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")


Index: lldb/trunk/docs/resources/build.rst
===
--- lldb/trunk/docs/resources/build.rst
+++ lldb/trunk/docs/resources/build.rst
@@ -120,10 +120,11 @@
 *
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
@@ -139,15 +140,15 @@
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ni

[Lldb-commits] [lldb] r372213 - [lldb][CMake] Build LLDB.framework with -Wdocumentation in Xcode

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Wed Sep 18 03:41:13 2019
New Revision: 372213

URL: http://llvm.org/viewvc/llvm-project?rev=372213&view=rev
Log:
[lldb][CMake] Build LLDB.framework with -Wdocumentation in Xcode

Modified:
lldb/trunk/cmake/modules/LLDBFramework.cmake

Modified: lldb/trunk/cmake/modules/LLDBFramework.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBFramework.cmake?rev=372213&r1=372212&r2=372213&view=diff
==
--- lldb/trunk/cmake/modules/LLDBFramework.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake Wed Sep 18 03:41:13 2019
@@ -44,6 +44,9 @@ else()
 XCODE_ATTRIBUTE_MACOSX_DEPLOYMENT_TARGET "${MACOSX_DEPLOYMENT_TARGET}")
 endif()
 
+# Add -Wdocumentation parameter
+set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_DOCUMENTATION_COMMENTS "YES")
+
 # Apart from this one, CMake creates all required symlinks in the framework 
bundle.
 add_custom_command(TARGET liblldb POST_BUILD
   COMMAND ${CMAKE_COMMAND} -E create_symlink


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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D67589#1672686 , @jankratochvil 
wrote:

> In D67589#1670966 , @labath wrote:
>
> > I agree that this approach isn't nice, but probably there isn't a nice 
> > approach to this at this point. One possibility you could consider is 
> > storing a shared_ptr inside SBCommandRO and encoding the 
> > ownership into the deleter of the shared_ptr (regular deleter => owned, 
> > noop deleter => unowned).
>
>
> Maybe also possibly cheaper `llvm::PointerIntPair` representing an associated 
> `bool` for the deletion.


We couldn't use PointerIntPair due to the our abi stability promise 
(http://lldb.llvm.org/resources/sbapi.html). One could try to implement 
something like that by hand, but I don't think it's worth the trouble.




Comment at: 
lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp:18
+result = subcommand(dbg, "help");
+result = result;
+if (!result.Succeeded())

jankratochvil wrote:
> jankratochvil wrote:
> > labath wrote:
> > > Is that intentional? If so, why?
> > It has no purpose there for this bugfix but when already writing a testcase 
> > I wanted to test this generally fragile functionality.
> > 
> If you mean the line:
> ```
> + if (!result.Succeeded())
> ```
> That is not really needed for this testcase but I think this is how a real 
> world implementation should behave so why not here, just 2 lines of code.
> 
Nope, I meant the "result = result" line. Testing self-assignment is fine, but 
you may want to call that out explicitly, as otherwise someone may just come 
along and delete the "obviously useless" code.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67589/new/

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil marked 6 inline comments as done.
jankratochvil added a comment.

In D67589#1673756 , @labath wrote:

> We couldn't use PointerIntPair due to the our abi stability promise 
> (http://lldb.llvm.org/resources/sbapi.html).


Thanks for this document! I did not know it. But isn't the document trying to 
keep ABI compatibility despite it is not explicitly stated there? Or otherwise 
why are there so many restrictions.

As then even using `std::shared_ptr` I think violates the ABI compatibility 
promise there as currently `SBCommandReturnObject` contains 
`std::unique_ptr m_opaque_up`. But maybe 
this discussion goes too far from this patch.




Comment at: lldb/include/lldb/API/SBCommandReturnObject.h:22-27
+namespace lldb_private {
+// Wrap SBCommandReturnObject::ref() so that any LLDB internal function can
+// call it but still no SB API users can call it.
+CommandReturnObject &
+SBCommandReturnObject_ref(lldb::SBCommandReturnObject &sb_cmd);
+} // namespace lldb_private

clayborg wrote:
> Easier to just make SBCommandReturnObject::ref() protected and friend any 
> users or just make it public?
I tried to make everyone a friend with `SBCommandReturnObject` but I could not. 
The problem is these two
```
SWIGEXPORT bool LLDBSwigPythonCallCommand
SWIGEXPORT bool LLDBSwigPythonCallCommandObject
```
from `lldb/scripts/Python/python-wrapper.swig` have `SWIGEXPORT which is 
defined only in build directory `tools/lldb/scripts/LLDBWrapPython.cpp` so one 
cannot access it from `lldb/include/lldb/API/SBCommandReturnObject.h`:
```
error: unknown type name 'SWIGEXPORT'
```
And when I remove `SWIGEXPORT` there I get:
```
llvm-monorepo-clangassert/tools/lldb/scripts/LLDBWrapPython.cpp:78030:1: error: 
declaration of 'LLDBSwigPythonCallCommandObject' has a different language 
linkage
LLDBSwigPythonCallCommandObject
llvm-monorepo/lldb/include/lldb/API/SBCommandReturnObject.h:20:2: note: 
previous declaration is here
 LLDBSwigPythonCallCommandObject
```

But it is true making it public is safe enough, 
`lldb_private::CommandReturnObject` is opaque to SB API users anyway. I found 
it too bold to write it that way myself, thanks.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67589/new/

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil updated this revision to Diff 220649.
jankratochvil marked an inline comment as done.

Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67589/new/

https://reviews.llvm.org/D67589

Files:
  lldb/include/lldb/API/SBCommandReturnObject.h
  lldb/packages/Python/lldbsuite/test/api/command-return-object/Makefile
  
lldb/packages/Python/lldbsuite/test/api/command-return-object/TestSBCommandReturnObject.py
  lldb/packages/Python/lldbsuite/test/api/command-return-object/main.cpp
  lldb/scripts/Python/python-wrapper.swig
  lldb/source/API/SBCommandInterpreter.cpp
  lldb/source/API/SBCommandReturnObject.cpp

Index: lldb/source/API/SBCommandReturnObject.cpp
===
--- lldb/source/API/SBCommandReturnObject.cpp
+++ lldb/source/API/SBCommandReturnObject.cpp
@@ -31,21 +31,8 @@
   m_opaque_up = clone(rhs.m_opaque_up);
 }
 
-SBCommandReturnObject::SBCommandReturnObject(CommandReturnObject *ptr)
-: m_opaque_up(ptr) {
-  LLDB_RECORD_CONSTRUCTOR(SBCommandReturnObject,
-  (lldb_private::CommandReturnObject *), ptr);
-}
-
 SBCommandReturnObject::~SBCommandReturnObject() = default;
 
-CommandReturnObject *SBCommandReturnObject::Release() {
-  LLDB_RECORD_METHOD_NO_ARGS(lldb_private::CommandReturnObject *,
- SBCommandReturnObject, Release);
-
-  return LLDB_RECORD_RESULT(m_opaque_up.release());
-}
-
 const SBCommandReturnObject &SBCommandReturnObject::
 operator=(const SBCommandReturnObject &rhs) {
   LLDB_RECORD_METHOD(
@@ -338,10 +325,6 @@
   LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject, ());
   LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject,
 (const lldb::SBCommandReturnObject &));
-  LLDB_REGISTER_CONSTRUCTOR(SBCommandReturnObject,
-(lldb_private::CommandReturnObject *));
-  LLDB_REGISTER_METHOD(lldb_private::CommandReturnObject *,
-   SBCommandReturnObject, Release, ());
   LLDB_REGISTER_METHOD(
   const lldb::SBCommandReturnObject &,
   SBCommandReturnObject, operator=,(const lldb::SBCommandReturnObject &));
Index: lldb/source/API/SBCommandInterpreter.cpp
===
--- lldb/source/API/SBCommandInterpreter.cpp
+++ lldb/source/API/SBCommandInterpreter.cpp
@@ -162,12 +162,13 @@
 
 protected:
   bool DoExecute(Args &command, CommandReturnObject &result) override {
-SBCommandReturnObject sb_return(&result);
+SBCommandReturnObject sb_return;
+std::swap(result, sb_return.ref());
 SBCommandInterpreter sb_interpreter(&m_interpreter);
 SBDebugger debugger_sb(m_interpreter.GetDebugger().shared_from_this());
 bool ret = m_backend->DoExecute(
 debugger_sb, (char **)command.GetArgumentVector(), sb_return);
-sb_return.Release();
+std::swap(result, sb_return.ref());
 return ret;
   }
   std::shared_ptr m_backend;
Index: lldb/scripts/Python/python-wrapper.swig
===
--- lldb/scripts/Python/python-wrapper.swig
+++ lldb/scripts/Python/python-wrapper.swig
@@ -650,30 +650,6 @@
 return sb_ptr;
 }
 
-// Currently, SBCommandReturnObjectReleaser wraps a unique pointer to an
-// lldb_private::CommandReturnObject. This means that the destructor for the
-// SB object will deallocate its contained CommandReturnObject. Because that
-// object is used as the real return object for Python-based commands, we want
-// it to stay around. Thus, we release the unique pointer before returning from
-// LLDBSwigPythonCallCommand, and to guarantee that the release will occur no
-// matter how we exit from the function, we have a releaser object whose
-// destructor does the right thing for us
-class SBCommandReturnObjectReleaser
-{
-public:
-SBCommandReturnObjectReleaser (lldb::SBCommandReturnObject &obj) :
-m_command_return_object_ref (obj)
-{
-}
-
-~SBCommandReturnObjectReleaser ()
-{
-m_command_return_object_ref.Release();
-}
-private:
-lldb::SBCommandReturnObject &m_command_return_object_ref;
-};
-
 SWIGEXPORT bool
 LLDBSwigPythonCallCommand
 (
@@ -686,8 +662,8 @@
 )
 {
 using namespace lldb_private;
-lldb::SBCommandReturnObject cmd_retobj_sb(&cmd_retobj);
-SBCommandReturnObjectReleaser cmd_retobj_sb_releaser(cmd_retobj_sb);
+lldb::SBCommandReturnObject cmd_retobj_sb;
+std::swap(cmd_retobj, cmd_retobj_sb.ref());
 lldb::SBDebugger debugger_sb(debugger);
 lldb::SBExecutionContext exe_ctx_sb(exe_ctx_ref_sp);
 
@@ -710,6 +686,7 @@
 else
 pfunc(debugger_arg, PythonString(args), cmd_retobj_arg, dict);
 
+std::swap(cmd_retobj, cmd_retobj_sb.ref());
 return true;
 }
 
@@ -724,8 +701,8 @@
 )
 {
 using namespace lldb_private;
-lldb::SBCommandReturnObject cmd_retobj_sb(&cmd_retobj);
-SBCommandReturnObjectReleaser cmd_retobj_sb_releaser(cmd_retobj_sb);
+ll

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Yeah, that is a problem, though it's not really caused by you, and I am not 
sure even if your planned changed makes it worse (it looks like it *might* do 
that, but I'd have to dig deeper to tell for sure). If you found this issue by 
running the test suite, then I guess it does.

The problem here is that there is a lot of confusion in the code about what is 
the "offset" field in the register info struct supposed to mean. Somewhere it 
is used to specify the offset in the operating system register context struct 
(`struct user` on linux), and elsewhere for the position in the gdb register 
packet string. In an ideal world, the same number could be used for both 
things, but unfortunately ymm registers use this weird discontiguous layout, 
which is not expressible in the RegisterInfo struct. If you want to fix that, I 
think the only reasonable way to do that would be to change the RegisterInfo 
offset for BND registers to mean the gdb-remote offset, and then change any 
code which uses it for the OS context offset to do something else (the only 
place doing something like that should be RegisterContextLinux_x86_64.cpp).

(As a side note, the register infos in lldb badly need some TLC. I am preparing 
a patch which should make things slightly better, though it will not help with 
this issue in any way.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62931/new/

https://reviews.llvm.org/D62931



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

[Lldb-commits] [lldb] r372222 - Fix command-script-import.test on linux

[Pavel Labath via lldb-commits]

Author: labath
Date: Wed Sep 18 05:58:52 2019
New Revision: 37

URL: http://llvm.org/viewvc/llvm-project?rev=37&view=rev
Log:
Fix command-script-import.test on linux

The test was expecting the value of "lldb.frame" to be None, because it
is cleared after each python interpreter session. However, this is not
true in the very first session, because lldb.py sets these values to
invalid objects (lldb.SBFrame(), etc.).

I have not investigated why is it that this test passes on darwin, but
my guess is that this is because we do extra work on darwin (loading the
objc runtime, etc), which causes us to enter the python interpreter
sooner.

This patch changes lldb.py to also initialize these values to None, as
that seems to make more sense. I also fixed some typos in the test while
I was in there.

Modified:
lldb/trunk/lit/Commands/Inputs/frame.py
lldb/trunk/lit/Commands/command-script-import.test
lldb/trunk/scripts/lldb.swig

Modified: lldb/trunk/lit/Commands/Inputs/frame.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/Inputs/frame.py?rev=37&r1=372221&r2=37&view=diff
==
--- lldb/trunk/lit/Commands/Inputs/frame.py (original)
+++ lldb/trunk/lit/Commands/Inputs/frame.py Wed Sep 18 05:58:52 2019
@@ -1,2 +1,2 @@
 import lldb
-print("frame:py: {}".format(lldb.frame))
+print("frame.py: {}".format(lldb.frame))

Modified: lldb/trunk/lit/Commands/command-script-import.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Commands/command-script-import.test?rev=37&r1=372221&r2=37&view=diff
==
--- lldb/trunk/lit/Commands/command-script-import.test (original)
+++ lldb/trunk/lit/Commands/command-script-import.test Wed Sep 18 05:58:52 2019
@@ -3,10 +3,10 @@
 # RUN: echo 'command script import %S/Inputs/frame.py' >> %t.in
 
 # RUN: %clang -g -O0 %S/Inputs/main.c -o %t.out
-# RUN: %lldb -b -s %t.in -o 'script print("script: {}").format(lldb.frame)' 
%t.out | FileCheck %s
+# RUN: %lldb -b -s %t.in -o 'script print("script: {}".format(lldb.frame))' 
%t.out | FileCheck %s
 
 # Make sure that we don't have access to lldb.frame from the Python script.
-# CHECK: frame:py: No value
+# CHECK: frame.py: None
 
 # Make sure that we do have access to lldb.frame from the script command.
 # CHECK: script: frame #0

Modified: lldb/trunk/scripts/lldb.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/lldb.swig?rev=37&r1=372221&r2=37&view=diff
==
--- lldb/trunk/scripts/lldb.swig (original)
+++ lldb/trunk/scripts/lldb.swig Wed Sep 18 05:58:52 2019
@@ -265,8 +265,8 @@ def lldb_iter(obj, getsize, getelem):
 debugger_unique_id = 0
 SBDebugger.Initialize()
 debugger = None
-target = SBTarget()
-process = SBProcess()
-thread = SBThread()
-frame = SBFrame()
+target = None
+process = None
+thread = None
+frame = None
 %}


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

[Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Unfortunately, there was a bug here which caused the test to fail on linux and 
windows. r37 ought to fix that. From the patch description:

  The test was expecting the value of "lldb.frame" to be None, because it
  is cleared after each python interpreter session. However, this is not
  true in the very first session, because lldb.py sets these values to
  invalid objects (lldb.SBFrame(), etc.).
  
  I have not investigated why is it that this test passes on darwin, but
  my guess is that this is because we do extra work on darwin (loading the
  objc runtime, etc), which causes us to enter the python interpreter
  sooner.
  
  This patch changes lldb.py to also initialize these values to None, as
  that seems to make more sense.

I am pretty sure this will fix the issue on linux, but I am not sure about 
windows, because it may fail later due to the use of nested quotes, which 
mostly doesn't work there. Overall, it's usually better to avoid nested quotes 
in lit tests.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67685/new/

https://reviews.llvm.org/D67685



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

[Lldb-commits] [lldb] r372224 - Fir TestAPILog for gcc

[Pavel Labath via lldb-commits]

Author: labath
Date: Wed Sep 18 06:41:50 2019
New Revision: 372224

URL: http://llvm.org/viewvc/llvm-project?rev=372224&view=rev
Log:
Fir TestAPILog for gcc

different compilers will put different things into __PRETTY_FUNCTION__.
For instance gcc will not put a " " in the "const char *" argument,
causing our regex matching to fail.

This patch relaxes the regexes in this test to account for this
difference.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py?rev=372224&r1=372223&r2=372224&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/api/log/TestAPILog.py Wed Sep 18 
06:41:50 2019
@@ -36,18 +36,16 @@ class APILogTestCase(TestBase):
 
 # Find the SBDebugger's address.
 debugger_addr = re.findall(
-r"lldb::SBDebugger::GetScriptingLanguage\(const char \*\) 
\(0x([0-9a-fA-F]+),",
+r"lldb::SBDebugger::GetScriptingLanguage\([^)]*\) 
\(0x([0-9a-fA-F]+),",
 log)
 
 # Make sure we've found a match.
 self.assertTrue(debugger_addr, log)
 
 # Make sure the GetScriptingLanguage matches.
-get_scripting_language = 'lldb::SBDebugger::GetScriptingLanguage(const 
char *) (0x{}, "")'.format(
-debugger_addr[0])
-self.assertTrue(get_scripting_language in log, log)
+
self.assertTrue(re.search(r'lldb::SBDebugger::GetScriptingLanguage\([^)]*\) 
\(0x{}, ""\)'.format(
+debugger_addr[0]), log), log)
 
 # Make sure the address matches.
-create_target = 'lldb::SBDebugger::CreateTarget(const char *) (0x{}, 
"")'.format(
-debugger_addr[0])
-self.assertTrue(create_target in log, log)
+self.assertTrue(re.search(r'lldb::SBDebugger::CreateTarget\([^)]*\) 
\(0x{}, ""\)'.format(
+debugger_addr[0]), log), log)


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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D67589#1673771 , @jankratochvil 
wrote:

> In D67589#1673756 , @labath wrote:
>
> > We couldn't use PointerIntPair due to the our abi stability promise 
> > (http://lldb.llvm.org/resources/sbapi.html).
>
>
> Thanks for this document! I did not know it. But isn't the document trying to 
> keep ABI compatibility despite it is not explicitly stated there? Or 
> otherwise why are there so many restrictions.


We are making all efforts to vend a stable C++ API. Thus the restrictions. If 
anyone makes a binary that contains a lldb::SB object we can't change the size 
of the object. That means no inheritance (size of object could change), no 
virtual functions (vtable size would change), and no changing the ivars since 
their size defines the size of the object. Then all function calls to the LLDB 
API are just fancy long mangled name lookups just like a C API, and thus our 
API is stable. Then people can have our classes as ivars in their classes, and 
if liblldb.so gets updated they can still run without having to re-link.

> As then even using `std::shared_ptr` I think violates the ABI compatibility 
> promise there as currently `SBCommandReturnObject` contains 
> `std::unique_ptr m_opaque_up`. But maybe 
> this discussion goes too far from this patch.

We can replace the std::unique_ptr 
m_opaque_up with another unique pointer to an internal object 
(std::unique_ptr m_opaque_up;). We could 
make a struct:

  lldb_private::CommandReturnObjectImpl {
bool owned;
std::unique_ptr m_opaque_up;
  };

And then release the object without freeing it if needed in the 
CommandReturnObjectImpl destructor. This keeps the ABI stable since the size of 
lldb::SBCommandReturnObject doesn't change. The constructors aren't inlined for 
just this purpose (another API thing).


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67589/new/

https://reviews.llvm.org/D67589



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

[Lldb-commits] [PATCH] D67727: [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBER

[Michał Górny via Phabricator via lldb-commits]

mgorny created this revision.
mgorny added reviewers: labath, krytarowski.

Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER.


https://reviews.llvm.org/D67727

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp


Index: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1454,7 +1454,8 @@
   }
 
   // Build the ResumeActionList
-  ResumeActionList actions(StateType::eStateRunning, 0);
+  ResumeActionList actions(StateType::eStateRunning,
+   LLDB_INVALID_SIGNAL_NUMBER);
 
   Status error = m_debugged_process_up->Resume(actions);
   if (error.Fail()) {
@@ -1521,7 +1522,7 @@
 ResumeAction thread_action;
 thread_action.tid = LLDB_INVALID_THREAD_ID;
 thread_action.state = eStateInvalid;
-thread_action.signal = 0;
+thread_action.signal = LLDB_INVALID_SIGNAL_NUMBER;
 
 const char action = packet.GetChar();
 switch (action) {
@@ -2724,7 +2725,7 @@
 return SendErrorResponse(0x33);
 
   // Create the step action for the given thread.
-  ResumeAction action = {tid, eStateStepping, 0};
+  ResumeAction action = {tid, eStateStepping, LLDB_INVALID_SIGNAL_NUMBER};
 
   // Setup the actions list.
   ResumeActionList actions;


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1454,7 +1454,8 @@
   }
 
   // Build the ResumeActionList
-  ResumeActionList actions(StateType::eStateRunning, 0);
+  ResumeActionList actions(StateType::eStateRunning,
+   LLDB_INVALID_SIGNAL_NUMBER);
 
   Status error = m_debugged_process_up->Resume(actions);
   if (error.Fail()) {
@@ -1521,7 +1522,7 @@
 ResumeAction thread_action;
 thread_action.tid = LLDB_INVALID_THREAD_ID;
 thread_action.state = eStateInvalid;
-thread_action.signal = 0;
+thread_action.signal = LLDB_INVALID_SIGNAL_NUMBER;
 
 const char action = packet.GetChar();
 switch (action) {
@@ -2724,7 +2725,7 @@
 return SendErrorResponse(0x33);
 
   // Create the step action for the given thread.
-  ResumeAction action = {tid, eStateStepping, 0};
+  ResumeAction action = {tid, eStateStepping, LLDB_INVALID_SIGNAL_NUMBER};
 
   // Setup the actions list.
   ResumeActionList actions;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67583: Fix swig python package path

[Haibo Huang via Phabricator via lldb-commits]

hhb added a comment.

In D67583#1673356 , @ZeGentzy wrote:

> Hello folks,
>
> These changes break running `ninja install` when building with `-D 
> LLVM_LIBDIR_SUFFIX=32`.
>
>   [...]
>   -- Up-to-date: 
> /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include
>   -- Up-to-date: 
> /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb
>   -- Up-to-date: 
> /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host
>   -- Installing: 
> /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host/Config.h
>   CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):
> file INSTALL cannot find
> "/build/llvm-git-gentz/src/_build32_final/./lib/python3.7".
>   Call Stack (most recent call first):
> tools/lldb/cmake_install.cmake:50 (include)
> tools/cmake_install.cmake:50 (include)
> cmake_install.cmake:68 (include)
>  
>  
>   FAILED: CMakeFiles/install.util 
>   cd /build/llvm-git-gentz/src/_build32_final && /usr/bin/cmake -P 
> cmake_install.cmake
>   ninja: build stopped: subcommand failed.
>
>
> After some investigation, I found that there is no 
> `/build/llvm-git-gentz/src/_build32_final/./lib/python3.7` but there is an 
> `/build/llvm-git-gentz/src/_build32_final/./lib32/python3.7`.
>
> I've temporary solved this problem by applying the following patch:
>
>   diff --git a/lldb/scripts/CMakeLists.txt b/lldb/scripts/CMakeLists.txt
>   index 9de96ef5565..7d346deee7f 100644
>   --- a/lldb/scripts/CMakeLists.txt
>   +++ b/lldb/scripts/CMakeLists.txt
>   @@ -47,7 +47,7 @@ if(NOT LLDB_BUILD_FRAMEWORK)
>  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
>set(swig_python_subdir Lib/site-packages)
>  else()
>   -set(swig_python_subdir 
> lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
>   +set(swig_python_subdir 
> lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
>  endif()
>   
>  set(SWIG_PYTHON_DIR 
> ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
>
>
> I believe solving this problem correctly would also involve updating 
> https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L150 to 
> account for `${LLVM_LIBDIR_SUFFIX}`, however, I've never used the script 
> before and am unfamiliar with it's purpose.
>
> @hhb Could you please revisit this revision so that it doesn't break builds 
> with a modified `LLVM_LIBDIR_SUFFIX` and revert this revision until then?


Hmm that's interesting... In my case the issue is opposite: 
LLVM_LIBDIR_SUFFIX=64 by default but the file is in lib/ .

I don't think we can change python to fix this. But I'm curious how the suffix 
is applied. Let me try LLVM_LIBDIR_SUFFIX by myself...


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583



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

[Lldb-commits] [PATCH] D67583: Fix swig python package path

[Haibo Huang via Phabricator via lldb-commits]

hhb added a comment.

In D67583#1674430 , @hhb wrote:

> In D67583#1673356 , @ZeGentzy wrote:
>
> > Hello folks,
> >
> > These changes break running `ninja install` when building with `-D 
> > LLVM_LIBDIR_SUFFIX=32`.
> >
> >   [...]
> >   -- Up-to-date: 
> > /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include
> >   -- Up-to-date: 
> > /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb
> >   -- Up-to-date: 
> > /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host
> >   -- Installing: 
> > /build/llvm-git-gentz/pkg/lib32-llvm-git-gentz/opt/llvm32/include/lldb/Host/Config.h
> >   CMake Error at tools/lldb/scripts/cmake_install.cmake:41 (file):
> > file INSTALL cannot find
> > "/build/llvm-git-gentz/src/_build32_final/./lib/python3.7".
> >   Call Stack (most recent call first):
> > tools/lldb/cmake_install.cmake:50 (include)
> > tools/cmake_install.cmake:50 (include)
> > cmake_install.cmake:68 (include)
> >  
> >  
> >   FAILED: CMakeFiles/install.util 
> >   cd /build/llvm-git-gentz/src/_build32_final && /usr/bin/cmake -P 
> > cmake_install.cmake
> >   ninja: build stopped: subcommand failed.
> >
> >
> > After some investigation, I found that there is no 
> > `/build/llvm-git-gentz/src/_build32_final/./lib/python3.7` but there is an 
> > `/build/llvm-git-gentz/src/_build32_final/./lib32/python3.7`.
> >
> > I've temporary solved this problem by applying the following patch:
> >
> >   diff --git a/lldb/scripts/CMakeLists.txt b/lldb/scripts/CMakeLists.txt
> >   index 9de96ef5565..7d346deee7f 100644
> >   --- a/lldb/scripts/CMakeLists.txt
> >   +++ b/lldb/scripts/CMakeLists.txt
> >   @@ -47,7 +47,7 @@ if(NOT LLDB_BUILD_FRAMEWORK)
> >  if(CMAKE_HOST_SYSTEM_NAME MATCHES "Windows")
> >set(swig_python_subdir Lib/site-packages)
> >  else()
> >   -set(swig_python_subdir 
> > lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
> >   +set(swig_python_subdir 
> > lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
> >  endif()
> >   
> >  set(SWIG_PYTHON_DIR 
> > ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${swig_python_subdir})
> >
> >
> > I believe solving this problem correctly would also involve updating 
> > https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L150 
> > to account for `${LLVM_LIBDIR_SUFFIX}`, however, I've never used the script 
> > before and am unfamiliar with it's purpose.
> >
> > @hhb Could you please revisit this revision so that it doesn't break builds 
> > with a modified `LLVM_LIBDIR_SUFFIX` and revert this revision until then?
>
>
> Hmm that's interesting... In my case the issue is opposite: 
> LLVM_LIBDIR_SUFFIX=64 but the file is in lib/ .
>
> I don't think we can change python to fix this. But I'm curious how the 
> suffix is applied. Let me try LLVM_LIBDIR_SUFFIX=32...


Can you share your full compile command and environment? I tried to build on 
Ubuntu (Python 2.7.16) with the latest llvm source code:

  $ cmake /src/llvm-project/llvm -DLLVM_LIBDIR_SUFFIX=32 
"-DLLVM_ENABLE_PROJECTS=clang;lldb"  -DCMAKE_INSTALL_PREFIX=/src/llvm-install 
-DLLDB_DISABLE_LIBEDIT=ON -GNinja
  $ ninja
  ...
  $ find -name site-packages
  ./lib/python2.7/site-packages

Or with python 3.6.8:

  $ cmake /src/llvm-project/llvm -DLLVM_LIBDIR_SUFFIX=32 
"-DLLVM_ENABLE_PROJECTS=clang;lldb"  -DCMAKE_INSTALL_PREFIX=/src/llvm-install 
-DLLDB_DISABLE_LIBEDIT=ON -GNinja -DPYTHON_EXECUTABLE=/usr/bin/python3.6 
-DPYTHON_INCLUDE_DIR=/usr/include/python3.6 
-DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython3.6m.so
  $ ninja
  ...
  $ find -name site-packages
  ./lib/python3.6/site-packages
  $ ls lib32/python*
  zsh: no matches found: lib32/python*


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583



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

[Lldb-commits] [PATCH] D67589: Fix crash on SBCommandReturnObject & assignment

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In D67589#1674269 , @clayborg wrote:

> We are making all efforts to vend a stable C++ API.


IIUC you mean "stable C++ **ABI**" here. Thanks for the clarification. Maybe 
http://lldb.llvm.org/resources/sbapi.html could say that and it would be much 
more clear.

>   lldb_private::CommandReturnObjectImpl {
> bool owned;
> std::unique_ptr m_opaque_up;
>   };

Is this a request to rework this patch this way? If so isn't it safer / more 
clear to do it rather this way?

  lldb_private::CommandReturnObjectImpl {
bool owned;
lldb_private::CommandReturnObject *m_opaque_ptr;
~CommandReturnObjectImpl() { if (owned) delete m_opaque_ptr; }
  };


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67589/new/

https://reviews.llvm.org/D67589



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

Re: [Lldb-commits] [PATCH] D67685: [ScriptInterpreter] Make sure LLDB's global variables are only available in interactive mode.

[Jonas Devlieghere via lldb-commits]

Wow, I really botched that test. How did that even pass locally?
Thanks for fixing it!

On Wed, Sep 18, 2019 at 6:03 AM Pavel Labath via Phabricator
 wrote:
>
> labath added a comment.
>
> Unfortunately, there was a bug here which caused the test to fail on linux 
> and windows. r37 ought to fix that. From the patch description:
>
>   The test was expecting the value of "lldb.frame" to be None, because it
>   is cleared after each python interpreter session. However, this is not
>   true in the very first session, because lldb.py sets these values to
>   invalid objects (lldb.SBFrame(), etc.).
>
>   I have not investigated why is it that this test passes on darwin, but
>   my guess is that this is because we do extra work on darwin (loading the
>   objc runtime, etc), which causes us to enter the python interpreter
>   sooner.
>
>   This patch changes lldb.py to also initialize these values to None, as
>   that seems to make more sense.
>
> I am pretty sure this will fix the issue on linux, but I am not sure about 
> windows, because it may fail later due to the use of nested quotes, which 
> mostly doesn't work there. Overall, it's usually better to avoid nested 
> quotes in lit tests.
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D67685/new/
>
> https://reviews.llvm.org/D67685
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67583: Fix swig python package path

[Hal Gentz via Phabricator via lldb-commits]

ZeGentzy added a comment.

That's odd

> Can you share your full compile command and environment?

I'm using this PKGBUILD: 
https://github.com/ZeGentzy/aur-buildscripts/blob/master/llvm-git-gentz/PKGBUILD#L376

The commands being run are these:

  export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
  export CFLAGS="$CFLAGS -m32"
  export CXXFLAGS="$CXXFLAGS -m32"
  export LDFLAGS="$LDFLAGS -m32"
  
  cmake /build/llvm-git-gentz/src/llvm-project32/llvm -G Ninja \
  -D CMAKE_BUILD_TYPE="Release" \
  -D LLVM_DEFAULT_TARGET_TRIPLE="i686-pc-linux-gnu" \
  -D LLVM_LIBDIR_SUFFIX=32 \
  -D LLVM_TARGET_ARCH:STRING=i686 \
  -D LLVM_CONFIG="/usr/bin/llvm-config32" \
  -D COMPILER_RT_BUILD_LIBFUZZER=OFF \
  -D LLVM_ENABLE_BINDINGS=OFF \
  -D PYTHON_EXECUTABLE=/usr/bin/python-32 \
  -D CMAKE_CXX_COMPILER="/usr/bin/clang++" \
  -D CMAKE_C_COMPILER="/usr/bin/clang" \
  -D LLVM_USE_LINKER="/usr/bin/ld.lld" \
  -D CMAKE_RANLIB="/usr/bin/llvm-ranlib" \
  -D CMAKE_AR="/usr/bin/llvm-ar" \
  -D LLVM_ENABLE_LTO=OFF \
  -D LLVM_BUILD_LLVM_DYLIB=ON \
  -D LLVM_LINK_LLVM_DYLIB=ON \
  -D LLVM_ENABLE_PROJECTS="clang;compiler-rt;lld;lldb;clang-tools-extra" \
  -D LLVM_APPEND_VC_REV=ON \
  -D LLVM_HOST_TRIPLE="x86_64-pc-linux-gnu" \
  -D LLVM_ENABLE_RTTI=ON \
  -D LLVM_ENABLE_FFI=ON \
  -D FFI_INCLUDE_DIR="/usr/lib32/libffi-3.2.1/include" \
  -D LLVM_BUILD_TESTS=ON \
  -D LLVM_VERSION_SUFFIX= \
  -D CMAKE_POLICY_DEFAULT_CMP0075=NEW \
  -D LLVM_OPTIMIZED_TABLEGEN=ON \
  -D LLVM_CCACHE_BUILD=ON \
  -D CMAKE_POLICY_DEFAULT_CMP0075=NEW \
  -D CMAKE_C_FLAGS="-march=native -O3 -pipe -ffast-math -funroll-loops 
-fstack-protector-strong -fno-plt -mno-xop -mno-fma4 -mno-tbm -m32" \
  -D CMAKE_CXX_FLAGS="-march=native -O3 -pipe -ffast-math -funroll-loops 
-fstack-protector-strong -fno-plt -mno-xop -mno-fma4 -mno-tbm -m32" \
  -D LLVM_TARGETS_TO_BUILD="AMDGPU;X86" \
  -D LLVM_BINUTILS_INCDIR=/usr/include \
  -D LLVM_EXTERNAL_LIT="/usr/bin/lit" \
  -D LLVM_BUILD_DOCS=OFF \
  -D LLVM_INCLUDE_DOCS=OFF \
  -D LLVM_ENABLE_SPHINX=OFF \
  -D LLVM_ENABLE_DOXYGEN=OFF \
  -D LLVM_INSTALL_UTILS=ON \
  -D LLVM_PARALLEL_LINK_JOBS=1 \
  -D CMAKE_INSTALL_PREFIX="/opt/llvm32"
  ninja -j4 all
  DESTDIR=/build/llvm-git-gentz/pkg/lib32-llvm-git-gentz ninja -j4 install

A lot... err, most... of the things I cargo culted from other sources.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583



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

[Lldb-commits] [lldb] r372300 - [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBER

[Michal Gorny via lldb-commits]

Author: mgorny
Date: Wed Sep 18 22:49:14 2019
New Revision: 372300

URL: http://llvm.org/viewvc/llvm-project?rev=372300&view=rev
Log:
[lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBER

Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER.

Differential Revision: https://reviews.llvm.org/D67727

Modified:

lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

Modified: 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp?rev=372300&r1=372299&r2=372300&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
 Wed Sep 18 22:49:14 2019
@@ -1454,7 +1454,8 @@ GDBRemoteCommunicationServerLLGS::Handle
   }
 
   // Build the ResumeActionList
-  ResumeActionList actions(StateType::eStateRunning, 0);
+  ResumeActionList actions(StateType::eStateRunning,
+   LLDB_INVALID_SIGNAL_NUMBER);
 
   Status error = m_debugged_process_up->Resume(actions);
   if (error.Fail()) {
@@ -1521,7 +1522,7 @@ GDBRemoteCommunicationServerLLGS::Handle
 ResumeAction thread_action;
 thread_action.tid = LLDB_INVALID_THREAD_ID;
 thread_action.state = eStateInvalid;
-thread_action.signal = 0;
+thread_action.signal = LLDB_INVALID_SIGNAL_NUMBER;
 
 const char action = packet.GetChar();
 switch (action) {
@@ -2724,7 +2725,7 @@ GDBRemoteCommunicationServerLLGS::Handle
 return SendErrorResponse(0x33);
 
   // Create the step action for the given thread.
-  ResumeAction action = {tid, eStateStepping, 0};
+  ResumeAction action = {tid, eStateStepping, LLDB_INVALID_SIGNAL_NUMBER};
 
   // Setup the actions list.
   ResumeActionList actions;


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

[Lldb-commits] [PATCH] D67727: [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBER

[Michał Górny via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372300: [lldb] [Process/gdb-remote] Correct more missing 
LLDB_INVALID_SIGNAL_NUMBER (authored by mgorny, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67727?vs=220723&id=220816#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67727/new/

https://reviews.llvm.org/D67727

Files:
  
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp


Index: 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1454,7 +1454,8 @@
   }
 
   // Build the ResumeActionList
-  ResumeActionList actions(StateType::eStateRunning, 0);
+  ResumeActionList actions(StateType::eStateRunning,
+   LLDB_INVALID_SIGNAL_NUMBER);
 
   Status error = m_debugged_process_up->Resume(actions);
   if (error.Fail()) {
@@ -1521,7 +1522,7 @@
 ResumeAction thread_action;
 thread_action.tid = LLDB_INVALID_THREAD_ID;
 thread_action.state = eStateInvalid;
-thread_action.signal = 0;
+thread_action.signal = LLDB_INVALID_SIGNAL_NUMBER;
 
 const char action = packet.GetChar();
 switch (action) {
@@ -2724,7 +2725,7 @@
 return SendErrorResponse(0x33);
 
   // Create the step action for the given thread.
-  ResumeAction action = {tid, eStateStepping, 0};
+  ResumeAction action = {tid, eStateStepping, LLDB_INVALID_SIGNAL_NUMBER};
 
   // Setup the actions list.
   ResumeActionList actions;


Index: lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1454,7 +1454,8 @@
   }
 
   // Build the ResumeActionList
-  ResumeActionList actions(StateType::eStateRunning, 0);
+  ResumeActionList actions(StateType::eStateRunning,
+   LLDB_INVALID_SIGNAL_NUMBER);
 
   Status error = m_debugged_process_up->Resume(actions);
   if (error.Fail()) {
@@ -1521,7 +1522,7 @@
 ResumeAction thread_action;
 thread_action.tid = LLDB_INVALID_THREAD_ID;
 thread_action.state = eStateInvalid;
-thread_action.signal = 0;
+thread_action.signal = LLDB_INVALID_SIGNAL_NUMBER;
 
 const char action = packet.GetChar();
 switch (action) {
@@ -2724,7 +2725,7 @@
 return SendErrorResponse(0x33);
 
   // Create the step action for the given thread.
-  ResumeAction action = {tid, eStateStepping, 0};
+  ResumeAction action = {tid, eStateStepping, LLDB_INVALID_SIGNAL_NUMBER};
 
   // Setup the actions list.
   ResumeActionList actions;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67583: Fix swig python package path

[Haibo Huang via Phabricator via lldb-commits]

hhb added a comment.

I don't have the right environment to try your command. But I didn't see 
anything obviously problematic.

Can you try the following:

  cd /src/llvm-project/lldb/scripts/Python

Then run the following python program:

  import sys
  sys.path.append('/src/llvm-project/lldb/scripts/Python')
  import finishSwigPythonLLDB
  vDictArgs = {"--srcRoot": "/src/llvm-project/lldb",
   "--targetDir": "/src/out/./lib32",
   "--cfgBldDir": "/src/out/tools/lldb/scripts",
   "--prefix": "/src/out",
   "--cmakeBuildConfiguration": ".",
   "--lldbLibDir": "lib32",
   "-m": None,
  }
  finishSwigPythonLLDB.get_framework_python_dir(vDictArgs)

For me the output is:

  (True, '/src/out/./lib/python2.7/site-packages/lldb', '')

Notice that the lib part don't have 32 prefix, even we specified that in 
parameters.

I kind of feeling that we should change this script to simply return targetDir. 
There's no good reason to use get_python_lib() and depends on python's 
implementation. But I don't know enough to make this decision...


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583



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

[Lldb-commits] [PATCH] D67583: Fix swig python package path

[Haibo Huang via Phabricator via lldb-commits]

hhb added a comment.

+deepak2427 since this behavior is introduced in 
https://github.com/llvm/llvm-project/commit/9b35cf52d2a88cda5167c9638696adce5b152720


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67583/new/

https://reviews.llvm.org/D67583



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