[Lldb-commits] [PATCH] D68179: [lldb] Fix JSON parser to allow empty arrays

2019-11-14 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Looks good to me. If I was writing the test, I'd probably just make it do a 
string->json->string round-trip and then verify the final string. But this is 
fine too...




Comment at: lldb/unittests/debugserver/JSONTest.cpp:16-17
+void TestJSON(JSONValue *json_val, const std::function &test_func) {
+  EXPECT_THAT(json_val, testing::NotNull());
+  EXPECT_TRUE(T::classof(json_val));
+  test_func(static_cast(*json_val));

You may want to change these into ASSERT_xxx to avoid crashing later if the 
expectations are not met.


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

https://reviews.llvm.org/D68179



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


[Lldb-commits] [PATCH] D70177: [lldb] Fix that trailing backslashes in source lines break the Clang highlighter

2019-11-14 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor updated this revision to Diff 229241.
teemperor added a comment.

- Turns out \r is also a new line that can be escaped, so that is now also 
handled. Also moved to a variable storing the line ending instead of three 
bools.


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

https://reviews.llvm.org/D70177

Files:
  lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
  lldb/unittests/Language/Highlighting/HighlighterTest.cpp


Index: lldb/unittests/Language/Highlighting/HighlighterTest.cpp
===
--- lldb/unittests/Language/Highlighting/HighlighterTest.cpp
+++ lldb/unittests/Language/Highlighting/HighlighterTest.cpp
@@ -205,6 +205,44 @@
 highlightC("#include \"foo\" //c", s));
 }
 
+TEST_F(HighlighterTest, ClangPreserveNewLine) {
+  HighlightStyle s;
+  s.comment.Set("", "");
+
+  EXPECT_EQ("//\n", highlightC("//\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashBeforeNewline) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\\n", highlightC("\\\n", s));
+  EXPECT_EQ("\\\r\n", highlightC("\\\r\n", s));
+
+  EXPECT_EQ("#define a \\\n", highlightC("#define a \\\n", s));
+  EXPECT_EQ("#define a \\\r\n", highlightC("#define a \\\r\n", s));
+  EXPECT_EQ("#define a \\\r", highlightC("#define a \\\r", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashWithWhitespace) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\  \n", highlightC("\\  \n", s));
+  EXPECT_EQ("\\ \t\n", highlightC("\\ \t\n", s));
+  EXPECT_EQ("\\ \n", highlightC("\\ \n", s));
+  EXPECT_EQ("\\\t\n", highlightC("\\\t\n", s));
+
+  EXPECT_EQ("#define a \\  \n", highlightC("#define a \\  \n", s));
+  EXPECT_EQ("#define a \\ \t\n", highlightC("#define a \\ \t\n", s));
+  EXPECT_EQ("#define a \\ \n", highlightC("#define a \\ \n", s));
+  EXPECT_EQ("#define a \\\t\n", highlightC("#define a \\\t\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashMissingNewLine) {
+  HighlightStyle s;
+  EXPECT_EQ("\\", highlightC("\\", s));
+  EXPECT_EQ("#define a\\", highlightC("#define a\\", s));
+}
+
 TEST_F(HighlighterTest, ClangComments) {
   HighlightStyle s;
   s.comment.Set("", "");
Index: lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
===
--- lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
+++ lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
@@ -139,6 +139,22 @@
   FileManager file_mgr(file_opts,
FileSystem::Instance().GetVirtualFileSystem());
 
+  // The line might end in a backslash which would cause Clang to drop the
+  // backslash and the terminating new line. This makes sense when parsing C++,
+  // but when highlighting we care about preserving the backslash/newline. To
+  // not lose this information we remove the new line here so that Clang knows
+  // this is just a single line we are highlighting. We add back the newline
+  // after tokenizing.
+  llvm::StringRef line_ending = "";
+  // There are a few legal line endings Clang recognizes and we need to
+  // temporarily remove from the string.
+  if (line.consume_back("\r\n"))
+line_ending = "\r\n";
+  else if (line.consume_back("\n"))
+line_ending = "\n";
+  else if (line.consume_back("\r"))
+line_ending = "\r";
+
   unsigned line_number = previous_lines.count('\n') + 1U;
 
   // Let's build the actual source code Clang needs and setup some utility
@@ -227,6 +243,9 @@
 color.Apply(result, to_print);
   }
 
+  // Add the line ending we trimmed before tokenizing.
+  result << line_ending;
+
   // If we went over the whole file but couldn't find our own file, then
   // somehow our setup was wrong. When we're in release mode we just give the
   // user the normal line and pretend we don't know how to highlight it. In


Index: lldb/unittests/Language/Highlighting/HighlighterTest.cpp
===
--- lldb/unittests/Language/Highlighting/HighlighterTest.cpp
+++ lldb/unittests/Language/Highlighting/HighlighterTest.cpp
@@ -205,6 +205,44 @@
 highlightC("#include \"foo\" //c", s));
 }
 
+TEST_F(HighlighterTest, ClangPreserveNewLine) {
+  HighlightStyle s;
+  s.comment.Set("", "");
+
+  EXPECT_EQ("//\n", highlightC("//\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashBeforeNewline) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\\n", highlightC("\\\n", s));
+  EXPECT_EQ("\\\r\n", highlightC("\\\r\n", s));
+
+  EXPECT_EQ("#define a \\\n", highlightC("#define a \\\n", s));
+  EXPECT_EQ("#define a \\\r\n", highlightC("#define a \\\r\n", s));
+  EXPECT_EQ("#define a \\\r", highlightC("#define a \\\r", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashWithWhitespace) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\  \n", highlightC("\\  \n", s));
+  EXPECT_EQ("\\ \t\n", highlightC("\\ \t\n", s));
+  EXPECT_EQ("\\ \n", highlightC("\\ \n", s));
+  EXPECT_EQ("\\\t\n", highlightC("\\\t\n

[Lldb-commits] [PATCH] D70154: [LLDB] Fix whitespace/tabs mismatch in lldbsuite Makefile.rules

2019-11-14 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D70154#1743904 , @labath wrote:

> It looks like you're replacing everything with tabs. I suppose that's fine, 
> as that is the prevalent local convention, but it might be better to go for 
> spaces, as we don't use tabs anywhere else.


Legacy make files always used tabs though modern make version can work with 
white-spaces I have chosen the legacy just to be safe.


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

https://reviews.llvm.org/D70154



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


[Lldb-commits] [lldb] f9f30f2 - [LLDB] Fix whitespace/tabs mismatch in lldbsuite Makefile.rules

2019-11-14 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2019-11-14T13:53:58+05:00
New Revision: f9f30f2ecba520fa1ce33ae7c27c807a0e7199be

URL: 
https://github.com/llvm/llvm-project/commit/f9f30f2ecba520fa1ce33ae7c27c807a0e7199be
DIFF: 
https://github.com/llvm/llvm-project/commit/f9f30f2ecba520fa1ce33ae7c27c807a0e7199be.diff

LOG: [LLDB] Fix whitespace/tabs mismatch in lldbsuite Makefile.rules

This patch fixes whitespace/tabs mismatch in
lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Legacy make files always used tabs though modern make version can
work with white-spaces I have chosen the legacy just to be safe.

Signed-off-by: Muhammad Omair Javaid 

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules 
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index 53729548cc4b..bde94d2c462b 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -181,8 +181,8 @@ endif
 
 ifeq "$(OS)" "Darwin"
 ifeq "$(SDKROOT)" ""
-# We haven't otherwise set the SDKROOT, so set it now to macosx
-SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path)
+   # We haven't otherwise set the SDKROOT, so set it now to macosx
+   SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path)
 endif
 endif
 
@@ -360,46 +360,46 @@ endif
 
 # Function that returns the counterpart C++ compiler, given $(CC) as arg.
 cxx_compiler_notdir = $(if $(findstring icc,$(1)), \
-$(subst icc,icpc,$(1)), \
-$(if $(findstring llvm-gcc,$(1)), \
- $(subst llvm-gcc,llvm-g++,$(1)), \
- $(if $(findstring gcc,$(1)), \
-  $(subst gcc,g++,$(1)), \
-  $(subst cc,c++,$(1)
+   $(subst icc,icpc,$(1)), \
+   $(if $(findstring llvm-gcc,$(1)), \
+   $(subst llvm-gcc,llvm-g++,$(1)), \
+   $(if $(findstring gcc,$(1)), \
+   $(subst gcc,g++,$(1)), \
+   $(subst cc,c++,$(1)
 cxx_compiler = $(if $(findstring /,$(1)),$(join $(dir $(1)), $(call 
cxx_compiler_notdir,$(notdir $(1,$(call cxx_compiler_notdir,$(1)))
 
 # Function that returns the C++ linker, given $(CC) as arg.
 cxx_linker_notdir = $(if $(findstring icc,$(1)), \
-  $(subst icc,icpc,$(1)), \
-  $(if $(findstring llvm-gcc,$(1)), \
-   $(subst llvm-gcc,llvm-g++,$(1)), \
-   $(if $(findstring gcc,$(1)), \
-$(subst gcc,g++,$(1)), \
-$(subst cc,c++,$(1)
+   $(subst icc,icpc,$(1)), \
+   $(if $(findstring llvm-gcc,$(1)), \
+   $(subst llvm-gcc,llvm-g++,$(1)), \
+   $(if $(findstring gcc,$(1)), \
+   $(subst gcc,g++,$(1)), \
+   $(subst cc,c++,$(1)
 cxx_linker = $(if $(findstring /,$(1)),$(join $(dir $(1)), $(call 
cxx_linker_notdir,$(notdir $(1,$(call cxx_linker_notdir,$(1)))
 
 ifneq "$(OS)" "Darwin"
-CLANG_OR_GCC := $(strip $(if $(findstring clang,$(CC)), \
- $(findstring clang,$(CC)), \
- $(if $(findstring gcc,$(CC)), \
-  $(findstring gcc,$(CC)), \
-  cc)))
-
-CC_LASTWORD := $(strip $(lastword $(subst -, ,$(CC
-
-replace_with = $(strip $(if $(findstring $(3),$(CC_LASTWORD)), \
-   $(subst $(3),$(1),$(2)), \
-   $(subst $(3),$(1),$(subst -$(CC_LASTWORD),,$(2)
-
-ifeq "$(notdir $(CC))" "$(CC)"
-replace_cc_with = $(call replace_with,$(1),$(CC),$(CLANG_OR_GCC))
-else
-replace_cc_with = $(join $(dir $(CC)),$(call 
replace_with,$(1),$(notdir $(CC)),$(CLANG_OR_GCC)))
-endif
+   CLANG_OR_GCC := $(strip $(if $(findstring clang,$(CC)), \
+   $(findstring clang,$(CC)), \
+   $(if $(findstring gcc,$(CC)), \
+   $(findstring gcc,$(CC)), \
+   cc)))
+
+   CC_LASTWORD := $(strip $(lastword $(subst -, ,$(CC
+
+   replace_with = $(strip $(if $(findstring $(3),$(CC_LASTWORD)), \
+   $(subst $(3),$(1),$(2)), \
+   $(subst $(3),$(1),$(subst -$(CC_LASTWORD),,$(2

[Lldb-commits] [lldb] ea2ba51 - [lldb][NFC] Simplify IOHandler constructor/destructor setup

2019-11-14 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2019-11-14T09:59:00+01:00
New Revision: ea2ba51b0b2f5bc0bea650bf64e5cbd63476563f

URL: 
https://github.com/llvm/llvm-project/commit/ea2ba51b0b2f5bc0bea650bf64e5cbd63476563f
DIFF: 
https://github.com/llvm/llvm-project/commit/ea2ba51b0b2f5bc0bea650bf64e5cbd63476563f.diff

LOG: [lldb][NFC] Simplify IOHandler constructor/destructor setup

We only need a default constructor because of DISALLOW_COPY_AND_ASSIGN,
but the non-virtual destructor isn't needed.

Added: 


Modified: 
lldb/include/lldb/Core/IOHandler.h

Removed: 




diff  --git a/lldb/include/lldb/Core/IOHandler.h 
b/lldb/include/lldb/Core/IOHandler.h
index 37142a5a8396..04b94da3a8c1 100644
--- a/lldb/include/lldb/Core/IOHandler.h
+++ b/lldb/include/lldb/Core/IOHandler.h
@@ -495,9 +495,7 @@ class IOHandlerCursesValueObjectList : public IOHandler {
 
 class IOHandlerStack {
 public:
-  IOHandlerStack() : m_stack(), m_mutex(), m_top(nullptr) {}
-
-  ~IOHandlerStack() = default;
+  IOHandlerStack() = default;
 
   size_t GetSize() const {
 std::lock_guard guard(m_mutex);
@@ -574,7 +572,7 @@ class IOHandlerStack {
   typedef std::vector collection;
   collection m_stack;
   mutable std::recursive_mutex m_mutex;
-  IOHandler *m_top;
+  IOHandler *m_top = nullptr;
 
 private:
   DISALLOW_COPY_AND_ASSIGN(IOHandlerStack);



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


[Lldb-commits] [PATCH] D70154: [LLDB] Fix whitespace/tabs mismatch in lldbsuite Makefile.rules

2019-11-14 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf9f30f2ecba5: [LLDB] Fix whitespace/tabs mismatch in 
lldbsuite Makefile.rules (authored by omjavaid).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70154

Files:
  lldb/packages/Python/lldbsuite/test/make/Makefile.rules


Index: lldb/packages/Python/lldbsuite/test/make/Makefile.rules
===
--- lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -181,8 +181,8 @@
 
 ifeq "$(OS)" "Darwin"
 ifeq "$(SDKROOT)" ""
-# We haven't otherwise set the SDKROOT, so set it now to macosx
-SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path)
+   # We haven't otherwise set the SDKROOT, so set it now to macosx
+   SDKROOT := $(shell xcrun --sdk macosx --show-sdk-path)
 endif
 endif
 
@@ -360,46 +360,46 @@
 
 # Function that returns the counterpart C++ compiler, given $(CC) as arg.
 cxx_compiler_notdir = $(if $(findstring icc,$(1)), \
-$(subst icc,icpc,$(1)), \
-$(if $(findstring llvm-gcc,$(1)), \
- $(subst llvm-gcc,llvm-g++,$(1)), \
- $(if $(findstring gcc,$(1)), \
-  $(subst gcc,g++,$(1)), \
-  $(subst cc,c++,$(1)
+   $(subst icc,icpc,$(1)), \
+   $(if $(findstring llvm-gcc,$(1)), \
+   $(subst llvm-gcc,llvm-g++,$(1)), \
+   $(if $(findstring gcc,$(1)), \
+   $(subst gcc,g++,$(1)), \
+   $(subst cc,c++,$(1)
 cxx_compiler = $(if $(findstring /,$(1)),$(join $(dir $(1)), $(call 
cxx_compiler_notdir,$(notdir $(1,$(call cxx_compiler_notdir,$(1)))
 
 # Function that returns the C++ linker, given $(CC) as arg.
 cxx_linker_notdir = $(if $(findstring icc,$(1)), \
-  $(subst icc,icpc,$(1)), \
-  $(if $(findstring llvm-gcc,$(1)), \
-   $(subst llvm-gcc,llvm-g++,$(1)), \
-   $(if $(findstring gcc,$(1)), \
-$(subst gcc,g++,$(1)), \
-$(subst cc,c++,$(1)
+   $(subst icc,icpc,$(1)), \
+   $(if $(findstring llvm-gcc,$(1)), \
+   $(subst llvm-gcc,llvm-g++,$(1)), \
+   $(if $(findstring gcc,$(1)), \
+   $(subst gcc,g++,$(1)), \
+   $(subst cc,c++,$(1)
 cxx_linker = $(if $(findstring /,$(1)),$(join $(dir $(1)), $(call 
cxx_linker_notdir,$(notdir $(1,$(call cxx_linker_notdir,$(1)))
 
 ifneq "$(OS)" "Darwin"
-CLANG_OR_GCC := $(strip $(if $(findstring clang,$(CC)), \
- $(findstring clang,$(CC)), \
- $(if $(findstring gcc,$(CC)), \
-  $(findstring gcc,$(CC)), \
-  cc)))
-
-CC_LASTWORD := $(strip $(lastword $(subst -, ,$(CC
-
-replace_with = $(strip $(if $(findstring $(3),$(CC_LASTWORD)), \
-   $(subst $(3),$(1),$(2)), \
-   $(subst $(3),$(1),$(subst -$(CC_LASTWORD),,$(2)
-
-ifeq "$(notdir $(CC))" "$(CC)"
-replace_cc_with = $(call replace_with,$(1),$(CC),$(CLANG_OR_GCC))
-else
-replace_cc_with = $(join $(dir $(CC)),$(call 
replace_with,$(1),$(notdir $(CC)),$(CLANG_OR_GCC)))
-endif
+   CLANG_OR_GCC := $(strip $(if $(findstring clang,$(CC)), \
+   $(findstring clang,$(CC)), \
+   $(if $(findstring gcc,$(CC)), \
+   $(findstring gcc,$(CC)), \
+   cc)))
+
+   CC_LASTWORD := $(strip $(lastword $(subst -, ,$(CC
+
+   replace_with = $(strip $(if $(findstring $(3),$(CC_LASTWORD)), \
+   $(subst $(3),$(1),$(2)), \
+   $(subst $(3),$(1),$(subst -$(CC_LASTWORD),,$(2)
+
+   ifeq "$(notdir $(CC))" "$(CC)"
+   replace_cc_with = $(call 
replace_with,$(1),$(CC),$(CLANG_OR_GCC))
+   else
+   replace_cc_with = $(join $(dir $(CC)),$(call 
replace_with,$(1),$(notdir $(CC)),$(CLANG_OR_GCC)))
+   endif
 
-OBJCOPY ?= $(call replace_cc_with,objcopy)
-ARCHIVER ?= $(call replace_cc_with,ar)
-override AR = $(ARCHIVER)
+   OBJCOPY ?= $(call replace_cc_with,objcopy)
+   ARCHIVER ?= $(call replace_cc_with,ar)
+   override AR = $

[Lldb-commits] [PATCH] D63540: Fix lookup of symbols at the same address with no size vs. size

2019-11-14 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

In D63540#1744110 , @jankratochvil 
wrote:

> It is still the same (no arm32 regression) with 
> `16bdcc809c72c639a2888b6b859dca88453e3c28` and this patch reapplied.


Hi Jan,

This issue manifests itself only when lldb test suite is being run on 32-bit 
arm host. I think we dont run complete testsuite when we test via lldb-dotest 
with lldb-server cross-compiled for Arm 32-bit.

I am trying to find a reasonable way to reproduce this issue. I ll get back to 
you with more details.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63540



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


[Lldb-commits] [PATCH] D63540: Fix lookup of symbols at the same address with no size vs. size

2019-11-14 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

Getting `ld.lld: error: failed to open ../../../../bin/clang-10: Cannot 
allocate memory` when trying to build `lldb` natively on arm32 (the same error 
happens both for `clang` and for `lldb`).  Apparently memory is not a problem 
but the linker runs out of its 32-bit address space.
I am aware of the cross-compiling `lldb` possibility but I haven't tried that 
yet. Do you have some simple instructions how to cross-compile `lldb` for arm32 
on x86_64 host?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63540



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


Re: [Lldb-commits] [PATCH] D63540: Fix lookup of symbols at the same address with no size vs. size

2019-11-14 Thread Omair Javaid via lldb-commits
On Thu, 14 Nov 2019 at 15:04, Jan Kratochvil via Phabricator <
revi...@reviews.llvm.org> wrote:

> jankratochvil added a comment.
>
> Getting `ld.lld: error: failed to open ../../../../bin/clang-10: Cannot
> allocate memory` when trying to build `lldb` natively on arm32 (the same
> error happens both for `clang` and for `lldb`).  Apparently memory is not a
> problem but the linker runs out of its 32-bit address space.
> I am aware of the cross-compiling `lldb` possibility but I haven't tried
> that yet. Do you have some simple instructions how to cross-compile `lldb`
> for arm32 on x86_64 host?
>

C_COMPILER=clang
CXX_COMPILER=clang++
LLVM_SOURCE_DIR="../../llvm-project/llvm"

BUILD_ENV_TRIPLE=`gcc -dumpmachine`

GCC_INC=/usr/$LLDB_HOST_TRIPLE/include
#GCC_V3=`gcc --version | grep ^gcc | sed 's/^.* //g'`
GCC_V3=`gcc -dumpversion`
TARGET_C_FLAGS="-target $LLDB_HOST_TRIPLE -I/$GCC_INC
-I/$GCC_INC/c++/$GCC_V3/$LLDB_HOST_TRIPLE"
TARGET_CXX_FLAGS="$TARGET_C_FLAGS"

cd ./build/$LLDB_HOST_TRIPLE

cmake -G Ninja \
-DCMAKE_CROSSCOMPILING=True \
-DCMAKE_C_COMPILER=$C_COMPILER \
-DCMAKE_CXX_COMPILER=$CXX_COMPILER \
-DCMAKE_C_FLAGS="$TARGET_C_FLAGS" \
-DCMAKE_CXX_FLAGS="$TARGET_CXX_FLAGS" \
-DLLDB_TEST_COMPILER=$LLDB_HOST_TRIPLE-gcc \
-DLLVM_USE_LINKER=gold \
-DLLVM_TABLEGEN=$PWD/../host/bin/llvm-tblgen \
-DCLANG_TABLEGEN=$PWD/../host/bin/clang-tblgen \
-DLLDB_TABLEGEN=$PWD/../host/bin/lldb-tblgen \
-DLLVM_HOST_TRIPLE=$LLDB_HOST_TRIPLE \
-DLLVM_ENABLE_PROJECTS="clang;lldb" \
-DLLVM_TARGETS_TO_BUILD=$TARGET_ARCH \
-DCMAKE_LIBRARY_ARCHITECTURE=$LLDB_HOST_TRIPLE \
-DCMAKE_IGNORE_PATH=/usr/lib/$BUILD_ENV_TRIPLE \
-DLLDB_DISABLE_PYTHON=1 \
-DLLDB_DISABLE_LIBEDIT=1 \
-DLLDB_DISABLE_CURSES=1 \
-DCMAKE_BUILD_TYPE=Release \
-DLLDB_EXPORT_ALL_SYMBOLS=1 \
-DLLVM_ENABLE_ASSERTIONS=On \
$LLVM_SOURCE_DIR

ninja lldb-server


>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D63540/new/
>
> https://reviews.llvm.org/D63540
>
>
>
>

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


[Lldb-commits] [lldb] 8715ffd - [lldb] Fix that trailing backslashes in source lines break the Clang highlighter

2019-11-14 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2019-11-14T11:11:20+01:00
New Revision: 8715ffdf1aafbfca7c3d7f1622fe586243f31df1

URL: 
https://github.com/llvm/llvm-project/commit/8715ffdf1aafbfca7c3d7f1622fe586243f31df1
DIFF: 
https://github.com/llvm/llvm-project/commit/8715ffdf1aafbfca7c3d7f1622fe586243f31df1.diff

LOG: [lldb] Fix that trailing backslashes in source lines break the Clang 
highlighter

Summary:
Clang's raw Lexer doesn't produce any tokens for trailing backslashes in a 
line. This doesn't work with
LLDB's Clang highlighter which builds the source code to display from the list 
of tokens the Lexer returns.
This causes that lines with trailing backslashes are lacking the backslash and 
the following newline when
rendering source code in LLDB.

This patch removes the trailing newline from the current line we are 
highlighting. This way Clang doesn't
drop the backslash token and we just restore the newline after tokenising.

Fixes rdar://57091487

Reviewers: JDevlieghere, labath

Reviewed By: JDevlieghere, labath

Subscribers: labath, lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
lldb/unittests/Language/Highlighting/HighlighterTest.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp 
b/lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
index a9a1b44731f2..3e77b1646739 100644
--- a/lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
+++ b/lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
@@ -139,6 +139,22 @@ void ClangHighlighter::Highlight(const HighlightStyle 
&options,
   FileManager file_mgr(file_opts,
FileSystem::Instance().GetVirtualFileSystem());
 
+  // The line might end in a backslash which would cause Clang to drop the
+  // backslash and the terminating new line. This makes sense when parsing C++,
+  // but when highlighting we care about preserving the backslash/newline. To
+  // not lose this information we remove the new line here so that Clang knows
+  // this is just a single line we are highlighting. We add back the newline
+  // after tokenizing.
+  llvm::StringRef line_ending = "";
+  // There are a few legal line endings Clang recognizes and we need to
+  // temporarily remove from the string.
+  if (line.consume_back("\r\n"))
+line_ending = "\r\n";
+  else if (line.consume_back("\n"))
+line_ending = "\n";
+  else if (line.consume_back("\r"))
+line_ending = "\r";
+
   unsigned line_number = previous_lines.count('\n') + 1U;
 
   // Let's build the actual source code Clang needs and setup some utility
@@ -227,6 +243,9 @@ void ClangHighlighter::Highlight(const HighlightStyle 
&options,
 color.Apply(result, to_print);
   }
 
+  // Add the line ending we trimmed before tokenizing.
+  result << line_ending;
+
   // If we went over the whole file but couldn't find our own file, then
   // somehow our setup was wrong. When we're in release mode we just give the
   // user the normal line and pretend we don't know how to highlight it. In

diff  --git a/lldb/unittests/Language/Highlighting/HighlighterTest.cpp 
b/lldb/unittests/Language/Highlighting/HighlighterTest.cpp
index 71457ed61892..ebcc6122245f 100644
--- a/lldb/unittests/Language/Highlighting/HighlighterTest.cpp
+++ b/lldb/unittests/Language/Highlighting/HighlighterTest.cpp
@@ -205,6 +205,44 @@ TEST_F(HighlighterTest, ClangPPDirectives) {
 highlightC("#include \"foo\" //c", s));
 }
 
+TEST_F(HighlighterTest, ClangPreserveNewLine) {
+  HighlightStyle s;
+  s.comment.Set("", "");
+
+  EXPECT_EQ("//\n", highlightC("//\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashBeforeNewline) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\\n", highlightC("\\\n", s));
+  EXPECT_EQ("\\\r\n", highlightC("\\\r\n", s));
+
+  EXPECT_EQ("#define a \\\n", highlightC("#define a \\\n", s));
+  EXPECT_EQ("#define a \\\r\n", highlightC("#define a \\\r\n", s));
+  EXPECT_EQ("#define a \\\r", highlightC("#define a \\\r", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashWithWhitespace) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\  \n", highlightC("\\  \n", s));
+  EXPECT_EQ("\\ \t\n", highlightC("\\ \t\n", s));
+  EXPECT_EQ("\\ \n", highlightC("\\ \n", s));
+  EXPECT_EQ("\\\t\n", highlightC("\\\t\n", s));
+
+  EXPECT_EQ("#define a \\  \n", highlightC("#define a \\  \n", s));
+  EXPECT_EQ("#define a \\ \t\n", highlightC("#define a \\ \t\n", s));
+  EXPECT_EQ("#define a \\ \n", highlightC("#define a \\ \n", s));
+  EXPECT_EQ("#define a \\\t\n", highlightC("#define a \\\t\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashMissingNewLine) {
+  HighlightStyle s;
+  EXPECT_EQ("\\", highlightC("\\", s));
+  EXPECT_EQ("#define a\\", highlightC("#define a\\", s));
+}
+
 TEST_F(HighlighterTest, ClangComments) {
   HighlightS

[Lldb-commits] [PATCH] D70177: [lldb] Fix that trailing backslashes in source lines break the Clang highlighter

2019-11-14 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8715ffdf1aaf: [lldb] Fix that trailing backslashes in source 
lines break the Clang highlighter (authored by teemperor).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70177

Files:
  lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
  lldb/unittests/Language/Highlighting/HighlighterTest.cpp


Index: lldb/unittests/Language/Highlighting/HighlighterTest.cpp
===
--- lldb/unittests/Language/Highlighting/HighlighterTest.cpp
+++ lldb/unittests/Language/Highlighting/HighlighterTest.cpp
@@ -205,6 +205,44 @@
 highlightC("#include \"foo\" //c", s));
 }
 
+TEST_F(HighlighterTest, ClangPreserveNewLine) {
+  HighlightStyle s;
+  s.comment.Set("", "");
+
+  EXPECT_EQ("//\n", highlightC("//\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashBeforeNewline) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\\n", highlightC("\\\n", s));
+  EXPECT_EQ("\\\r\n", highlightC("\\\r\n", s));
+
+  EXPECT_EQ("#define a \\\n", highlightC("#define a \\\n", s));
+  EXPECT_EQ("#define a \\\r\n", highlightC("#define a \\\r\n", s));
+  EXPECT_EQ("#define a \\\r", highlightC("#define a \\\r", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashWithWhitespace) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\  \n", highlightC("\\  \n", s));
+  EXPECT_EQ("\\ \t\n", highlightC("\\ \t\n", s));
+  EXPECT_EQ("\\ \n", highlightC("\\ \n", s));
+  EXPECT_EQ("\\\t\n", highlightC("\\\t\n", s));
+
+  EXPECT_EQ("#define a \\  \n", highlightC("#define a \\  \n", s));
+  EXPECT_EQ("#define a \\ \t\n", highlightC("#define a \\ \t\n", s));
+  EXPECT_EQ("#define a \\ \n", highlightC("#define a \\ \n", s));
+  EXPECT_EQ("#define a \\\t\n", highlightC("#define a \\\t\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashMissingNewLine) {
+  HighlightStyle s;
+  EXPECT_EQ("\\", highlightC("\\", s));
+  EXPECT_EQ("#define a\\", highlightC("#define a\\", s));
+}
+
 TEST_F(HighlighterTest, ClangComments) {
   HighlightStyle s;
   s.comment.Set("", "");
Index: lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
===
--- lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
+++ lldb/source/Plugins/Language/ClangCommon/ClangHighlighter.cpp
@@ -139,6 +139,22 @@
   FileManager file_mgr(file_opts,
FileSystem::Instance().GetVirtualFileSystem());
 
+  // The line might end in a backslash which would cause Clang to drop the
+  // backslash and the terminating new line. This makes sense when parsing C++,
+  // but when highlighting we care about preserving the backslash/newline. To
+  // not lose this information we remove the new line here so that Clang knows
+  // this is just a single line we are highlighting. We add back the newline
+  // after tokenizing.
+  llvm::StringRef line_ending = "";
+  // There are a few legal line endings Clang recognizes and we need to
+  // temporarily remove from the string.
+  if (line.consume_back("\r\n"))
+line_ending = "\r\n";
+  else if (line.consume_back("\n"))
+line_ending = "\n";
+  else if (line.consume_back("\r"))
+line_ending = "\r";
+
   unsigned line_number = previous_lines.count('\n') + 1U;
 
   // Let's build the actual source code Clang needs and setup some utility
@@ -227,6 +243,9 @@
 color.Apply(result, to_print);
   }
 
+  // Add the line ending we trimmed before tokenizing.
+  result << line_ending;
+
   // If we went over the whole file but couldn't find our own file, then
   // somehow our setup was wrong. When we're in release mode we just give the
   // user the normal line and pretend we don't know how to highlight it. In


Index: lldb/unittests/Language/Highlighting/HighlighterTest.cpp
===
--- lldb/unittests/Language/Highlighting/HighlighterTest.cpp
+++ lldb/unittests/Language/Highlighting/HighlighterTest.cpp
@@ -205,6 +205,44 @@
 highlightC("#include \"foo\" //c", s));
 }
 
+TEST_F(HighlighterTest, ClangPreserveNewLine) {
+  HighlightStyle s;
+  s.comment.Set("", "");
+
+  EXPECT_EQ("//\n", highlightC("//\n", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashBeforeNewline) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\\n", highlightC("\\\n", s));
+  EXPECT_EQ("\\\r\n", highlightC("\\\r\n", s));
+
+  EXPECT_EQ("#define a \\\n", highlightC("#define a \\\n", s));
+  EXPECT_EQ("#define a \\\r\n", highlightC("#define a \\\r\n", s));
+  EXPECT_EQ("#define a \\\r", highlightC("#define a \\\r", s));
+}
+
+TEST_F(HighlighterTest, ClangTrailingBackslashWithWhitespace) {
+  HighlightStyle s;
+
+  EXPECT_EQ("\\  \n", highlightC("\\  \n", s));
+  EXPECT_EQ("\\ \t\n", highlightC("\\ \t\n", s));
+  EXPECT_EQ("\\ \n", highlightC("\\ \n", s));
+  EXPECT_EQ("\\\t\n", h

[Lldb-commits] [lldb] e03a06b - Fix typos in docs. NFC

2019-11-14 Thread Diana Picus via lldb-commits

Author: Diana Picus
Date: 2019-11-14T12:11:57+01:00
New Revision: e03a06b348ba49d774aa948f97bce3fac638a797

URL: 
https://github.com/llvm/llvm-project/commit/e03a06b348ba49d774aa948f97bce3fac638a797
DIFF: 
https://github.com/llvm/llvm-project/commit/e03a06b348ba49d774aa948f97bce3fac638a797.diff

LOG: Fix typos in docs. NFC

Added: 


Modified: 
lldb/docs/resources/contributing.rst

Removed: 




diff  --git a/lldb/docs/resources/contributing.rst 
b/lldb/docs/resources/contributing.rst
index 4305cdcaaf44..81171ec8524b 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -24,7 +24,7 @@ Policy in the following respects.
folder on disk for examples.
 
  - **Coding Style**: LLDB's code style 
diff ers from LLVM's coding style.
-   Unfortunately there is no document describing the 
diff erent. Please be
+   Unfortunately there is no document describing the 
diff erences. Please be
consistent with the existing code.
 
 For anything not explicitly listed here, assume that LLDB follows the LLVM
@@ -61,7 +61,7 @@ rules of thumb:
   what allows us to refactor and evolve the LLDB code base.
 
 * Logging. LLDB provides a very rich logging API. When recoverable
-  errors cannot reasonably by surfaced to the end user, the error may
+  errors cannot reasonably be surfaced to the end user, the error may
   be written to a topical log channel.
 
 * Soft assertions.  LLDB provides `lldb_assert()` as a soft



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


[Lldb-commits] [PATCH] D70023: [lldb] [Process/NetBSD] Copy watchpoints to newly-created threads

2019-11-14 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 229279.
mgorny added a comment.

Made dbregs copied only if any watchpoints are enabled, and added error 
handling.


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

https://reviews.llvm.org/D70023

Files:
  
lldb/packages/Python/lldbsuite/test/commands/watchpoints/multiple_threads/TestWatchpointMultipleThreads.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentDelaySignalWatch.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneWatchpoint.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentWatchBreakDelay.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentWatchpointDelayWatchpointOneBreakpoint.py
  
lldb/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
  lldb/source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD.h
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.h
  lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
  lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
  lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
  lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
  lldb/test/Shell/lit.cfg.py

Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -5,6 +5,7 @@
 import re
 import shutil
 import site
+import subprocess
 import sys
 
 import lit.formats
@@ -103,3 +104,17 @@
 
 if find_executable('xz') != None:
 config.available_features.add('xz')
+
+# NetBSD permits setting dbregs either if one is root
+# or if user_set_dbregs is enabled
+can_set_dbregs = True
+if platform.system() == 'NetBSD' and os.geteuid() != 0:
+try:
+output = subprocess.check_output(["/sbin/sysctl", "-n",
+  "security.models.extensions.user_set_dbregs"]).decode().strip()
+if output != "1":
+can_set_dbregs = False
+except subprocess.CalledProcessError:
+can_set_dbregs = False
+if can_set_dbregs:
+config.available_features.add('dbregs-set')
Index: lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
===
--- /dev/null
+++ lldb/test/Shell/Watchpoint/netbsd-nouserdbregs.test
@@ -0,0 +1,22 @@
+# Check that 'watchpoint set' errors out gracefully when we can't set dbregs
+# and that new threads are monitored correctly even though we can't copy dbregs.
+
+# REQUIRES: native && system-netbsd && (target-x86 || target-x86_64) && !dbregs-set
+# RUN: %clang %p/Inputs/thread-dbreg.c -pthread -g -o %t.out
+# RUN: %lldb -b -o 'settings set interpreter.stop-command-source-on-error false' -s %s %t.out 2>&1 | FileCheck %s
+
+settings show interpreter.stop-command-source-on-error
+# CHECK: interpreter.stop-command-source-on-error (boolean) = false
+
+b main
+# CHECK: Breakpoint {{[0-9]+}}: where = {{.*}}`main
+b thread_func
+# CHECK: Breakpoint {{[0-9]+}}: where = {{.*}}`thread_func
+run
+# CHECK: stop reason = breakpoint
+watchpoint set variable g_watchme
+# CHECK: error: Watchpoint creation failed
+cont
+# CHECK: stop reason = breakpoint
+cont
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
===
--- /dev/null
+++ lldb/test/Shell/Watchpoint/Inputs/thread-dbreg.c
@@ -0,0 +1,23 @@
+#include 
+
+int g_watchme = 0;
+
+void *thread_func(void *arg) {
+  /* watchpoint trigger from subthread */
+  g_watchme = 2;
+  return 0;
+}
+
+int main() {
+  pthread_t thread;
+  if (pthread_create(&thread, 0, thread_func, 0))
+return 1;
+
+  /* watchpoint trigger from main thread */
+  g_watchme = 1;
+
+  if (pthread_join(thread, 0))
+return 2;
+
+  return 0;
+}
Index: lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
===
--- lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
+++ lldb/source/Plugins/Process/NetBSD/NativeThreadNetBSD.h
@@ -62,6 +62,8 @@
   void SetRunning();
   void SetStepping();
 
+  Status CopyWatchpointsFrom(NativeThreadNetBSD& source);
+
   // Member Variabl

[Lldb-commits] [PATCH] D70238: [lldb] Allow loading of minidumps with no process id

2019-11-14 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: jingham, clayborg.
Herald added a project: LLDB.
labath added a comment.

Note: I am certain that there will be things which will fail for these kinds of 
"processes" -- there's plenty of `!= LLDB_INVALID_PID` checks, but most of them 
seem to be on the launch/attach code paths which are not exercised here. I am 
fine with fixing these as they are discovered -- the bigger question here is 
whether this is a reasonable direction to take lldb in. I think it is, because 
most of the `!= LLDB_INVALID_PID` checks look like they could be replaced by a 
check of the process state.


Normally, on linux we retrieve the process ID from the LinuxProcStatus
stream (which is just the contents of /proc/%d/status pseudo-file).

However, this stream is not strictly required (it's a breakpad
extension), and we are encountering a fair amount of minidumps which do
not have it present. It's not clear whether this is the case with all
these minidumps, but the two known situations where this stream can be
missing are:

- /proc filesystem not mounted (or something to that effect)
- process crashing after exhausting (almost) all file descriptors (so the 
minidump writer may not be able to open the /proc file)

At first I wanted to do something similar to what the gdb-remote plugin
does when talking to bare metal gdb stubs and like, and "invent" a
process ID in this case. However, then I noticed that most of the things
"just work" even if I leave the proces ID as "invalid".

Since it seems we have multiple use cases for a "process" without a
"process id", what I do in this patch instead is "downgrade" the missing
pid case to a warning. I also changes the "process status" output to
better handle the case of a missing/unknown pid.

The test case in this patch verifies that basic functionality still
works even with a pid-less minidump.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70238

Files:
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/source/Target/Process.cpp
  lldb/test/Shell/Minidump/no-process-id.yaml

Index: lldb/test/Shell/Minidump/no-process-id.yaml
===
--- /dev/null
+++ lldb/test/Shell/Minidump/no-process-id.yaml
@@ -0,0 +1,38 @@
+# RUN: yaml2obj %s > %t
+# RUN: %lldb -c %t -o "thread list" -o "register read" -b 2>&1 | FileCheck %s
+
+# CHECK: (lldb) target create --core
+# CHECK: Unable to retrieve process ID from minidump file.
+# CHECK: Core file {{.*}} was loaded.
+
+# CHECK: (lldb) thread list
+# CHECK: Process stopped
+# CHECK: * thread #1: tid = 16001, 0x00401dc6 a.out
+
+# CHECK: (lldb) register read
+# CHECK: rsp = 0x7ffceb34a210
+
+--- !minidump
+Streams:
+  - Type:ThreadList
+Threads:
+  - Thread Id:   0x3E81
+Context: 0B001000330006020100100010A234EBFC7F10A234EBFC7FF09C34EBFC7FC0A91ABCE97FA0163FBCE97F4602921C400030A434EBFC7FC61D40007F03801F0000FF00252525252525252525252525252525250000FF00FF000

[Lldb-commits] [PATCH] D70238: [lldb] Allow loading of minidumps with no process id

2019-11-14 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Note: I am certain that there will be things which will fail for these kinds of 
"processes" -- there's plenty of `!= LLDB_INVALID_PID` checks, but most of them 
seem to be on the launch/attach code paths which are not exercised here. I am 
fine with fixing these as they are discovered -- the bigger question here is 
whether this is a reasonable direction to take lldb in. I think it is, because 
most of the `!= LLDB_INVALID_PID` checks look like they could be replaced by a 
check of the process state.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70238



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


[Lldb-commits] [PATCH] D68179: [lldb] Fix JSON parser to allow empty arrays

2019-11-14 Thread Alex Cameron via Phabricator via lldb-commits
tetsuo-cpp updated this revision to Diff 229291.

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

https://reviews.llvm.org/D68179

Files:
  lldb/tools/debugserver/source/JSON.cpp
  lldb/tools/debugserver/source/JSON.h
  lldb/unittests/debugserver/CMakeLists.txt
  lldb/unittests/debugserver/JSONTest.cpp

Index: lldb/unittests/debugserver/JSONTest.cpp
===
--- /dev/null
+++ lldb/unittests/debugserver/JSONTest.cpp
@@ -0,0 +1,89 @@
+//===-- JSONTest.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+#include "JSON.h"
+
+template 
+void TestJSON(JSONValue *json_val, const std::function &test_func) {
+  ASSERT_THAT(json_val, testing::NotNull());
+  ASSERT_TRUE(T::classof(json_val));
+  test_func(static_cast(*json_val));
+}
+
+JSONValue::SP ParseJSON(const char *json_string) {
+  return JSONParser(json_string).ParseJSONValue();
+}
+
+template 
+void ParseAndTestJSON(
+const char *json_string,
+const std::function &test_func = [](T &) {}) {
+  auto json_val = ParseJSON(json_string);
+  TestJSON(json_val.get(), test_func);
+}
+
+TEST(JSON, Parse) {
+  ParseAndTestJSON("\"foo\"", [](JSONString &string_val) {
+EXPECT_EQ(string_val.GetData(), "foo");
+  });
+  EXPECT_THAT(ParseJSON("\"foo"), testing::IsNull());
+  ParseAndTestJSON("3", [](JSONNumber &number_val) {
+EXPECT_EQ(number_val.GetAsSigned(), 3);
+EXPECT_EQ(number_val.GetAsUnsigned(), 3u);
+EXPECT_EQ(number_val.GetAsDouble(), 3.0);
+  });
+  ParseAndTestJSON("-5", [](JSONNumber &number_val) {
+EXPECT_EQ(number_val.GetAsSigned(), -5);
+EXPECT_EQ(number_val.GetAsDouble(), -5.0);
+  });
+  ParseAndTestJSON("-6.4", [](JSONNumber &number_val) {
+EXPECT_EQ(number_val.GetAsSigned(), -6);
+EXPECT_EQ(number_val.GetAsDouble(), -6.4);
+  });
+  EXPECT_THAT(ParseJSON("-1.2.3"), testing::IsNull());
+  ParseAndTestJSON("true");
+  ParseAndTestJSON("false");
+  ParseAndTestJSON("null");
+  ParseAndTestJSON(
+  "{ \"key1\": 4, \"key2\": \"foobar\" }", [](JSONObject &obj_val) {
+TestJSON(obj_val.GetObject("key1").get(),
+ [](JSONNumber &number_val) {
+   EXPECT_EQ(number_val.GetAsSigned(), 4);
+   EXPECT_EQ(number_val.GetAsUnsigned(), 4u);
+   EXPECT_EQ(number_val.GetAsDouble(), 4.0);
+ });
+TestJSON(obj_val.GetObject("key2").get(),
+ [](JSONString &string_val) {
+   EXPECT_EQ(string_val.GetData(), "foobar");
+ });
+  });
+  ParseAndTestJSON("[1, \"bar\", 3.14]", [](JSONArray &array_val) {
+EXPECT_EQ(array_val.GetNumElements(), 3u);
+TestJSON(array_val.GetObject(0).get(),
+ [](JSONNumber &number_val) {
+   EXPECT_EQ(number_val.GetAsSigned(), 1);
+   EXPECT_EQ(number_val.GetAsUnsigned(), 1u);
+   EXPECT_EQ(number_val.GetAsDouble(), 1.0);
+ });
+TestJSON(
+array_val.GetObject(1).get(),
+[](JSONString &string_val) { EXPECT_EQ(string_val.GetData(), "bar"); });
+TestJSON(array_val.GetObject(2).get(),
+ [](JSONNumber &number_val) {
+   EXPECT_EQ(number_val.GetAsSigned(), 3);
+   EXPECT_EQ(number_val.GetAsUnsigned(), 3u);
+   EXPECT_EQ(number_val.GetAsDouble(), 3.14);
+ });
+  });
+  ParseAndTestJSON("[]", [](JSONArray &array_val) {
+EXPECT_EQ(array_val.GetNumElements(), 0u);
+  });
+}
Index: lldb/unittests/debugserver/CMakeLists.txt
===
--- lldb/unittests/debugserver/CMakeLists.txt
+++ lldb/unittests/debugserver/CMakeLists.txt
@@ -8,6 +8,7 @@
 ${LLDB_SOURCE_DIR}/tools/debugserver/source/MacOSX)
 
 add_lldb_unittest(debugserverTests
+  JSONTest.cpp
   RNBSocketTest.cpp
   debugserver_LogCallback.cpp
 
@@ -24,8 +25,9 @@
   WITH_FBS
   WITH_BKS
   )
-  
+
   add_lldb_unittest(debugserverNonUITests
+JSONTest.cpp
 RNBSocketTest.cpp
 debugserver_LogCallback.cpp
 
Index: lldb/tools/debugserver/source/JSON.h
===
--- lldb/tools/debugserver/source/JSON.h
+++ lldb/tools/debugserver/source/JSON.h
@@ -292,6 +292,8 @@
   JSONValue::SP ParseJSONValue();
 
 protected:
+  JSONValue::SP ParseJSONValue(const std::string &value, const Token &to

[Lldb-commits] [PATCH] D68179: [lldb] Fix JSON parser to allow empty arrays

2019-11-14 Thread Alex Cameron via Phabricator via lldb-commits
tetsuo-cpp marked an inline comment as done.
tetsuo-cpp added a comment.

Thanks for looking at this. I will need someone to commit it for me.
However, I've been having issues with the test suite on my MacBook. 
`check-lldb-unit` works for me but `check-llvm` and `check-lldb` are hitting 
issues because of something wrong with my environment. So I'll need to sort 
this out first to verify that I haven't broken anything before it's committed. 
I'm hoping to spend some time this weekend to debug my setup.


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

https://reviews.llvm.org/D68179



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


[Lldb-commits] [PATCH] D70215: Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

2019-11-14 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor accepted this revision.
teemperor added a comment.
This revision is now accepted and ready to land.

LGTM minus some small changes.




Comment at: lldb/include/lldb/Symbol/SymbolFile.h:127
+  /// Apply a lambda to each external lldb::Module referenced by this
+  /// compilation unit. Recursively also descends into the referenced external
+  /// modules of any encountered compilation unit.

"this compilation unit", that doesn't really fit to the SymbolFile class. Maybe 
we could just do like `@see CompileUnit::ForEachExternalModule`?



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2511
   // list.
+
   types.InsertUnique(matching_type->shared_from_this());

unrelated whitespace change?


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

https://reviews.llvm.org/D70215



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


[Lldb-commits] [PATCH] D70241: [lldb] remove unsigned Stream::operator<< overloads

2019-11-14 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: teemperor, JDevlieghere.
Herald added a reviewer: jdoerfert.
Herald added a project: LLDB.

I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.

Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.

Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70241

Files:
  lldb/include/lldb/Utility/Stream.h
  lldb/source/Expression/DWARFExpression.cpp
  lldb/source/Symbol/SymbolContext.cpp
  lldb/source/Symbol/Type.cpp
  lldb/source/Symbol/Variable.cpp
  lldb/source/Utility/Stream.cpp
  lldb/test/Shell/SymbolFile/DWARF/array-sizes.s
  lldb/unittests/Utility/StreamTest.cpp

Index: lldb/unittests/Utility/StreamTest.cpp
===
--- lldb/unittests/Utility/StreamTest.cpp
+++ lldb/unittests/Utility/StreamTest.cpp
@@ -304,15 +304,6 @@
   EXPECT_EQ("127 32767 2147483647 9223372036854775807", TakeValue());
 }
 
-TEST_F(StreamTest, ShiftOperatorUInts) {
-  s << std::numeric_limits::max() << " ";
-  s << std::numeric_limits::max() << " ";
-  s << std::numeric_limits::max() << " ";
-  s << std::numeric_limits::max();
-  EXPECT_EQ(33U, s.GetWrittenBytes());
-  EXPECT_EQ("ff   ", TakeValue());
-}
-
 TEST_F(StreamTest, ShiftOperatorPtr) {
   // This test is a bit tricky because pretty much everything related to
   // pointer printing seems to lead to UB or IB. So let's make the most basic
Index: lldb/test/Shell/SymbolFile/DWARF/array-sizes.s
===
--- lldb/test/Shell/SymbolFile/DWARF/array-sizes.s
+++ lldb/test/Shell/SymbolFile/DWARF/array-sizes.s
@@ -10,7 +10,7 @@
 # RUN: lldb-test symbols %t | FileCheck %s
 
 # CHECK: Variable{0x7fff001e}, name = "X"
-# CHECK-SAME: type = {7fff0033} 0x{{[0-9a-f]*}} (char [56])
+# CHECK-SAME: type = {7fff0033} 0x{{[0-9A-F]*}} (char [56])
 
 
 # Generated from "char X[47];"
Index: lldb/source/Utility/Stream.cpp
===
--- lldb/source/Utility/Stream.cpp
+++ lldb/source/Utility/Stream.cpp
@@ -160,30 +160,6 @@
   return *this;
 }
 
-// Stream a uint8_t "uval" out to this stream.
-Stream &Stream::operator<<(uint8_t uval) {
-  PutHex8(uval);
-  return *this;
-}
-
-// Stream a uint16_t "uval" out to this stream.
-Stream &Stream::operator<<(uint16_t uval) {
-  PutHex16(uval, m_byte_order);
-  return *this;
-}
-
-// Stream a uint32_t "uval" out to this stream.
-Stream &Stream::operator<<(uint32_t uval) {
-  PutHex32(uval, m_byte_order);
-  return *this;
-}
-
-// Stream a uint64_t "uval" out to this stream.
-Stream &Stream::operator<<(uint64_t uval) {
-  PutHex64(uval, m_byte_order);
-  return *this;
-}
-
 // Stream a int8_t "sval" out to this stream.
 Stream &Stream::operator<<(int8_t sval) {
   Printf("%i", static_cast(sval));
Index: lldb/source/Symbol/Variable.cpp
===
--- lldb/source/Symbol/Variable.cpp
+++ lldb/source/Symbol/Variable.cpp
@@ -112,7 +112,7 @@
   if (m_symfile_type_sp) {
 Type *type = m_symfile_type_sp->GetType();
 if (type) {
-  *s << ", type = {" << type->GetID() << "} " << (void *)type << " (";
+  s->Format(", type = {{{0:x-16}} {1} (", type->GetID(), type);
   type->DumpTypeName(s);
   s->PutChar(')');
 }
Index: lldb/source/Symbol/Type.cpp
===
--- lldb/source/Symbol/Type.cpp
+++ lldb/source/Symbol/Type.cpp
@@ -256,7 +256,7 @@
 *s << ", compiler_type = " << m_compiler_type.GetOpaqueQualType() << ' ';
 GetForwardCompilerType().DumpTypeDescription(s);
   } else if (m_encoding_uid != LLDB_INVALID_UID) {
-*s << ", type_data = " << (uint64_t)m_encoding_uid;
+s->Format(", type_data = {0:x-16}", m_encoding_uid);
 switch (m_encoding_uid_type) {
 case eEncodingInvalid:
   break;
Index: lldb/source/Symbol/SymbolContext.cpp
===
--- lldb/source/Symbol/SymbolContext.cpp
+++ lldb/source/Symbol/SymbolContext.cpp
@@ -315,14 +315,14 @@
   s->Indent();
   *s << "CompileUnit  = " << comp_unit;
   if (comp_unit != nullptr)
-*s << " {0x" << comp_unit->GetID() << "} "
-   << *(static_cast(comp_unit));
+s->

[Lldb-commits] [lldb] 6e3ecd1 - [lldb] Fix dwo variant of TestLibCxxFunction

2019-11-14 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2019-11-14T16:29:36+01:00
New Revision: 6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339

URL: 
https://github.com/llvm/llvm-project/commit/6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339
DIFF: 
https://github.com/llvm/llvm-project/commit/6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339.diff

LOG: [lldb] Fix dwo variant of TestLibCxxFunction

The test was failing due to a bug in SymbolFileDWARF::FindFunctions --
the function was searching the main dwarf unit for DW_TAG_subprograms,
but the main unit is empty in case of split dwarf.  The fix is simple --
search the non-skeleton unit instead.

This bug went unnoticed because this function is expensive, and so one
generally avoids calling it.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index c0c10b21a747..10296527a114 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -839,7 +839,8 @@ size_t SymbolFileDWARF::ParseFunctions(CompileUnit 
&comp_unit) {
 
   size_t functions_added = 0;
   std::vector function_dies;
-  dwarf_cu->AppendDIEsWithTag(DW_TAG_subprogram, function_dies);
+  dwarf_cu->GetNonSkeletonUnit().AppendDIEsWithTag(DW_TAG_subprogram,
+function_dies);
   for (const DWARFDIE &die : function_dies) {
 if (comp_unit.FindFunctionByUID(die.GetID()))
   continue;



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


[Lldb-commits] [PATCH] D68179: [lldb] Fix JSON parser to allow empty arrays

2019-11-14 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

In D68179#1745614 , @tetsuo-cpp wrote:

> Thanks for looking at this. I will need someone to commit it for me.
>  However, I've been having issues with the test suite on my MacBook. 
> `check-lldb-unit` works for me but `check-llvm` and `check-lldb` are hitting 
> issues because of something wrong with my environment. So I'll need to sort 
> this out first to verify that I haven't broken anything before it's 
> committed. I'm hoping to spend some time this weekend to debug my setup.


Once this is approved, I can run the tests for you to make sure it didn't 
regress [I do that regardless before committing].
That said, it would be good if you got your environment set up correctly [if 
there's something you don't understand, feel free to reach out on `llvm-dev` or 
`lldb-dev`, depending on the question].


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

https://reviews.llvm.org/D68179



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


[Lldb-commits] [lldb] 0e45e60 - Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

2019-11-14 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-14T08:58:31-08:00
New Revision: 0e45e60c6f316d095d878aea3c098202b39b5bee

URL: 
https://github.com/llvm/llvm-project/commit/0e45e60c6f316d095d878aea3c098202b39b5bee
DIFF: 
https://github.com/llvm/llvm-project/commit/0e45e60c6f316d095d878aea3c098202b39b5bee.diff

LOG: Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that
ForEachExternalModule also had the problem of visiting the same leaf
node an exponential number of times in the worst-case. This adds a set
of searched_symbol_files set to the function as well as the ability to
early-exit from it.

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

Added: 


Modified: 
lldb/include/lldb/Symbol/CompileUnit.h
lldb/include/lldb/Symbol/SymbolFile.h
lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
lldb/source/Symbol/CompileUnit.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/CompileUnit.h 
b/lldb/include/lldb/Symbol/CompileUnit.h
index b206e6fde9ee..7efbf792b1a9 100644
--- a/lldb/include/lldb/Symbol/CompileUnit.h
+++ b/lldb/include/lldb/Symbol/CompileUnit.h
@@ -19,6 +19,7 @@
 #include "lldb/lldb-enumerations.h"
 
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/DenseSet.h"
 
 namespace lldb_private {
 /// \class CompileUnit CompileUnit.h "lldb/Symbol/CompileUnit.h"
@@ -241,9 +242,20 @@ class CompileUnit : public 
std::enable_shared_from_this,
   /// compilation unit. Recursively also descends into the referenced external
   /// modules of any encountered compilation unit.
   ///
-  /// \param[in] f
-  /// The lambda that should be applied to every module.
-  void ForEachExternalModule(llvm::function_ref f);
+  /// \param visited_symbol_files
+  /// A set of SymbolFiles that were already visited to avoid
+  /// visiting one file more than once.
+  ///
+  /// \param[in] lambda
+  /// The lambda that should be applied to every function. The lambda can
+  /// return true if the iteration should be aborted earlier.
+  ///
+  /// \return
+  /// If the lambda early-exited, this function returns true to
+  /// propagate the early exit.
+  virtual bool ForEachExternalModule(
+  llvm::DenseSet &visited_symbol_files,
+  llvm::function_ref lambda);
 
   /// Get the compile unit's support file list.
   ///

diff  --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index 3c52766f39d3..9c5e46b01634 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -122,9 +122,35 @@ class SymbolFile : public PluginInterface {
   virtual size_t ParseFunctions(CompileUnit &comp_unit) = 0;
   virtual bool ParseLineTable(CompileUnit &comp_unit) = 0;
   virtual bool ParseDebugMacros(CompileUnit &comp_unit) = 0;
-  virtual void
-  ForEachExternalModule(CompileUnit &comp_unit,
-llvm::function_ref f) {}
+
+  /// Apply a lambda to each external lldb::Module referenced by this
+  /// \p comp_unit. Recursively also descends into the referenced external
+  /// modules of any encountered compilation unit.
+  ///
+  /// \param comp_unit
+  /// When this SymbolFile consists of multiple auxilliary
+  /// SymbolFiles, for example, a Darwin debug map that references
+  /// multiple .o files, comp_unit helps choose the auxilliary
+  /// file. In most other cases comp_unit's symbol file is
+  /// identiacal with *this.
+  ///
+  /// \param[in] lambda
+  /// The lambda that should be applied to every function. The lambda can
+  /// return true if the iteration should be aborted earlier.
+  ///
+  /// \param visited_symbol_files
+  /// A set of SymbolFiles that were already visited to avoid
+  /// visiting one file more than once.
+  ///
+  /// \return
+  /// If the lambda early-exited, this function returns true to
+  /// propagate the early exit.
+  virtual bool ForEachExternalModule(
+  lldb_private::CompileUnit &comp_unit,
+  llvm::DenseSet &visited_symbol_files,
+  llvm::function_ref lambda) {
+return false;
+  }
   virtual bool ParseSupportFiles(CompileUnit &comp_unit,
  FileSpecList &support_files) = 0;
   virtual size_t ParseTypes(CompileUnit &comp_unit) = 0;

diff  --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp 
b/lldb/source/Plugins/ExpressionParser/Clan

[Lldb-commits] [PATCH] D70215: Use ForEachExternalModule in ParseTypeFromClangModule (NFC)

2019-11-14 Thread Adrian Prantl via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
aprantl marked an inline comment as done.
Closed by commit rG0e45e60c6f31: Use ForEachExternalModule in 
ParseTypeFromClangModule (NFC) (authored by aprantl).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D70215?vs=229209&id=229324#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70215

Files:
  lldb/include/lldb/Symbol/CompileUnit.h
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  lldb/source/Symbol/CompileUnit.cpp

Index: lldb/source/Symbol/CompileUnit.cpp
===
--- lldb/source/Symbol/CompileUnit.cpp
+++ lldb/source/Symbol/CompileUnit.cpp
@@ -379,9 +379,12 @@
   return m_imported_modules;
 }
 
-void CompileUnit::ForEachExternalModule(llvm::function_ref f) {
+bool CompileUnit::ForEachExternalModule(
+llvm::DenseSet &visited_symbol_files,
+llvm::function_ref lambda) {
   if (SymbolFile *symfile = GetModule()->GetSymbolFile())
-symfile->ForEachExternalModule(*this, f);
+return symfile->ForEachExternalModule(*this, visited_symbol_files, lambda);
+  return false;
 }
 
 const FileSpecList &CompileUnit::GetSupportFiles() {
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
@@ -53,9 +53,9 @@
 
   bool ParseDebugMacros(lldb_private::CompileUnit &comp_unit) override;
 
-  void
-  ForEachExternalModule(lldb_private::CompileUnit &comp_unit,
-llvm::function_ref f) override;
+  bool ForEachExternalModule(
+  lldb_private::CompileUnit &, llvm::DenseSet &,
+  llvm::function_ref) override;
 
   bool ParseSupportFiles(lldb_private::CompileUnit &comp_unit,
  lldb_private::FileSpecList &support_files) override;
@@ -114,6 +114,11 @@
 uint32_t max_matches,
 llvm::DenseSet &searched_symbol_files,
 lldb_private::TypeMap &types) override;
+  void
+  FindTypes(llvm::ArrayRef context,
+lldb_private::LanguageSet languages,
+llvm::DenseSet &searched_symbol_files,
+lldb_private::TypeMap &types) override;
   lldb_private::CompilerDeclContext FindNamespace(
   lldb_private::ConstString name,
   const lldb_private::CompilerDeclContext *parent_decl_ctx) override;
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -652,12 +652,15 @@
   return false;
 }
 
-void SymbolFileDWARFDebugMap::ForEachExternalModule(
-CompileUnit &comp_unit, llvm::function_ref f) {
+bool SymbolFileDWARFDebugMap::ForEachExternalModule(
+CompileUnit &comp_unit,
+llvm::DenseSet &visited_symbol_files,
+llvm::function_ref f) {
   std::lock_guard guard(GetModuleMutex());
   SymbolFileDWARF *oso_dwarf = GetSymbolFile(comp_unit);
   if (oso_dwarf)
-oso_dwarf->ForEachExternalModule(comp_unit, f);
+return oso_dwarf->ForEachExternalModule(comp_unit, visited_symbol_files, f);
+  return false;
 }
 
 bool SymbolFileDWARFDebugMap::ParseSupportFiles(CompileUnit &comp_unit,
@@ -1183,6 +1186,16 @@
   });
 }
 
+void SymbolFileDWARFDebugMap::FindTypes(
+llvm::ArrayRef context, LanguageSet languages,
+llvm::DenseSet &searched_symbol_files,
+TypeMap &types) {
+  ForEachSymbolFile([&](SymbolFileDWARF *oso_dwarf) -> bool {
+oso_dwarf->FindTypes(context, languages, searched_symbol_files, types);
+return false;
+  });
+}
+
 //
 // uint32_t
 // SymbolFileDWARFDebugMap::FindTypes (const SymbolContext& sc, const
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -105,9 +105,9 @@
 
   bool ParseDebugMacros(lldb_private::CompileUnit &comp_unit) override;
 
-  void
-  ForEachExternalModule(lldb_private::CompileUnit &comp_unit,
-llvm::function_ref f) override;
+  bool ForEachExternalModule(
+  lldb_private::CompileUnit &, llvm::DenseSet &,
+  llvm::functi

[Lldb-commits] [lldb] 4229f70 - [LLDB] Make a clear distinction between usage & development docs

2019-11-14 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2019-11-14T09:04:28-08:00
New Revision: 4229f70d226b381ca82b49c7f66d7e33b73be9fd

URL: 
https://github.com/llvm/llvm-project/commit/4229f70d226b381ca82b49c7f66d7e33b73be9fd
DIFF: 
https://github.com/llvm/llvm-project/commit/4229f70d226b381ca82b49c7f66d7e33b73be9fd.diff

LOG: [LLDB] Make a clear distinction between usage & development docs

This renames the "Goals & Status" section to "Project" and the
"Resources" section to "Development". To better match this layout I've
moved the releases page under "Project".

Added: 
lldb/docs/status/releases.rst

Modified: 
lldb/docs/.htaccess
lldb/docs/index.rst

Removed: 
lldb/docs/resources/download.rst



diff  --git a/lldb/docs/.htaccess b/lldb/docs/.htaccess
index cc92b0a65cfa..d605f68afcf4 100644
--- a/lldb/docs/.htaccess
+++ b/lldb/docs/.htaccess
@@ -10,4 +10,6 @@ Redirect 301 /source.html 
https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /tutorial.html https://lldb.llvm.org/use/tutorial.html
 Redirect 301 /varformats.html https://lldb.llvm.org/use/variable.html
 
+# Sphinx redirects
 Redirect 301 /resources/source.html 
https://lldb.llvm.org/resources/contributing.html
+Redirect 301 /resources/download.html 
https://lldb.llvm.org/status/releases.html

diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index b833821554b1..1f7fe58a525e 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -109,12 +109,13 @@ interesting areas to contribute to lldb.
 .. toctree::
:hidden:
:maxdepth: 1
-   :caption: Goals & Status
+   :caption: Project
 
status/goals
status/features
status/status
status/projects
+   status/releases
 
 .. toctree::
:hidden:
@@ -136,14 +137,13 @@ interesting areas to contribute to lldb.
 .. toctree::
:hidden:
:maxdepth: 1
-   :caption: Resources
+   :caption: Development
 
resources/contributing
resources/build
resources/test
resources/bots
resources/sbapi
-   resources/download
 
 .. toctree::
:hidden:

diff  --git a/lldb/docs/resources/download.rst b/lldb/docs/status/releases.rst
similarity index 100%
rename from lldb/docs/resources/download.rst
rename to lldb/docs/status/releases.rst



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


[Lldb-commits] [lldb] 83f5287 - Rename DWO -> Clang module to avoid confusion. (NFC)

2019-11-14 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-14T09:13:49-08:00
New Revision: 83f5287567bcdf1b5de244229fba4e552b7d0054

URL: 
https://github.com/llvm/llvm-project/commit/83f5287567bcdf1b5de244229fba4e552b7d0054
DIFF: 
https://github.com/llvm/llvm-project/commit/83f5287567bcdf1b5de244229fba4e552b7d0054.diff

LOG: Rename DWO -> Clang module to avoid confusion. (NFC)

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 7d1803fc7b9d..30572974fe92 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -171,8 +171,8 @@ static lldb::ModuleSP GetContainingClangModule(const 
DWARFDIE &die) {
 TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const SymbolContext &sc,
  const DWARFDIE &die,
  Log *log) {
-  ModuleSP dwo_module_sp = GetContainingClangModule(die);
-  if (!dwo_module_sp)
+  ModuleSP clang_module_sp = GetContainingClangModule(die);
+  if (!clang_module_sp)
 return TypeSP();
 
   // If this type comes from a Clang module, recursively look in the
@@ -186,7 +186,7 @@ TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const 
SymbolContext &sc,
   LanguageSet languages;
   languages.Insert(die.GetCU()->GetLanguageType());
   llvm::DenseSet searched_symbol_files;
-  dwo_module_sp->GetSymbolFile()->FindTypes(decl_context, languages,
+  clang_module_sp->GetSymbolFile()->FindTypes(decl_context, languages,
 searched_symbol_files, pcm_types);
   if (pcm_types.Empty()) {
 // Since this type is defined in one of the Clang modules imported
@@ -468,32 +468,36 @@ TypeSP DWARFASTParserClang::ParseTypeFromDWARF(const 
SymbolContext &sc,
   case DW_TAG_volatile_type:
   case DW_TAG_unspecified_type: {
 if (tag == DW_TAG_typedef && attrs.type.IsValid()) {
-  // Try to parse a typedef from the DWO file first as modules can
-  // contain typedef'ed structures that have no names like:
+  // Try to parse a typedef from the (DWARF embedded in the) Clang
+  // module file first as modules can contain typedef'ed
+  // structures that have no names like:
   //
   //  typedef struct { int a; } Foo;
   //
-  // In this case we will have a structure with no name and a typedef
-  // named "Foo" that points to this unnamed structure. The name in the
-  // typedef is the only identifier for the struct, so always try to
-  // get typedefs from DWO files if possible.
+  // In this case we will have a structure with no name and a
+  // typedef named "Foo" that points to this unnamed
+  // structure. The name in the typedef is the only identifier for
+  // the struct, so always try to get typedefs from Clang modules
+  // if possible.
   //
-  // The type_sp returned will be empty if the typedef doesn't exist in
-  // a DWO file, so it is cheap to call this function just to check.
+  // The type_sp returned will be empty if the typedef doesn't
+  // exist in a module file, so it is cheap to call this function
+  // just to check.
   //
-  // If we don't do this we end up creating a TypeSP that says this is
-  // a typedef to type 0x123 (the DW_AT_type value would be 0x123 in
-  // the DW_TAG_typedef), and this is the unnamed structure type. We
-  // will have a hard time tracking down an unnammed structure type in
-  // the module DWO file, so we make sure we don't get into this
-  // situation by always resolving typedefs from the DWO file.
+  // If we don't do this we end up creating a TypeSP that says
+  // this is a typedef to type 0x123 (the DW_AT_type value would
+  // be 0x123 in the DW_TAG_typedef), and this is the unnamed
+  // structure type. We will have a hard time tracking down an
+  // unnammed structure type in the module debug info, so we make
+  // sure we don't get into this situation by always resolving
+  // typedefs from the module.
   const DWARFDIE encoding_die = attrs.type.Reference();
 
-  // First make sure that the die that this is typedef'ed to _is_ just
-  // a declaration (DW_AT_declaration == 1), not a full definition
-  // since template types can't be represented in modules since only
-  // concrete instances of templates are ever emitted and modules won't
-  // contain those
+  // First make sure that the die that this is typedef'ed to _is_
+  // just a declaration (DW_AT_declaration == 1), not a full
+  // definition since template types can't be represented in
+  // modules since only concrete instances o

[Lldb-commits] [PATCH] D70241: [lldb] remove unsigned Stream::operator<< overloads

2019-11-14 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

🥳


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70241



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


[Lldb-commits] [lldb] 0352007 - Convert UpdateExternalModuleListIfNeeded to use early exits.

2019-11-14 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-14T09:35:06-08:00
New Revision: 0352007fdb3f6ae1eaedbff53e018ad1e364720e

URL: 
https://github.com/llvm/llvm-project/commit/0352007fdb3f6ae1eaedbff53e018ad1e364720e
DIFF: 
https://github.com/llvm/llvm-project/commit/0352007fdb3f6ae1eaedbff53e018ad1e364720e.diff

LOG: Convert UpdateExternalModuleListIfNeeded to use early exits.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 0a2ce5a817a4..4d4a0d8b7bc9 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1618,72 +1618,72 @@ void 
SymbolFileDWARF::UpdateExternalModuleListIfNeeded() {
 
   DWARFDebugInfo *debug_info = DebugInfo();
 
+  // Follow DWO skeleton unit breadcrumbs.
   const uint32_t num_compile_units = GetNumCompileUnits();
   for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx) {
 DWARFUnit *dwarf_cu = debug_info->GetUnitAtIndex(cu_idx);
-
 const DWARFBaseDIE die = dwarf_cu->GetUnitDIEOnly();
-if (die && !die.HasChildren()) {
-  const char *name = die.GetAttributeValueAsString(DW_AT_name, nullptr);
-
-  if (name) {
-ConstString const_name(name);
-if (m_external_type_modules.find(const_name) ==
-m_external_type_modules.end()) {
-  ModuleSP module_sp;
-  const char *dwo_path =
-  die.GetAttributeValueAsString(DW_AT_GNU_dwo_name, nullptr);
-  if (dwo_path) {
-ModuleSpec dwo_module_spec;
-dwo_module_spec.GetFileSpec().SetFile(dwo_path,
-  FileSpec::Style::native);
-if (dwo_module_spec.GetFileSpec().IsRelative()) {
-  const char *comp_dir =
-  die.GetAttributeValueAsString(DW_AT_comp_dir, nullptr);
-  if (comp_dir) {
-dwo_module_spec.GetFileSpec().SetFile(comp_dir,
-  FileSpec::Style::native);
-FileSystem::Instance().Resolve(dwo_module_spec.GetFileSpec());
-dwo_module_spec.GetFileSpec().AppendPathComponent(dwo_path);
-  }
-}
-dwo_module_spec.GetArchitecture() =
-m_objfile_sp->GetModule()->GetArchitecture();
-
-// When LLDB loads "external" modules it looks at the presence of
-// DW_AT_GNU_dwo_name. However, when the already created module
-// (corresponding to .dwo itself) is being processed, it will see
-// the presence of DW_AT_GNU_dwo_name (which contains the name of
-// dwo file) and will try to call ModuleList::GetSharedModule
-// again. In some cases (i.e. for empty files) Clang 4.0 generates
-// a *.dwo file which has DW_AT_GNU_dwo_name, but no
-// DW_AT_comp_dir. In this case the method
-// ModuleList::GetSharedModule will fail and the warning will be
-// printed. However, as one can notice in this case we don't
-// actually need to try to load the already loaded module
-// (corresponding to .dwo) so we simply skip it.
-if (m_objfile_sp->GetFileSpec().GetFileNameExtension() == ".dwo" &&
-llvm::StringRef(m_objfile_sp->GetFileSpec().GetPath())
-.endswith(dwo_module_spec.GetFileSpec().GetPath())) {
-  continue;
-}
+if (!die || die.HasChildren())
+  continue;
 
-Status error = ModuleList::GetSharedModule(
-dwo_module_spec, module_sp, nullptr, nullptr, nullptr);
-if (!module_sp) {
-  GetObjectFile()->GetModule()->ReportWarning(
-  "0x%8.8x: unable to locate module needed for external types: 
"
-  "%s\nerror: %s\nDebugging will be degraded due to missing "
-  "types. Rebuilding your project will regenerate the needed "
-  "module files.",
-  die.GetOffset(),
-  dwo_module_spec.GetFileSpec().GetPath().c_str(),
-  error.AsCString("unknown error"));
-}
-  }
-  m_external_type_modules[const_name] = module_sp;
+const char *name = die.GetAttributeValueAsString(DW_AT_name, nullptr);
+if (!name)
+  continue;
+
+ConstString const_name(name);
+ModuleSP &module_sp = m_external_type_modules[const_name];
+if (module_sp)
+  continue;
+
+const char *dwo_path =
+die.GetAttributeValueAsString(DW_AT_GNU_dwo_name, nullptr);
+if (!dwo_path)
+  dwo_path = die.GetAttributeValueAsString(DW_AT_dwo_name, nullptr);
+if (dwo_path) {
+  ModuleSpec dwo_module_spec;

[Lldb-commits] [lldb] 268e11f - Convert condition to early exit (NFC)

2019-11-14 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-14T09:38:49-08:00
New Revision: 268e11f95d331a6268f08bf94ce86d04efbb7baa

URL: 
https://github.com/llvm/llvm-project/commit/268e11f95d331a6268f08bf94ce86d04efbb7baa
DIFF: 
https://github.com/llvm/llvm-project/commit/268e11f95d331a6268f08bf94ce86d04efbb7baa.diff

LOG: Convert condition to early exit (NFC)

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 4d4a0d8b7bc9..727334f3717b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1639,52 +1639,54 @@ void 
SymbolFileDWARF::UpdateExternalModuleListIfNeeded() {
 die.GetAttributeValueAsString(DW_AT_GNU_dwo_name, nullptr);
 if (!dwo_path)
   dwo_path = die.GetAttributeValueAsString(DW_AT_dwo_name, nullptr);
-if (dwo_path) {
-  ModuleSpec dwo_module_spec;
-  dwo_module_spec.GetFileSpec().SetFile(dwo_path, FileSpec::Style::native);
-  if (dwo_module_spec.GetFileSpec().IsRelative()) {
-const char *comp_dir =
-die.GetAttributeValueAsString(DW_AT_comp_dir, nullptr);
-if (comp_dir) {
-  dwo_module_spec.GetFileSpec().SetFile(comp_dir,
-FileSpec::Style::native);
-  FileSystem::Instance().Resolve(dwo_module_spec.GetFileSpec());
-  dwo_module_spec.GetFileSpec().AppendPathComponent(dwo_path);
-}
-  }
-  dwo_module_spec.GetArchitecture() =
-  m_objfile_sp->GetModule()->GetArchitecture();
-
-  // When LLDB loads "external" modules it looks at the presence
-  // of DW_AT_dwo_name. However, when the already created module
-  // (corresponding to .dwo itself) is being processed, it will
-  // see the presence of DW_AT_dwo_name (which contains the name
-  // of dwo file) and will try to call ModuleList::GetSharedModule
-  // again. In some cases (i.e., for empty files) Clang 4.0
-  // generates a *.dwo file which has DW_AT_dwo_name, but no
-  // DW_AT_comp_dir. In this case the method
-  // ModuleList::GetSharedModule will fail and the warning will be
-  // printed. However, as one can notice in this case we don't
-  // actually need to try to load the already loaded module
-  // (corresponding to .dwo) so we simply skip it.
-  if (m_objfile_sp->GetFileSpec().GetFileNameExtension() == ".dwo" &&
-  llvm::StringRef(m_objfile_sp->GetFileSpec().GetPath())
-  .endswith(dwo_module_spec.GetFileSpec().GetPath())) {
-continue;
-  }
+if (!dwo_path)
+  continue;
 
-  Status error = ModuleList::GetSharedModule(dwo_module_spec, module_sp,
- nullptr, nullptr, nullptr);
-  if (!module_sp) {
-GetObjectFile()->GetModule()->ReportWarning(
-"0x%8.8x: unable to locate module needed for external types: "
-"%s\nerror: %s\nDebugging will be degraded due to missing "
-"types. Rebuilding your project will regenerate the needed "
-"module files.",
-die.GetOffset(), dwo_module_spec.GetFileSpec().GetPath().c_str(),
-error.AsCString("unknown error"));
+ModuleSpec dwo_module_spec;
+dwo_module_spec.GetFileSpec().SetFile(dwo_path, FileSpec::Style::native);
+if (dwo_module_spec.GetFileSpec().IsRelative()) {
+  const char *comp_dir =
+  die.GetAttributeValueAsString(DW_AT_comp_dir, nullptr);
+  if (comp_dir) {
+dwo_module_spec.GetFileSpec().SetFile(comp_dir,
+  FileSpec::Style::native);
+FileSystem::Instance().Resolve(dwo_module_spec.GetFileSpec());
+dwo_module_spec.GetFileSpec().AppendPathComponent(dwo_path);
   }
 }
+dwo_module_spec.GetArchitecture() =
+m_objfile_sp->GetModule()->GetArchitecture();
+
+// When LLDB loads "external" modules it looks at the presence of
+// DW_AT_dwo_name. However, when the already created module
+// (corresponding to .dwo itself) is being processed, it will see
+// the presence of DW_AT_dwo_name (which contains the name of dwo
+// file) and will try to call ModuleList::GetSharedModule
+// again. In some cases (i.e., for empty files) Clang 4.0
+// generates a *.dwo file which has DW_AT_dwo_name, but no
+// DW_AT_comp_dir. In this case the method
+// ModuleList::GetSharedModule will fail and the warning will be
+// printed. However, as one can notice in this case we don't
+// actually need to try to load the already loaded module
+// (corresponding to .dwo) so we simply skip it.
+if (m_objfile_sp->GetFileSpec().GetFileNameExtension() == ".dwo" &&
+   

[Lldb-commits] [lldb] dcb5bd9 - Fix incorrect comment.

2019-11-14 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2019-11-14T09:55:24-08:00
New Revision: dcb5bd91095fc2a009a777e4d7eefb127f057634

URL: 
https://github.com/llvm/llvm-project/commit/dcb5bd91095fc2a009a777e4d7eefb127f057634
DIFF: 
https://github.com/llvm/llvm-project/commit/dcb5bd91095fc2a009a777e4d7eefb127f057634.diff

LOG: Fix incorrect comment.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 727334f3717b..b61355376bf4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1556,9 +1556,11 @@ SymbolFileDWARF::GetDIE(const DIERef &die_ref) {
 std::unique_ptr
 SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(
 DWARFUnit &unit, const DWARFDebugInfoEntry &cu_die) {
-  // If we are using a dSYM file, we never want the standard DWO files since
-  // the -gmodules support uses the same DWO machanism to specify full debug
-  // info files for modules.
+  // If this is a Darwin-style debug map (non-.dSYM) symbol file,
+  // never attempt to load ELF-style DWO files since the -gmodules
+  // support uses the same DWO machanism to specify full debug info
+  // files for modules. This is handled in
+  // UpdateExternalModuleListIfNeeded().
   if (GetDebugMapSymfile())
 return nullptr;
 



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


Re: [Lldb-commits] [lldb] 6e3ecd1 - [lldb] Fix dwo variant of TestLibCxxFunction

2019-11-14 Thread Shafik Yaghmour via lldb-commits
Pavel,

Thank you for fixing this! 

> On Nov 14, 2019, at 7:30 AM, Pavel Labath via lldb-commits 
>  wrote:
> 
> 
> Author: Pavel Labath
> Date: 2019-11-14T16:29:36+01:00
> New Revision: 6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339
> DIFF: 
> https://github.com/llvm/llvm-project/commit/6e3ecd18847cb5c5bbe41d23428e1aa57ed1b339.diff
> 
> LOG: [lldb] Fix dwo variant of TestLibCxxFunction
> 
> The test was failing due to a bug in SymbolFileDWARF::FindFunctions --
> the function was searching the main dwarf unit for DW_TAG_subprograms,
> but the main unit is empty in case of split dwarf.  The fix is simple --
> search the non-skeleton unit instead.
> 
> This bug went unnoticed because this function is expensive, and so one
> generally avoids calling it.
> 
> Added: 
> 
> 
> Modified: 
>lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
> b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> index c0c10b21a747..10296527a114 100644
> --- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> +++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
> @@ -839,7 +839,8 @@ size_t SymbolFileDWARF::ParseFunctions(CompileUnit 
> &comp_unit) {
> 
>   size_t functions_added = 0;
>   std::vector function_dies;
> -  dwarf_cu->AppendDIEsWithTag(DW_TAG_subprogram, function_dies);
> +  dwarf_cu->GetNonSkeletonUnit().AppendDIEsWithTag(DW_TAG_subprogram,
> +function_dies);
>   for (const DWARFDIE &die : function_dies) {
> if (comp_unit.FindFunctionByUID(die.GetID()))
>   continue;
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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


[Lldb-commits] [PATCH] D70252: [Docs] Add Python caveats under the development section

2019-11-14 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: labath, aadsm, davide.
JDevlieghere added a project: LLDB.
Herald added subscribers: abidh, arphaman.

This adds a page named Caveats with a section on some of the things to be aware 
of related to Python. It's a question we've seen more than once pop up and I 
think it's good to have it documentation on the website. Even though some of it 
might be useful to users, I still put it under "development" because it 
requires some understanding of how LLDB is built.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D70252

Files:
  lldb/docs/index.rst
  lldb/docs/resources/caveats.rst


Index: lldb/docs/resources/caveats.rst
===
--- /dev/null
+++ lldb/docs/resources/caveats.rst
@@ -0,0 +1,34 @@
+Caveats
+===
+
+.. contents::
+   :local:
+
+Python
+--
+
+LLDB has a powerful scripting interface which is accessible through Python.
+Python is available either from withing LLDB through a (interactive) script
+interpreter, or as a Python module which you can import from the Python
+interpreter.
+
+To make this possible, LLDB links against the Python shared library. Linking
+against Python comes with some constraints to be aware of.
+
+1.  It is not possible to build and link LLDB against a Python 3 library and
+use it from Python 2 and vice versa.
+
+2.  It is not possible to build and link LLDB against one distribution on
+Python and use it through a interpreter coming from another distribution.
+For example, on macOS, if you build and link against Python from
+python.org, you cannot import the lldb module from the Python interpreter
+installed with Homebrew.
+
+3.  To use third party Python packages from inside LLDB, you need to install
+them using a utility (such as ``pip``) from the same Python distribution as
+the one used to build and link LLDB.
+
+The previous considerations are especially important during development, but
+apply to binary distributions of LLDB as well. For example, the LLDB that comes
+with Xcode links against the Python that's part of Xcode. You should always use
+the system's Python interpreter to import the lldb module or install packages.
Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -144,6 +144,7 @@
resources/test
resources/bots
resources/sbapi
+   resources/caveats
 
 .. toctree::
:hidden:


Index: lldb/docs/resources/caveats.rst
===
--- /dev/null
+++ lldb/docs/resources/caveats.rst
@@ -0,0 +1,34 @@
+Caveats
+===
+
+.. contents::
+   :local:
+
+Python
+--
+
+LLDB has a powerful scripting interface which is accessible through Python.
+Python is available either from withing LLDB through a (interactive) script
+interpreter, or as a Python module which you can import from the Python
+interpreter.
+
+To make this possible, LLDB links against the Python shared library. Linking
+against Python comes with some constraints to be aware of.
+
+1.  It is not possible to build and link LLDB against a Python 3 library and
+use it from Python 2 and vice versa.
+
+2.  It is not possible to build and link LLDB against one distribution on
+Python and use it through a interpreter coming from another distribution.
+For example, on macOS, if you build and link against Python from
+python.org, you cannot import the lldb module from the Python interpreter
+installed with Homebrew.
+
+3.  To use third party Python packages from inside LLDB, you need to install
+them using a utility (such as ``pip``) from the same Python distribution as
+the one used to build and link LLDB.
+
+The previous considerations are especially important during development, but
+apply to binary distributions of LLDB as well. For example, the LLDB that comes
+with Xcode links against the Python that's part of Xcode. You should always use
+the system's Python interpreter to import the lldb module or install packages.
Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -144,6 +144,7 @@
resources/test
resources/bots
resources/sbapi
+   resources/caveats
 
 .. toctree::
:hidden:
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D70137: [lldb][Editline] Support ctrl+left/right arrow word navigation.

2019-11-14 Thread Jordan Rupprecht via Phabricator via lldb-commits
rupprecht updated this revision to Diff 229349.
rupprecht marked an inline comment as done.
rupprecht added a comment.

- Fix test comment
- Use `expect` helper from lldbpexpect


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70137

Files:
  lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
  lldb/source/Host/common/Editline.cpp


Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -1105,6 +1105,15 @@
   el_set(m_editline, EL_BIND, "\t", "lldb-complete",
  NULL); // Bind TAB to auto complete
 
+  // Allow ctrl-left-arrow and ctrl-right-arrow for navigation, behave like
+  // bash in emacs mode.
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[D", "ed-prev-word", NULL);
+
   // Allow user-specific customization prior to registering bindings we
   // absolutely require
   el_source(m_editline, nullptr);
Index: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
@@ -0,0 +1,49 @@
+"""
+Test that the lldb editline handling is configured correctly.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+
+class EditlineTest(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_left_right_arrow(self):
+"""Test that ctrl+left/right arrow navigates words correctly.
+
+Note: just sending escape characters to pexpect and checking the buffer
+doesn't work well, so we run real commands. We want to type
+"help command" while exercising word-navigation, so type it as below,
+where [] indicates cursor position.
+
+1. Send "el ommand" -> "el ommand[]"
+2. Ctrl+left once   -> "el []ommand"
+3. Send "c" -> "el c[]ommand"
+4. Ctrl+left twice  -> "[]el command"
+5. Send "h" -> "h[]el command"
+6. Ctrl+right   -> "hel[] command"
+7. Send "p" -> "help command"
+"""
+self.launch()
+
+# Run help for different commands for escape variants to make sure each
+# one matches uniquely (the buffer isn't cleared in between matches).
+cases = [
+("print", "\x1b[1;5D", "\x1b[1;5C"),
+("step", "\x1b[5D", "\x1b[5C"),
+("exit", "\x1b\x1b[D", "\x1b\x1b[C"),
+]
+for (cmd, l_escape, r_escape) in cases:
+self.expect("el {cmd_tail}{L}{cmd_head}{L}{L}h{R}p\n".format(
+cmd_head=cmd[0], cmd_tail=cmd[1:], L=l_escape, R=r_escape),
+substrs=["Syntax: %s" % cmd])
+
+self.quit()


Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -1105,6 +1105,15 @@
   el_set(m_editline, EL_BIND, "\t", "lldb-complete",
  NULL); // Bind TAB to auto complete
 
+  // Allow ctrl-left-arrow and ctrl-right-arrow for navigation, behave like
+  // bash in emacs mode.
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[D", "ed-prev-word", NULL);
+
   // Allow user-specific customization prior to registering bindings we
   // absolutely require
   el_source(m_editline, nullptr);
Index: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
@@ -0,0 +1,49 @@
+"""
+Test that the lldb editline handling is configured correctly.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+
+class EditlineTest(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+

[Lldb-commits] [PATCH] D70137: [lldb][Editline] Support ctrl+left/right arrow word navigation.

2019-11-14 Thread Jordan Rupprecht via Phabricator via lldb-commits
rupprecht marked an inline comment as done.
rupprecht added inline comments.



Comment at: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py:37-38
+
+# Run help for different commands for escape variants to make sure each
+# one matches uniquely (the buffer isn't cleared in between matches).
+cases = [

labath wrote:
> The buffer isn't exactly "cleared", but each "expect" command should only 
> match from the end of the previous match, so repeating the same command 
> should not be a problem. What the other (few) pexpect tests do is put an 
> `self.expect_prompt()` to ensure all output from the previous command is 
> ignored, and lldb is ready to receive a new command. You could do that too. 
> In fact, you could probably use the helper "expect" command which does all of 
> this for you:
> `self.expect("el ommand{L}c{L}{L}h{R}p".format(...), substrs=["Syntax: 
> command"])`
The expect helper is nice, thanks!

> but each "expect" command should only match from the end of the previous match
I am not able to reproduce that. If I change the expect to the static string 
`"Syntax: print"` (not `% cmd`), then the second case (which types `"help 
step"`) passes. Which implies it's checking the entire buffer.

The third case (`"help exit"`) fails because the buffer does not contain the 
`print` help text anymore. But that means this behavior is dependent on the 
relation between help text length and buffer size. For now, I'll leave this as 
separate help commands.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70137



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


[Lldb-commits] [PATCH] D70137: [lldb][Editline] Support ctrl+left/right arrow word navigation.

2019-11-14 Thread pre-merge checks [bot] via Phabricator via lldb-commits
merge_guards_bot added a comment.

Build result: pass - 60015 tests passed, 0 failed and 722 were skipped.
Log files: console-log.txt 
,
 CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70137



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


[Lldb-commits] [lldb] f2e6544 - [lldb][Editline] Support ctrl+left/right arrow word navigation.

2019-11-14 Thread Jordan Rupprecht via lldb-commits

Author: Jordan Rupprecht
Date: 2019-11-14T11:41:11-08:00
New Revision: f2e65447b3cb6340883957e033e77095a025ebdc

URL: 
https://github.com/llvm/llvm-project/commit/f2e65447b3cb6340883957e033e77095a025ebdc
DIFF: 
https://github.com/llvm/llvm-project/commit/f2e65447b3cb6340883957e033e77095a025ebdc.diff

LOG: [lldb][Editline] Support ctrl+left/right arrow word navigation.

Summary:
This adds several 5C/5D escape codes that allow moving forward/backward words 
similar to bash command line navigation.

On my terminal, `ctrl+v ctrl+` prints `^[[1;5D`. However, it seems 
inputrc also maps other escape variants of this to forward/backward word, so 
I've included those too. Similar for 5C = ctrl+right arrow.

Reviewers: JDevlieghere, labath

Reviewed By: JDevlieghere, labath

Subscribers: merge_guards_bot, lldb-commits

Tags: #lldb

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

Added: 
lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py

Modified: 
lldb/source/Host/common/Editline.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py 
b/lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
new file mode 100644
index ..49a46f2de539
--- /dev/null
+++ b/lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
@@ -0,0 +1,49 @@
+"""
+Test that the lldb editline handling is configured correctly.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+
+class EditlineTest(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_left_right_arrow(self):
+"""Test that ctrl+left/right arrow navigates words correctly.
+
+Note: just sending escape characters to pexpect and checking the buffer
+doesn't work well, so we run real commands. We want to type
+"help command" while exercising word-navigation, so type it as below,
+where [] indicates cursor position.
+
+1. Send "el ommand" -> "el ommand[]"
+2. Ctrl+left once   -> "el []ommand"
+3. Send "c" -> "el c[]ommand"
+4. Ctrl+left twice  -> "[]el command"
+5. Send "h" -> "h[]el command"
+6. Ctrl+right   -> "hel[] command"
+7. Send "p" -> "help command"
+"""
+self.launch()
+
+# Run help for 
diff erent commands for escape variants to make sure each
+# one matches uniquely (the buffer isn't cleared in between matches).
+cases = [
+("print", "\x1b[1;5D", "\x1b[1;5C"),
+("step", "\x1b[5D", "\x1b[5C"),
+("exit", "\x1b\x1b[D", "\x1b\x1b[C"),
+]
+for (cmd, l_escape, r_escape) in cases:
+self.expect("el {cmd_tail}{L}{cmd_head}{L}{L}h{R}p".format(
+cmd_head=cmd[0], cmd_tail=cmd[1:], L=l_escape, R=r_escape),
+substrs=["Syntax: %s" % cmd])
+
+self.quit()

diff  --git a/lldb/source/Host/common/Editline.cpp 
b/lldb/source/Host/common/Editline.cpp
index 3e655244b107..3ae837866faf 100644
--- a/lldb/source/Host/common/Editline.cpp
+++ b/lldb/source/Host/common/Editline.cpp
@@ -1105,6 +1105,15 @@ void Editline::ConfigureEditor(bool multiline) {
   el_set(m_editline, EL_BIND, "\t", "lldb-complete",
  NULL); // Bind TAB to auto complete
 
+  // Allow ctrl-left-arrow and ctrl-right-arrow for navigation, behave like
+  // bash in emacs mode.
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[D", "ed-prev-word", NULL);
+
   // Allow user-specific customization prior to registering bindings we
   // absolutely require
   el_source(m_editline, nullptr);



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


[Lldb-commits] [PATCH] D70137: [lldb][Editline] Support ctrl+left/right arrow word navigation.

2019-11-14 Thread Jordan Rupprecht via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf2e65447b3cb: [lldb][Editline] Support ctrl+left/right arrow 
word navigation. (authored by rupprecht).

Changed prior to commit:
  https://reviews.llvm.org/D70137?vs=229349&id=229373#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70137

Files:
  lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
  lldb/source/Host/common/Editline.cpp


Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -1105,6 +1105,15 @@
   el_set(m_editline, EL_BIND, "\t", "lldb-complete",
  NULL); // Bind TAB to auto complete
 
+  // Allow ctrl-left-arrow and ctrl-right-arrow for navigation, behave like
+  // bash in emacs mode.
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[D", "ed-prev-word", NULL);
+
   // Allow user-specific customization prior to registering bindings we
   // absolutely require
   el_source(m_editline, nullptr);
Index: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
@@ -0,0 +1,49 @@
+"""
+Test that the lldb editline handling is configured correctly.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbpexpect import PExpectTest
+
+
+class EditlineTest(PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_left_right_arrow(self):
+"""Test that ctrl+left/right arrow navigates words correctly.
+
+Note: just sending escape characters to pexpect and checking the buffer
+doesn't work well, so we run real commands. We want to type
+"help command" while exercising word-navigation, so type it as below,
+where [] indicates cursor position.
+
+1. Send "el ommand" -> "el ommand[]"
+2. Ctrl+left once   -> "el []ommand"
+3. Send "c" -> "el c[]ommand"
+4. Ctrl+left twice  -> "[]el command"
+5. Send "h" -> "h[]el command"
+6. Ctrl+right   -> "hel[] command"
+7. Send "p" -> "help command"
+"""
+self.launch()
+
+# Run help for different commands for escape variants to make sure each
+# one matches uniquely (the buffer isn't cleared in between matches).
+cases = [
+("print", "\x1b[1;5D", "\x1b[1;5C"),
+("step", "\x1b[5D", "\x1b[5C"),
+("exit", "\x1b\x1b[D", "\x1b\x1b[C"),
+]
+for (cmd, l_escape, r_escape) in cases:
+self.expect("el {cmd_tail}{L}{cmd_head}{L}{L}h{R}p".format(
+cmd_head=cmd[0], cmd_tail=cmd[1:], L=l_escape, R=r_escape),
+substrs=["Syntax: %s" % cmd])
+
+self.quit()


Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -1105,6 +1105,15 @@
   el_set(m_editline, EL_BIND, "\t", "lldb-complete",
  NULL); // Bind TAB to auto complete
 
+  // Allow ctrl-left-arrow and ctrl-right-arrow for navigation, behave like
+  // bash in emacs mode.
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[1;5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE "[5D", "ed-prev-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[C", "em-next-word", NULL);
+  el_set(m_editline, EL_BIND, ESCAPE ESCAPE "[D", "ed-prev-word", NULL);
+
   // Allow user-specific customization prior to registering bindings we
   // absolutely require
   el_source(m_editline, nullptr);
Index: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py
@@ -0,0 +1,49 @@
+"""
+Test that the lldb editline handling is configured correctly.
+"""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbpexpect import PExpe

Re: [Lldb-commits] [lldb] 0877dd1 - [Driver] Force llvm to install its handlers before lldb's

2019-11-14 Thread via lldb-commits

> On Nov 11, 2019, at 6:12 AM, Pavel Labath  wrote:
> 
> On 09/11/2019 03:05, v...@apple.com  wrote:
>>> On Nov 8, 2019, at 1:17 AM, Pavel Labath  wrote:
>>> 
>>> On 08/11/2019 01:33, via lldb-commits wrote:
 Hey JF, Pavel,
 We're still seeing crashes due to SIGPIPE on some lldb bots. This 
 workaround in the lldb driver is insufficient, because liblldb.dylib may 
 install its own a fresh set of llvm signal handlers (the 
 `NumRegisteredSignals` global is not shared by all images loaded in a 
 process). Here is a trace that illustrates the issue: 
 https://gist.github.com/vedantk/2d0cc1df9bea9f0fa74ee101d240b82c.
 I think we should fix this by changing llvm's default behavior: let's have 
 it ignore SIGPIPE. Driver programs (like clang, dwarfdump, etc.) can then 
 opt-in to exiting when SIGPIPE is received. Wdyt?
>>> 
>>> Ah, yes.. I should've realized that wasn't enough.
>>> 
>>> I agree (and I've alluded to this in the past) that changing the llvm 
>>> behavior is the best option, though ideally, I'd take this a step further, 
>>> and have llvm avoid installing *any* signal handlers by default.
>>> 
>>> This kind of race is not just limited to SIGPIPE. Other signals suffer from 
>>> the same issues too, it's just that the manifestation of that is more 
>>> subtle.
>>> 
>>> lldb and liblldb are still racing in who sets the SIGSEGV (etc.) handlers 
>>> last. Since the main effect of those handlers is to produce a backtrace and 
>>> exit, you won't notice this most of the time. But another effect of these 
>>> handlers is to run the RemoveFileOnSignal actions, and so the set of files 
>>> removed might differ since the two lists of files to delete are independent 
>>> too.
>>> 
>>> (BTW, the fact that this is two copies of llvm racing with each other here 
>>> is unfortunate but irrelevant for this discussion -- the same kind of 
>>> problem would occur if we had llvm and some other entity both trying to 
>>> handle the same signals.)
>> One wrinkle is that the two copies of llvm will track different sets of 
>> files to remove on a signal. In practice, this doesn't seem to be an issue. 
>> But the current situation is that if the lldb process gets a SIGINT, any 
>> files-to-be-removed registered by liblldb get removed, but any 
>> files-to-be-removed registered by the lldb driver stick around.
>>> I think the right behavior for the llvm *library* should be to not install 
>>> *any* signal handlers by default. Instead it should expose some API like 
>>> `runAbnormalExitActions()`, which it's *users* can invoke from a signal 
>>> handler, if they choose so.
>>> 
>>> Then, the client programs can opt into installing the signal handlers and 
>>> calling this function. This can be done as a part of InitLLVM, and it can 
>>> be the default behavior of InitLLVM. The lldb driver can then pass some 
>>> flag to InitLLVM to disable this handling, or it can just continue to 
>>> override it after the fact, like it does now.
>> One advantage of this approach is that existing llvm tools without custom 
>> signal handling wouldn't have to change.
>> To make this work, the dylib would need to install an interrupt handler that 
>> 1) runs llvm::runAbnormalExitActions() to clean up files, then 2) locates & 
>> runs the lldb driver's handler (to do 
>> `GetDebugger().DispatchInputInterrupt()`).
>> And we couldn't use a static initializer to do it, because *then* 
>> liblldb.dylib's handler would get installed before the lldb driver's. I 
>> think this approach necessitates a special entry point into the dylib that 
>> just installs handlers.
> 
> That's *almost* what I was thinking. The main difference is that I didn't 
> want liblldb to be installing the signal handlers (as it is also a library, 
> and I don't think *any* library should be doing that by default).
> Instead I'd expose an SB api to run the cleanup actions 
> (SBHostOS::RunAbnormalExitActions() ?), and leave the signal installation to 
> the lldb driver, whose handler can then call the SB function.
> However, all of this is only needed if we _really_ care that the cleanup 
> actions inside liblldb get actually run. I'm not sure if that's the case 
> right now.
> 
 Some alternatives include:
 - Add a static initializer to liblldb.dylib that copies the workaround in 
 the driver. This should work fine, but it's a duct tape on top of a 
 bandaid.
 - Have the dynamic linker coalesce all copies of `NumRegisteredSignals` in 
 a process. This would incur an app launch time hit on iOS (where libllvm 
 is hot code), and it doesn't seem very portable.
>>> 
>>> A third option might be to link liblldb and the lldb driver to libllvm 
>>> dynamically. That would solve this problem by not having two copies of llvm 
>>> around, but it would also come with some runtime and binary size costs...
>> Yeah, that might be too big a hammer.
>> I just talked to Jonas about it offline and both 

[Lldb-commits] [PATCH] D70252: [Docs] Add Python caveats under the development section

2019-11-14 Thread António Afonso via Phabricator via lldb-commits
aadsm added a comment.

Thank you for writing this up! I was thinking how I would find this.. I don't 
see myself clicking on the "Caveats" link (could also be a me problem though). 
Could we also add a link to it in this section? 
https://lldb.llvm.org/resources/build.html#id22. Something like "NOTE: You need 
to use the python binary you built with, check caveats to learn more"?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D70252



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


[Lldb-commits] [PATCH] D70272: [-gmodules] Let LLDB log a warning if the Clang module hash mismatches.

2019-11-14 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl created this revision.
aprantl added reviewers: jingham, JDevlieghere.
Herald added a reviewer: jdoerfert.

This feature is mostly there to aid debugging of Clang module issues, since the 
only useful actual the end-user can to is to recompile their program. Dsymutil 
prints a similar warning in this case.


https://reviews.llvm.org/D70272

Files:
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/include/lldb/Utility/Log.h
  lldb/packages/Python/lldbsuite/test/lang/objc/modules-hash-mismatch/Makefile
  
lldb/packages/Python/lldbsuite/test/lang/objc/modules-hash-mismatch/TestClangModulesHashMismatch.py
  lldb/packages/Python/lldbsuite/test/lang/objc/modules-hash-mismatch/main.m
  lldb/packages/Python/lldbsuite/test/lang/objc/modules-hash-mismatch/other.m
  lldb/packages/Python/lldbsuite/test/make/Makefile.rules
  lldb/source/Host/common/Host.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -289,6 +289,9 @@
 
   virtual llvm::Optional GetDwoNum() { return llvm::None; }
 
+  llvm::Optional GetSymbolHash() override;
+
+
   static bool
   DIEInDeclContext(const lldb_private::CompilerDeclContext *parent_decl_ctx,
const DWARFDIE &die);
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1553,6 +1553,39 @@
 return DWARFDIE();
 }
 
+/// Return the DW_AT_(GNU_)dwo_name.
+static const char *GetDWOName(DWARFCompileUnit &dwarf_cu,
+  DWARFDebugInfoEntry cu_die) {
+  const char *dwo_name =
+  cu_die.GetAttributeValueAsString(&dwarf_cu, DW_AT_GNU_dwo_name, nullptr);
+  if (!dwo_name)
+dwo_name =
+cu_die.GetAttributeValueAsString(&dwarf_cu, DW_AT_dwo_name, nullptr);
+  return dwo_name;
+}
+
+/// Return the DW_AT_(GNU_)dwo_id.
+/// FIXME: Technically 0 is a valid hash.
+static uint64_t GetDWOId(DWARFCompileUnit &dwarf_cu,
+ DWARFDebugInfoEntry cu_die) {
+  uint64_t dwo_id =
+  cu_die.GetAttributeValueAsUnsigned(&dwarf_cu, DW_AT_GNU_dwo_id, 0);
+  if (!dwo_id)
+dwo_id = cu_die.GetAttributeValueAsUnsigned(&dwarf_cu, DW_AT_dwo_id, 0);
+  return dwo_id;
+}
+
+llvm::Optional SymbolFileDWARF::GetSymbolHash() {
+  if (auto comp_unit = GetCompileUnitAtIndex(0)) {
+if (DWARFCompileUnit *cu = llvm::dyn_cast_or_null(
+GetDWARFCompileUnit(comp_unit.get(
+  if (DWARFDebugInfoEntry *cu_die = cu->DIE().GetDIE())
+if (uint64_t dwo_id = GetDWOId(*cu, *cu_die))
+  return dwo_id;
+  }
+  return {};
+}
+
 std::unique_ptr
 SymbolFileDWARF::GetDwoSymbolFileForCompileUnit(
 DWARFUnit &unit, const DWARFDebugInfoEntry &cu_die) {
@@ -1569,15 +1602,13 @@
   if (!dwarf_cu)
 return nullptr;
 
-  const char *dwo_name =
-  cu_die.GetAttributeValueAsString(dwarf_cu, DW_AT_GNU_dwo_name, nullptr);
+  const char *dwo_name = GetDWOName(*dwarf_cu, cu_die);
   if (!dwo_name)
 return nullptr;
 
   SymbolFileDWARFDwp *dwp_symfile = GetDwpSymbolFile();
   if (dwp_symfile) {
-uint64_t dwo_id =
-cu_die.GetAttributeValueAsUnsigned(dwarf_cu, DW_AT_GNU_dwo_id, 0);
+uint64_t dwo_id = GetDWOId(*dwarf_cu, cu_die);
 std::unique_ptr dwo_symfile =
 dwp_symfile->GetSymbolFileForDwoId(*dwarf_cu, dwo_id);
 if (dwo_symfile)
@@ -1617,15 +1648,18 @@
   if (m_fetched_external_modules)
 return;
   m_fetched_external_modules = true;
-
   DWARFDebugInfo *debug_info = DebugInfo();
 
   // Follow DWO skeleton unit breadcrumbs.
   const uint32_t num_compile_units = GetNumCompileUnits();
   for (uint32_t cu_idx = 0; cu_idx < num_compile_units; ++cu_idx) {
-DWARFUnit *dwarf_cu = debug_info->GetUnitAtIndex(cu_idx);
+auto *dwarf_cu =
+llvm::dyn_cast(debug_info->GetUnitAtIndex(cu_idx));
+if (!dwarf_cu)
+  continue;
+
 const DWARFBaseDIE die = dwarf_cu->GetUnitDIEOnly();
-if (!die || die.HasChildren())
+if (!die || die.HasChildren() || !die.GetDIE())
   continue;
 
 const char *name = die.GetAttributeValueAsString(DW_AT_name, nullptr);
@@ -1637,10 +1671,7 @@
 if (module_sp)
   continue;
 
-const char *dwo_path =
-die.GetAttributeValueAsString(DW_AT_GNU_dwo_name, nullptr);
-if (!dwo_path)
-  dwo_path = die.GetAttributeValueAsString(DW_AT_dwo_name, nullptr);
+const char *dwo_path = GetDWOName(*dwarf_cu, *die.GetDIE());
 if (!dwo_path)
   continue;
 
@@ -1683,12 +1714,34 @@
   GetObjectFile()->GetModule()->ReportWarning(
   "0x%8.8x: unable to locate module needed for external types: "
   

[Lldb-commits] [lldb] f4f47da - [Reproducer] Enable crash reports for reproducer tests

2019-11-14 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2019-11-14T14:16:41-08:00
New Revision: f4f47da530729161a73d71791ada3ab58886b9dd

URL: 
https://github.com/llvm/llvm-project/commit/f4f47da530729161a73d71791ada3ab58886b9dd
DIFF: 
https://github.com/llvm/llvm-project/commit/f4f47da530729161a73d71791ada3ab58886b9dd.diff

LOG: [Reproducer] Enable crash reports for reproducer tests

For some reason the reproducer tests seem really proficient at
uncovering structural issues in LLDB related to how we tear down things,
but of course only on the bots.

The pretty stack trace helps a bit, but what I really want is the crash
reports which contain much more information, such as what other threads
we doing.

Crash reports are automatically suppressed by lit. This patch
(temporarily) disables that for the reproducer tests.

Added: 
lldb/test/Shell/Reproducer/lit.local.cfg

Modified: 


Removed: 




diff  --git a/lldb/test/Shell/Reproducer/lit.local.cfg 
b/lldb/test/Shell/Reproducer/lit.local.cfg
new file mode 100644
index ..5659f1baa06d
--- /dev/null
+++ b/lldb/test/Shell/Reproducer/lit.local.cfg
@@ -0,0 +1,2 @@
+# Enable crash reports for the reproducer tests.
+del config.environment['LLVM_DISABLE_CRASH_REPORT']



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


[Lldb-commits] [lldb] 3b142bc - [LLDB] Fix more -Wdocumentation issues (NFC)

2019-11-14 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2019-11-14T14:31:44-08:00
New Revision: 3b142bc9ff14869726e4fff27ba6f925aa7b5be4

URL: 
https://github.com/llvm/llvm-project/commit/3b142bc9ff14869726e4fff27ba6f925aa7b5be4
DIFF: 
https://github.com/llvm/llvm-project/commit/3b142bc9ff14869726e4fff27ba6f925aa7b5be4.diff

LOG: [LLDB] Fix more -Wdocumentation issues (NFC)

Added: 


Modified: 
lldb/include/lldb/Breakpoint/BreakpointOptions.h
lldb/include/lldb/Core/Address.h
lldb/include/lldb/Expression/ExpressionParser.h
lldb/include/lldb/Expression/UtilityFunction.h
lldb/include/lldb/Interpreter/CommandObject.h
lldb/include/lldb/Target/Process.h

lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/MainThreadCheckerRuntime.cpp

Removed: 




diff  --git a/lldb/include/lldb/Breakpoint/BreakpointOptions.h 
b/lldb/include/lldb/Breakpoint/BreakpointOptions.h
index 55a4be2d19c1..9e02afff5227 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointOptions.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointOptions.h
@@ -135,7 +135,7 @@ friend class Breakpoint;
 
   // Operators
   const BreakpointOptions &operator=(const BreakpointOptions &rhs);
-  
+
   /// Copy over only the options set in the incoming BreakpointOptions.
   void CopyOverSetOptions(const BreakpointOptions &rhs);
 
@@ -267,7 +267,7 @@ friend class Breakpoint;
   bool IsEnabled() const { return m_enabled; }
 
   /// If \a enable is \b true, enable the breakpoint, if \b false disable it.
-  void SetEnabled(bool enabled) { 
+  void SetEnabled(bool enabled) {
 m_enabled = enabled;
 m_set_flags.Set(eEnabled);
   }
@@ -278,7 +278,7 @@ friend class Breakpoint;
   bool IsAutoContinue() const { return m_auto_continue; }
 
   /// Set the auto-continue state.
-  void SetAutoContinue(bool auto_continue) { 
+  void SetAutoContinue(bool auto_continue) {
 m_auto_continue = auto_continue;
 m_set_flags.Set(eAutoContinue);
   }
@@ -289,17 +289,16 @@ friend class Breakpoint;
   bool IsOneShot() const { return m_one_shot; }
 
   /// If \a enable is \b true, enable the breakpoint, if \b false disable it.
-  void SetOneShot(bool one_shot) { 
-m_one_shot = one_shot; 
-m_set_flags.Set(eOneShot); 
+  void SetOneShot(bool one_shot) {
+m_one_shot = one_shot;
+m_set_flags.Set(eOneShot);
   }
 
   /// Set the breakpoint to ignore the next \a count breakpoint hits.
-  /// \param[in] count
+  /// \param[in] n
   ///The number of breakpoint hits to ignore.
-
-  void SetIgnoreCount(uint32_t n) { 
-m_ignore_count = n; 
+  void SetIgnoreCount(uint32_t n) {
+m_ignore_count = n;
 m_set_flags.Set(eIgnoreCount);
   }
 
@@ -341,13 +340,13 @@ friend class Breakpoint;
   /// A UP holding the new'ed CommandData object.
   /// The breakpoint will take ownership of pointer held by this object.
   void SetCommandDataCallback(std::unique_ptr &cmd_data);
-  
+
   void Clear();
-  
+
   bool AnySet() const {
 return m_set_flags.AnySet(eAllOptions);
   }
-  
+
 protected:
   // Classes that inherit from BreakpointOptions can see and modify these
   bool IsOptionSet(OptionKind kind)
@@ -377,7 +376,7 @@ friend class Breakpoint;
 
 private:
   /// For BreakpointOptions only
-  
+
   /// This is the callback function pointer
   BreakpointHitCallback m_callback;
   /// This is the client data for the callback

diff  --git a/lldb/include/lldb/Core/Address.h 
b/lldb/include/lldb/Core/Address.h
index 386c3f1a0f85..70a7f790e40d 100644
--- a/lldb/include/lldb/Core/Address.h
+++ b/lldb/include/lldb/Core/Address.h
@@ -131,7 +131,7 @@ class Address {
   ///
   /// Initialize the address with the supplied \a section and \a offset.
   ///
-  /// \param[in] section
+  /// \param[in] section_sp
   /// A section pointer to a valid lldb::Section, or NULL if the
   /// address doesn't have a section or will get resolved later.
   ///
@@ -443,7 +443,7 @@ class Address {
 
   /// Set accessor for the section.
   ///
-  /// \param[in] section
+  /// \param[in] section_sp
   /// A new lldb::Section pointer to use as the section base. Can
   /// be NULL for absolute addresses that are not relative to
   /// any section.

diff  --git a/lldb/include/lldb/Expression/ExpressionParser.h 
b/lldb/include/lldb/Expression/ExpressionParser.h
index 4dec5d6a9aae..2e7b3075d509 100644
--- a/lldb/include/lldb/Expression/ExpressionParser.h
+++ b/lldb/include/lldb/Expression/ExpressionParser.h
@@ -29,7 +29,7 @@ class ExpressionParser {
   ///
   /// Initializes class variables.
   ///
-  /// \param[in] exe_scope,
+  /// \param[in] exe_scope
   /// If non-NULL, an execution context scope that can help to
   /// correctly create an expression with a valid process for
   /// optional tuning Objective-C runtime support. Can be NULL.

diff  --git a/lldb/include/lldb/Expression/UtilityFunction.h 
b/lldb/include/lldb/Expression/UtilityFunction.h
index 8a11e2f

[Lldb-commits] [PATCH] D70277: [Signal] Allow llvm clients to opt into one-shot SIGPIPE handling

2019-11-14 Thread Vedant Kumar via Phabricator via lldb-commits
vsk created this revision.
vsk added reviewers: JDevlieghere, jfb, labath.
Herald added subscribers: dexonsmith, hiraditya.
Herald added a project: LLVM.

Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of exiting with an IO error by default.

This prevents "IO error" crashes in long-lived processes (lldb is the
motivating example) which both a) load llvm as a dynamic library and b)
*really* need to ignore SIGPIPE.

As llvm signal handlers can be installed when calling into libclang
(say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for
SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the
current model.


https://reviews.llvm.org/D70277

Files:
  clang/tools/driver/driver.cpp
  lldb/tools/driver/Driver.cpp
  llvm/include/llvm/Support/Signals.h
  llvm/lib/Support/Unix/Signals.inc
  llvm/lib/Support/Windows/Signals.inc

Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -560,6 +560,13 @@
   // Unimplemented.
 }
 
+void llvm::sys::SetOneShotPipeSignalFunction(void (*Handler)()) {
+  // Unimplemented.
+}
+
+void llvm::sys::DefaultOneShotPipeSignalHandler() {
+  // Unimplemented.
+}
 
 /// Add a function to be called when a signal is delivered to the process. The
 /// handler can have a cookie passed to it to identify what instance of the
Index: llvm/lib/Support/Unix/Signals.inc
===
--- llvm/lib/Support/Unix/Signals.inc
+++ llvm/lib/Support/Unix/Signals.inc
@@ -88,6 +88,9 @@
 ATOMIC_VAR_INIT(nullptr);
 static std::atomic InfoSignalFunction =
 ATOMIC_VAR_INIT(nullptr);
+/// The function to call on SIGPIPE (one-time use only).
+static std::atomic OneShotPipeSignalFunction =
+ATOMIC_VAR_INIT(nullptr);
 
 namespace {
 /// Signal-safe removal of files.
@@ -206,7 +209,7 @@
 /// if there is, it's not our direct responsibility. For whatever reason, our
 /// continued execution is no longer desirable.
 static const int IntSigs[] = {
-  SIGHUP, SIGINT, SIGPIPE, SIGTERM, SIGUSR2
+  SIGHUP, SIGINT, SIGTERM, SIGUSR2
 };
 
 /// Signals that represent that we have a bug, and our prompt termination has
@@ -237,7 +240,7 @@
 
 static const size_t NumSigs =
 array_lengthof(IntSigs) + array_lengthof(KillSigs) +
-array_lengthof(InfoSigs);
+array_lengthof(InfoSigs) + 1 /* SIGPIPE */;
 
 
 static std::atomic NumRegisteredSignals = ATOMIC_VAR_INIT(0);
@@ -322,6 +325,8 @@
 registerHandler(S, SignalKind::IsKill);
   for (auto S : KillSigs)
 registerHandler(S, SignalKind::IsKill);
+  if (OneShotPipeSignalFunction)
+registerHandler(SIGPIPE, SignalKind::IsKill);
   for (auto S : InfoSigs)
 registerHandler(S, SignalKind::IsInfo);
 }
@@ -361,9 +366,10 @@
   if (auto OldInterruptFunction = InterruptFunction.exchange(nullptr))
 return OldInterruptFunction();
 
-  // Send a special return code that drivers can check for, from sysexits.h.
   if (Sig == SIGPIPE)
-exit(EX_IOERR);
+if (auto OldOneShotPipeFunction =
+OneShotPipeSignalFunction.exchange(nullptr))
+  return OldOneShotPipeFunction();
 
   raise(Sig);   // Execute the default handler.
   return;
@@ -403,6 +409,16 @@
   RegisterHandlers();
 }
 
+void llvm::sys::SetOneShotPipeSignalFunction(void (*Handler)()) {
+  OneShotPipeSignalFunction.exchange(Handler);
+  RegisterHandlers();
+}
+
+void llvm::sys::DefaultOneShotPipeSignalHandler() {
+  // Send a special return code that drivers can check for, from sysexits.h.
+  exit(EX_IOERR);
+}
+
 // The public API
 bool llvm::sys::RemoveFileOnSignal(StringRef Filename,
std::string* ErrMsg) {
Index: llvm/include/llvm/Support/Signals.h
===
--- llvm/include/llvm/Support/Signals.h
+++ llvm/include/llvm/Support/Signals.h
@@ -84,6 +84,26 @@
   /// function.  Note also that the handler may be executed on a different
   /// thread on some platforms.
   void SetInfoSignalFunction(void (*Handler)());
+
+  /// Registers a function to be called in a "one-shot" manner when a pipe
+  /// signal is delivered to the process (i.e., on a failed write to a pipe).
+  /// After the pipe signal is handled once, the handler is unregistered.
+  ///
+  /// The LLVM signal handling code will not install any handler for the pipe
+  /// signal unless one is provided with this API (see \ref
+  /// DefaultOneShotPipeSignalHandler).
+  ///
+  /// Note that the handler is not allowed to call any non-reentrant
+  /// functions.  A null handler pointer disables the current installed
+  /// function.  Note also that the handler may be executed on a
+  /// different thread on some platforms.
+  ///
+  /// This is a no-op on Windows.
+  void SetOneShotPipeSignalFunction(void (*Handler)());
+
+  /// On Unix

[Lldb-commits] [PATCH] D64844: [Target] Remove Target::GetScratchClangASTContext

2019-11-14 Thread Alex Langford via Phabricator via lldb-commits
xiaobai updated this revision to Diff 229418.
xiaobai added a comment.
Herald added a project: LLDB.

Rebased
Moved this change to the monorepo layout
Moved `ClangASTContext::GetScratch` to the ClangASTContext header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64844

Files:
  lldb/include/lldb/Symbol/ClangASTContext.h
  lldb/include/lldb/Target/Target.h
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
  lldb/source/Plugins/Language/ObjC/NSArray.cpp
  lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
  lldb/source/Plugins/Language/ObjC/NSError.cpp
  lldb/source/Plugins/Language/ObjC/NSException.cpp
  lldb/source/Plugins/Language/ObjC/NSIndexPath.cpp
  lldb/source/Plugins/Language/ObjC/NSString.cpp
  
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
  lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
  lldb/source/Target/Target.cpp

Index: lldb/source/Target/Target.cpp
===
--- lldb/source/Target/Target.cpp
+++ lldb/source/Target/Target.cpp
@@ -2253,20 +2253,6 @@
   return utility_fn;
 }
 
-ClangASTContext *Target::GetScratchClangASTContext(bool create_on_demand) {
-  if (!m_valid)
-return nullptr;
-
-  auto type_system_or_err =
-  GetScratchTypeSystemForLanguage(eLanguageTypeC, create_on_demand);
-  if (auto err = type_system_or_err.takeError()) {
-LLDB_LOG_ERROR(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_TARGET),
-   std::move(err), "Couldn't get scratch ClangASTContext");
-return nullptr;
-  }
-  return llvm::dyn_cast(&type_system_or_err.get());
-}
-
 ClangASTImporterSP Target::GetClangASTImporter() {
   if (m_valid) {
 if (!m_ast_importer_sp) {
Index: lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -412,7 +412,7 @@
 #endif
 
 ClangASTContext *ast_ctx =
-m_process->GetTarget().GetScratchClangASTContext();
+ClangASTContext::GetScratch(m_process->GetTarget());
 if (ast_ctx->getASTContext() &&
 m_dispatch_tsd_indexes_addr != LLDB_INVALID_ADDRESS) {
   CompilerType uint16 =
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -186,7 +186,7 @@
   // Also make the FunctionCaller for this UtilityFunction:
 
   ClangASTContext *clang_ast_context =
-  thread.GetProcess()->GetTarget().GetScratchClangASTContext();
+  ClangASTContext::GetScratch(thread.GetProcess()->GetTarget());
   CompilerType get_thread_item_info_return_type =
   clang_ast_context->GetBasicType(eBasicTypeVoid).GetPointerType();
 
@@ -237,7 +237,7 @@
   lldb::StackFrameSP thread_cur_frame = thread.GetStackFrameAtIndex(0);
   ProcessSP process_sp(thread.CalculateProcess());
   TargetSP target_sp(thread.CalculateTarget());
-  ClangASTContext *clang_ast_context = target_sp->GetScratchClangASTContext();
+  ClangASTContext *clang_ast_context = ClangASTContext::GetScratch(*target_sp);
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_SYSTEM_RUNTIME));
 
   GetThreadItemInfoReturnInfo return_value;
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
@@ -191,7 +191,7 @@
 
 // Next make the runner function 

[Lldb-commits] [lldb] 95c770f - [Utility] Remove a dead header [PPC64LE_ehframe_Registers.h]

2019-11-14 Thread Davide Italiano via lldb-commits

Author: Davide Italiano
Date: 2019-11-14T15:29:47-08:00
New Revision: 95c770fbfb14b07e1af7c2d427c16745617d9f1f

URL: 
https://github.com/llvm/llvm-project/commit/95c770fbfb14b07e1af7c2d427c16745617d9f1f
DIFF: 
https://github.com/llvm/llvm-project/commit/95c770fbfb14b07e1af7c2d427c16745617d9f1f.diff

LOG: [Utility] Remove a dead header [PPC64LE_ehframe_Registers.h]

Added: 


Modified: 


Removed: 
lldb/source/Utility/PPC64LE_ehframe_Registers.h



diff  --git a/lldb/source/Utility/PPC64LE_ehframe_Registers.h 
b/lldb/source/Utility/PPC64LE_ehframe_Registers.h
deleted file mode 100644
index 77cb3e5924e7..
--- a/lldb/source/Utility/PPC64LE_ehframe_Registers.h
+++ /dev/null
@@ -1,193 +0,0 @@
-//===-- PPC64LE_ehframe_Registers.h -*- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#ifndef utility_PPC64LE_ehframe_Registers_h_
-#define utility_PPC64LE_ehframe_Registers_h_
-
-// The register numbers used in the eh_frame unwind information.
-// Should be the same as DWARF register numbers.
-
-namespace ppc64le_ehframe {
-
-enum {
-  r0 = 0,
-  r1,
-  r2,
-  r3,
-  r4,
-  r5,
-  r6,
-  r7,
-  r8,
-  r9,
-  r10,
-  r11,
-  r12,
-  r13,
-  r14,
-  r15,
-  r16,
-  r17,
-  r18,
-  r19,
-  r20,
-  r21,
-  r22,
-  r23,
-  r24,
-  r25,
-  r26,
-  r27,
-  r28,
-  r29,
-  r30,
-  r31,
-  f0,
-  f1,
-  f2,
-  f3,
-  f4,
-  f5,
-  f6,
-  f7,
-  f8,
-  f9,
-  f10,
-  f11,
-  f12,
-  f13,
-  f14,
-  f15,
-  f16,
-  f17,
-  f18,
-  f19,
-  f20,
-  f21,
-  f22,
-  f23,
-  f24,
-  f25,
-  f26,
-  f27,
-  f28,
-  f29,
-  f30,
-  f31,
-  lr = 65,
-  ctr,
-  cr = 68,
-  xer = 76,
-  vr0,
-  vr1,
-  vr2,
-  vr3,
-  vr4,
-  vr5,
-  vr6,
-  vr7,
-  vr8,
-  vr9,
-  vr10,
-  vr11,
-  vr12,
-  vr13,
-  vr14,
-  vr15,
-  vr16,
-  vr17,
-  vr18,
-  vr19,
-  vr20,
-  vr21,
-  vr22,
-  vr23,
-  vr24,
-  vr25,
-  vr26,
-  vr27,
-  vr28,
-  vr29,
-  vr30,
-  vr31,
-  vscr = 110,
-  vrsave = 117,
-  pc,
-  softe,
-  trap,
-  origr3,
-  fpscr,
-  msr,
-  vs0,
-  vs1,
-  vs2,
-  vs3,
-  vs4,
-  vs5,
-  vs6,
-  vs7,
-  vs8,
-  vs9,
-  vs10,
-  vs11,
-  vs12,
-  vs13,
-  vs14,
-  vs15,
-  vs16,
-  vs17,
-  vs18,
-  vs19,
-  vs20,
-  vs21,
-  vs22,
-  vs23,
-  vs24,
-  vs25,
-  vs26,
-  vs27,
-  vs28,
-  vs29,
-  vs30,
-  vs31,
-  vs32,
-  vs33,
-  vs34,
-  vs35,
-  vs36,
-  vs37,
-  vs38,
-  vs39,
-  vs40,
-  vs41,
-  vs42,
-  vs43,
-  vs44,
-  vs45,
-  vs46,
-  vs47,
-  vs48,
-  vs49,
-  vs50,
-  vs51,
-  vs52,
-  vs53,
-  vs54,
-  vs55,
-  vs56,
-  vs57,
-  vs58,
-  vs59,
-  vs60,
-  vs61,
-  vs62,
-  vs63,
-};
-}
-
-#endif // utility_PPC64LE_ehframe_Registers_h_



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


[Lldb-commits] [PATCH] D70281: Fix -Wunused-result warnings in LLDB

2019-11-14 Thread Reid Kleckner via Phabricator via lldb-commits
rnk created this revision.
rnk added a reviewer: amccarth.
Herald added a project: LLDB.

Three uses of try_lock intentionally ignore the result. Make that
explicit with a void cast.

Add what appears to be a missing return in the clang expression parser
code. It's a functional change, but presumably the right one.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70281

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
  lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp


Index: lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
===
--- lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
+++ lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
@@ -166,7 +166,7 @@
   Target &target = m_process->GetTarget();
   std::unique_lock api_lock(target.GetAPIMutex(),
   std::defer_lock);
-  api_lock.try_lock();
+  (void)api_lock.try_lock(); // Ignore the result, do it anyway.
   auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
   LLDB_LOGF(log,
@@ -308,7 +308,7 @@
   Target &target = m_process->GetTarget();
   std::unique_lock api_lock(target.GetAPIMutex(),
   std::defer_lock);
-  api_lock.try_lock();
+  (void)api_lock.try_lock(); // Ignore the result, do it anyway.
   auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
@@ -395,7 +395,7 @@
 Target &target = m_process->GetTarget();
 std::unique_lock api_lock(target.GetAPIMutex(),
 std::defer_lock);
-api_lock.try_lock();
+(void)api_lock.try_lock(); // Ignore the result, do it anyway.
 auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
 StructuredData::DictionarySP thread_info_dict =
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
@@ -312,7 +312,7 @@
   if (m_exe_ctx.GetTargetPtr())
 return m_exe_ctx.GetTargetPtr();
   else if (m_sym_ctx.target_sp)
-m_sym_ctx.target_sp.get();
+return m_sym_ctx.target_sp.get();
   return nullptr;
 }
 


Index: lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
===
--- lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
+++ lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
@@ -166,7 +166,7 @@
   Target &target = m_process->GetTarget();
   std::unique_lock api_lock(target.GetAPIMutex(),
   std::defer_lock);
-  api_lock.try_lock();
+  (void)api_lock.try_lock(); // Ignore the result, do it anyway.
   auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
   LLDB_LOGF(log,
@@ -308,7 +308,7 @@
   Target &target = m_process->GetTarget();
   std::unique_lock api_lock(target.GetAPIMutex(),
   std::defer_lock);
-  api_lock.try_lock();
+  (void)api_lock.try_lock(); // Ignore the result, do it anyway.
   auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_THREAD));
@@ -395,7 +395,7 @@
 Target &target = m_process->GetTarget();
 std::unique_lock api_lock(target.GetAPIMutex(),
 std::defer_lock);
-api_lock.try_lock();
+(void)api_lock.try_lock(); // Ignore the result, do it anyway.
 auto interpreter_lock = m_interpreter->AcquireInterpreterLock();
 
 StructuredData::DictionarySP thread_info_dict =
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
@@ -312,7 +312,7 @@
   if (m_exe_ctx.GetTargetPtr())
 return m_exe_ctx.GetTargetPtr();
   else if (m_sym_ctx.target_sp)
-m_sym_ctx.target_sp.get();
+return m_sym_ctx.target_sp.get();
   return nullptr;
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D70281: Fix -Wunused-result warnings in LLDB

2019-11-14 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth accepted this revision.
amccarth added a comment.
This revision is now accepted and ready to land.

LGTM.

It's too bad that pattern is repeated three times, including the explanatory 
comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70281



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


[Lldb-commits] [PATCH] D70281: Fix -Wunused-result warnings in LLDB

2019-11-14 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

There's a PP above each instance of this code explaining why it's okay if we 
don't get the API lock, since that's a bit of a tricky point.  So if you want 
to add a comment, it would be better to say "see explanation above".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70281



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


[Lldb-commits] [PATCH] D70272: [-gmodules] Let LLDB log a warning if the Clang module hash mismatches.

2019-11-14 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: lldb/source/Host/common/Host.cpp:300
   va_end(args);
+
+  // Log to log channel. This allows testcases to grep for log output.

On macOS, SystemLog vsprintf's to stderr.  So you probably don't want to put 
this out always.  Maybe since you don't know where SystemLog is going to print 
things, it would be better to only output this if the log channel is set to 
verbose.  That would still allow you to use it in tests, but wouldn't introduce 
any new output in the normal case?


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

https://reviews.llvm.org/D70272



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