[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext
+
+def getToolchainUtil(util_name):
+return (cc_dir / (cc_prefix + util_name + cc_ext)).as_posix()
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",
+"ARCHIVER": "ar",
+"DWP": "dwp",
+}
+utils = []
+
+# Note: LLVM_AR is currently required by API TestBSDArchives.py 
tests.
+# Assembly a full path to llvm-ar for given LLVM_TOOLS_DIR;
+# otherwise assume we have llvm-ar at the same place where is CC 
specified.
+if not os.getenv("LLVM_AR"):
+llvm_ar = getLlvmUtil("llvm-ar")
+utils.extend(['LLVM_AR="%s"' % llvm_ar])
+
+if not lldbplatformutil.platformIsDarwin():
+if os.getenv("USE_LLVM_TOOLS"):
+# Use the llvm project tool instead of the system defaults.
+for var, name in util_names.items():
+utils.append('%s="%s"' % (var, getLlvmUtil("llvm-" + 
name)))
+utils.extend(['AR="%s"' % llvm_ar])
+elif cc_type in ["clang", "cc", "gcc"]:
+util_paths = {}
+# Assembly a toolchain side tool cmd based on passed CC.
+for var, name in util_names.items():
+# Do not override explicity specified tool from the 
cmd line.
+if not os.getenv(var):
+util_paths[var] = getToolchainUtil(name)
+else:
+util_paths[var] = os.getenv(var)
+utils.extend(['AR="%s"' % util_paths["ARCHIVER"]])
+
+# Look for llvm-dwp or gnu dwp
+if not lldbutil.which(util_paths["DWP"]):
+util_paths["DWP"] = getToolchainUtil("llvm-dwp")
+if not lldbutil.which(util_paths["DWP"]):
+util_paths["DWP"] = lldbutil.which("llvm-dwp")
+if not util_paths["DWP"]:
+util_paths["DWP"] = lldbutil.which("dwp")
+if not util_paths["DWP"]:
+del util_paths["DWP"]
+
+for var, path in util_paths.items():
+   

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext

labath wrote:

```suggestion
return os.path.join(llvm_tools_dir, util_name + exe_ext)
```

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -102,15 +102,33 @@ endif
 # If you change the defaults of CC, be sure to also change it in the file
 # test/builders/builder_base.py, which provides a Python way to return the
 # value of the make variable CC -- getCompiler().
-#
-# See also these functions:
-#   o cxx_compiler
-#   o cxx_linker
 #--
 ifeq "$(CC)" ""
 $(error "C compiler is not specified. Please run tests through lldb-dotest or 
lit")
 endif
 
+# Remove all " and ' characters from the path. Also remove surrounding space 
chars.
+cstrip = $(strip $(subst ",,$(subst ',,$(1
+override CC := $(call cstrip,$(CC))
+override CCC := $(call cstrip,$(CCC))
+override CXX := $(call cstrip,$(CXX))
+# Always override the linker. Assign already normalized CC.
+override LD := $(call cstrip,$(CC))
+# A kind of linker. It always gets retrieved from CC.
+override LDC := $(call cstrip,$(CCC))
+override OBJCOPY := $(call cstrip,$(OBJCOPY))
+override STRIP := $(call cstrip,$(STRIP))
+override ARCHIVER := $(call cstrip,$(ARCHIVER))
+override AR := $(call cstrip,$(AR))
+override DWP := $(call cstrip,$(DWP))
+override LLVM_AR := $(call cstrip,$(LLVM_AR))

labath wrote:

Is this really necessary? Could we get rid of it by *not* passing the extra 
quotes in the python cmd?

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] unique_ptr-ify some GetUserExpression APIs. (PR #106034)

[Pavel Labath via lldb-commits]

https://github.com/labath approved this pull request.


https://github.com/llvm/llvm-project/pull/106034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add 'FindInMemory()' overload for PostMortemProcess. (PR #102536)

[Pavel Labath via lldb-commits]

labath wrote:

> Let me know if you guys don't want this patch in. I will closed it and apply 
> it to our local branch. @jasonmolenda @labath

Without claiming official authority to make this decision, I'm going to say 
that *I* don't think this is a good idea, because the patch is very (and IMO, 
unnecessarily) specific to post mortem processes. My (currently WIP) patch 
(#104193) gets you most of the speed benefits, works with live processes as 
well and it does that without introducing any new APIs.

What you do downstream is up to you, but I would encourage you to wait for me 
to finish up that patch, as this doesn't look like something that would be a 
good idea to carry downstream (I certainly wouldn't want to do it).

https://github.com/llvm/llvm-project/pull/102536
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

[Pavel Labath via lldb-commits]

labath wrote:

I like this. I have just two remarks:
- it might be better to split this into three steps (add new APIs, port to new 
APIs, remove old APIs), as that will make reverts easier/less disruptive (I 
don't know how much we can trust pre-commit CI these days, but I wouldn't be 
surprised if this breaks some platform-specific code).
- since this seems like a perfect opportunity to bikesh^Wdiscuss the names, I'm 
going to ask if there's any appetite for shortening some of the new factory 
functions. `Status::FromErrorStringWithFormatv` is a bit of a mouthful, so I 
was thinking if we could  use something shorter instead (`Status::FromFormatv` 
or even `Status::Formatv`) ?

https://github.com/llvm/llvm-project/pull/106163
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Updated TCPSocket to listen multiple ports on the same single thread (PR #104797)

[Pavel Labath via lldb-commits]

labath wrote:

Having a single socket listen on multiple ports sounds like a bad idea to me. 
The socket class is complicated enough as it is, and it's not the way the 
MainLoop class was meant to be used (the idea being for it to be created at the 
topmost level possible, so that any number of users could register their 
handlers).

I think that a better and more versatile API would be something like:
```
std::vector /*or sth like that*/ 
TCPSocket::Accept(MainLoop &mainloop, 
std::function accepted_socket)> /*or similar*/ 
socket_cb);
```

Then we could create two sockets and have them listen on the same main loop 
instance. It should be possible to reimplement the existing TCPSocket::Accept 
function on top of this API.

https://github.com/llvm/llvm-project/pull/104797
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][WIP] memory find speedup+bugfix (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From b46820a91f1ad8d6db46210e3135abdb1ab475e8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 25 +-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 131 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..88fbd0c192a58e 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/find/Tes

[Lldb-commits] [lldb] [lldb][WIP] memory find speedup+bugfix (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From 7b8b8b699902d2365ea43e5ae015546c4d20fac8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 30 ++-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 136 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..72acfb3d600701 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/find/Te

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath ready_for_review 
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From 7b8b8b699902d2365ea43e5ae015546c4d20fac8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH 1/2] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 30 ++-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 136 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..72acfb3d600701 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/fin

[Lldb-commits] [lldb] [lldb] Turn lldb_private::Status into a value type. (PR #106163)

[Pavel Labath via lldb-commits]

labath wrote:

> > * since this seems like a perfect opportunity to bikesh^Wdiscuss the names, 
> > I'm going to ask if there's any appetite for shortening some of the new 
> > factory functions. `Status::FromErrorStringWithFormatv` is a bit of a 
> > mouthful, so I was thinking if we could  use something shorter instead 
> > (`Status::FromFormatv` or even `Status::Formatv`) ?
> 
> I picked these names, because they are in line with the old names, which made 
> the regex replacement feasible. Renaming them afterwards is going to be 
> easier. My 2 cents on the naming: I had `Status::FromFormatv` in a previous 
> iteration of this patch and changed my mind, because it doesn't indicate that 
> this is going to be an error. What do you think about the slightly shorter 
> `Status::ErrorFromFromatv()`?

I think it's better (because its shorter), though it's still a bit long for my 
taste. FWIW, I don't find the short name at all confusing, because my mental 
model of these error types is (and all types I know behave that way) is that 
they have only one "success" value, and everything else represents some kind of 
an error/failure. So, when I see anything more complicated than `Status()` (or 
whatever the final API is for constructing success values), I immediately 
expect an error status.

I guess one difference is that I'm used to working with `absl::Status` (which I 
believe was zturner's inspiration for this name), so "status" feels just like a 
synonym for "error" to me. If you think having the word "error" in the name 
helps, I'd also be fine with `Status::Errorf` and `Status::Errorv` (for printf 
vs formatv styles) or something like that.

https://github.com/llvm/llvm-project/pull/106163
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From 7b8b8b699902d2365ea43e5ae015546c4d20fac8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH 1/3] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 30 ++-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 136 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..72acfb3d600701 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/fin

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

labath wrote:

> > It also reads the memory in bulk (up to 1MB)
> 
> ```
> // Maximum number of bytes read (and buffered). We need to read at least
> // `size` bytes for a successful match.
> const size_t max_read_size = std::max(size, 0x1);
> ```
> 
> It seems the minimal chunk is 64KB and the maximal chunk may be very long 
> (more than 1MB).

Depends on how you look at it, I guess. The actual read size will be the 
minimum of this number and the "remainder of memory to be searched" 
(`std::min(mem.size(), high - s)`), so `max_read_size` is really a cap on the 
read size. It's true that the value can be bigger than 64K (or even 1MB). 
However that can only happen if the string being searched is larger than that 
value. This is necessary because the search algorithm matches from the end of 
the pattern.

I wanted to keep the algorithm simple and keep the entire (potential) match in 
memory at once, as trying to read in the middle of matching would get messy. I 
don't think anyone searches for strings this long, but if we do want to 
(better) support that use case, I think that the best solution would be to 
switch to an algorithm (e.g. 
[KMP](https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm))
 which scans the search space in a strictly linear fashion -- as that will make 
it easy to read the memory in arbitrary increments.

> 
> Something is wrong with the first memory block in tests
> 
> ```
> Got output:
> data found at location: 0x7f6bdf3eb000
> 0x7f6bdf3eb000: 6e 65 65 64 6c 65 00 00 00 00 00 00 00 00 00 00  
> needle..
> 0x7f6bdf3eb010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 
> data found at location: 0x7f6bdf3eb800
> 0x7f6bdf3eb800: 6e 65 65 64 6c 65 00 00 00 00 00 00 00 00 00 00  
> needle..
> 0x7f6bdf3eb810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 
> data found at location: 0x7f6bdf3edff9
> 0x7f6bdf3edff9: 6e 65 65 64 6c 65 00 50 e0 3e df 6b 7f 00 00 6d  
> needle.P.>.k...m
> 0x7f6bdf3ee009: dd 41 df 6b 7f 00 00 00 00 00 00 00 00 00 00 40  
> .A.k...@
> no more matches within the range.
> 
> Expecting sub string: "data found at location: 0x7f6bdf3e9000" (was not found)
> ```
> 

Interesting. It does work on my machine. I'll try to debug this.

> Note the capacity=0 is a special case here `llvm::SmallVector 
> mem;` I'd recommend
> 
> ```
> const size_t min_read_size = 0x1;
> const size_t max_read_size = std::max(size, min_read_size);
> llvm::SmallVector mem;
> ```

That would allocate the 64k on the stack, which isn't good practice (I doubt it 
will make things faster, and it can cause us to blow the stack). 64k is  1000x 
larger than the [preffered small vector 
size](https://github.com/llvm/llvm-project/blob/16910a21ee0fabab2df291e4e5bc18289bd5762d/llvm/include/llvm/ADT/SmallVector.h#L1150C27-L1150C54).
 In practice there will only ever be one heap allocation here -- first `resize` 
call on the vector will allocate a ~64k heap block, and all subsequent resizes 
will just move the end pointer around.

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;

labath wrote:

I'm using the SmallVector for the `resize_for_overwrite` functionality 
(allocating memory without initializing it).

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From 7b8b8b699902d2365ea43e5ae015546c4d20fac8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH 1/4] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 30 ++-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 136 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..72acfb3d600701 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/fin

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -79,3 +83,25 @@ def test_memory_find(self):
 'memory find -s "nothere" `stringdata` `stringdata+10`',
 substrs=["data not found within the range."],
 )
+
+@expectedFailureWindows
+def test_memory_find_with_holes(self):
+self._prepare_inferior()
+
+self.runCmd("log enable gdb-remote packets")
+self.runCmd("log enable lldb process target")
+
+pagesize = self.frame().FindVariable("pagesize").GetValueAsUnsigned()
+mem_with_holes = (
+self.frame().FindVariable("mem_with_holes").GetValueAsUnsigned()
+)
+matches_var = self.frame().FindVariable("matches")
+self.assertEqual(matches_var.GetNumChildren(), 4)
+matches = [
+f"data found at location: 
{matches_var.GetChildAtIndex(i).GetValueAsUnsigned():#x}"
+for i in range(4)
+]
+self.expect(
+'memory find -c 5 -s "needle" `mem_with_holes` 
`mem_with_holes+5*pagesize`',

labath wrote:

Done (the first part).

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {

labath wrote:

How about cur_addr? :) (`s` was a leftover from the original implementation, 
but I've now completely changed it anyway).

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {

labath wrote:

good idea

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -1,9 +1,76 @@
-#include 
-#include 
-
-int main (int argc, char const *argv[])
-{
-const char* stringdata = "hello world; I like to write text in const char 
pointers";
-uint8_t bytedata[] = 
{0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99};
-return 0; // break here
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef _WIN32
+#include "Windows.h"
+
+int getpagesize() {
+  SYSTEM_INFO system_info;
+  GetSystemInfo(&system_info);
+  return system_info.dwPageSize;
+}
+
+char *allocate_memory_with_holes() {
+  int pagesize = getpagesize();
+  void *mem = VirtualAlloc(nullptr, 5 * pagesize, MEM_RESERVE, PAGE_NOACCESS);
+  if (!mem) {
+std::cerr << std::system_category().message(GetLastError()) << std::endl;
+exit(1);
+  }
+  char *bytes = static_cast(mem);
+  for (int page : {0, 2, 4}) {
+if (!VirtualAlloc(bytes + page * pagesize, pagesize, MEM_COMMIT,

labath wrote:

Added a comment at the top. Definitely not a Windows expert here, but my 
understanding is that the main difference is due to the MEM_RESERVE/MEM_COMMIT. 
MEM_RESERVE does not actually allocate any memory. It just marks the range as 
in use ("reserved") so that it is won't be taken by other allocation calls. 
MEM_COMMIT is what actually allocates the page.

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();

labath wrote:

Correct. mem_pos is updated when changing the `mem` array, which we're not 
doing here. That will happen on the next iteration of the loop when we realize 
that the mem buffer does not hold the thing we're interested in.

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

labath wrote:

I figured out the problem, and it's kind of hilarious. Turns out (linux?) 
lldb-server does not actually return partial reads (i.e., it behaves like 
windows), but the reason that the test succeeds (for me) is that the holes in 
the allocated memory get filled my memory allocated by lldb. For whatever 
reason (different kernel) this does not happen on the bot. I guess I'll need to 
fix the memory read issues first..

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Inline expression evaluator error visualization (PR #106470)

[Pavel Labath via lldb-commits]

labath wrote:

This seems like it could be problematic for IDEs, if they don't print the error 
in the same window as the expression being evaluated. The arrows could end up 
pointing to nowhere, or to the wrong place in the expression (if we don't get 
the right offset).

I think this could be made simpler and more robust by just printing a 
reproduction of the expression as the first line of the error message. It 
saving that one line output worth it?

Also, how will this behave for multiline expressions? Or with errors that refer 
to multiple source locations (e.g inside macro expansions)?
```
(lldb) expr
Enter expressions, then terminate with an empty line to evaluate:
  1: #define FOO(x) foo+x 
  2: FOO(bar) 
error: :2:1: use of undeclared identifier 'foo'
2 | FOO(bar)
  | ^
:1:16: expanded from macro 'FOO'
1 | #define FOO(x) foo+x
  |^
error: :2:5: use of undeclared identifier 'bar'
2 | FOO(bar)
  | ^
```

https://github.com/llvm/llvm-project/pull/106470
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add Status::Detail to store expression evaluator diagnostics [… (PR #106442)

[Pavel Labath via lldb-commits]

labath wrote:

The llvm::Error class already supports this kind of metadata (and in a much 
better way IMO). Given that moving to llvm::Error is our long term goal, would 
it be possible to port enough APIs so that it's possible to pass an unmodified 
Error object from the producer to the place that needs to consume it?

https://github.com/llvm/llvm-project/pull/106442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] lldb: get lldb API tests working with newer Android NDKs (PR #106443)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

This looks great. I don't think anyone will object to removing old ndk support, 
but let's leave this PR open for a while to give people a chance to notice.

https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] lldb: get lldb API tests working with newer Android NDKs (PR #106443)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] lldb: get lldb API tests working with newer Android NDKs (PR #106443)

[Pavel Labath via lldb-commits]

@@ -1,81 +1,55 @@
 NDK_ROOT := $(shell dirname $(CC))/../../../../..
 
-ifeq "$(findstring 64, $(ARCH))" "64"
-   # lowest 64-bit API level
-   API_LEVEL := 21
-else ifeq "$(ARCH)" "i386"
-   # clone(2) declaration is present only since this api level
-   API_LEVEL := 17
+ifeq "$(HOST_OS)" "Linux"
+   HOST_TAG := linux-x86_64
+else ifeq "$(HOST_OS)" "Darwin"
+   HOST_TAG := darwin-x86_64
 else
-   # lowest supported 32-bit API level
-   API_LEVEL := 16
+   HOST_TAG := windows-x86_64
+endif
+
+TOOLCHAIN_SYSROOT := $(NDK_ROOT)/toolchains/llvm/prebuilt/$(HOST_TAG)/sysroot
+
+ifeq "$(wildcard $(TOOLCHAIN_SYSROOT)/.)" ""
+# Compiling test inferiors for Android requires an NDK with the unified
+# toolchain introduced in version r19.
+$(error "No unified toolchain sysroot found in $(NDK_ROOT). NDK must be r19 or 
later.")
 endif
 
 ifeq "$(ARCH)" "arm"
-   SYSROOT_ARCH := arm
-   STL_ARCH := armeabi-v7a
TRIPLE := armv7-none-linux-androideabi
ARCH_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -marm
 else ifeq "$(ARCH)" "aarch64"
-   SYSROOT_ARCH := arm64
-   STL_ARCH := arm64-v8a
TRIPLE := aarch64-none-linux-android
 else ifeq "$(ARCH)" "i386"
-   SYSROOT_ARCH := x86
-   STL_ARCH := x86
TRIPLE := i686-none-linux-android
 else
-   SYSROOT_ARCH := $(ARCH)
-   STL_ARCH := $(ARCH)
TRIPLE := $(ARCH)-none-linux-android
 endif
 
-ifeq "$(findstring 86,$(ARCH))" "86"
-   TOOLCHAIN_DIR := $(STL_ARCH)-4.9
-else ifeq "$(ARCH)" "arm"
-   TOOLCHAIN_DIR := arm-linux-androideabi-4.9
-else
-   TOOLCHAIN_DIR := $(subst -none,,$(TRIPLE))-4.9
-endif
+# lowest 64-bit API level
+API_LEVEL := 21
 
 ifeq "$(ARCH)" "arm"
-   TOOL_PREFIX := arm-linux-androideabi
-else
-   TOOL_PREFIX := $(subst -none,,$(TRIPLE))
-endif
-
-ifeq "$(HOST_OS)" "Linux"
-   HOST_TAG := linux-x86_64
-else ifeq "$(HOST_OS)" "Darwin"
-   HOST_TAG := darwin-x86_64
+   ARCH_DIR := arm-linux-androideabi
 else
-   HOST_TAG := windows-x86_64
-endif
-
-GCC_TOOLCHAIN = $(NDK_ROOT)/toolchains/$(TOOLCHAIN_DIR)/prebuilt/$(HOST_TAG)
-
-OBJCOPY ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-objcopy
-ARCHIVER ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-ar
-
-ifeq "$(findstring clang,$(CC))" "clang"
-   ARCH_CFLAGS += -target $(TRIPLE) --gcc-toolchain=$(GCC_TOOLCHAIN)
-   ARCH_LDFLAGS += -target $(TRIPLE) --gcc-toolchain=$(GCC_TOOLCHAIN)
+   ARCH_DIR := $(subst -none,,$(TRIPLE))
 endif
 
-ARCH_CFLAGS += --sysroot=$(NDK_ROOT)/sysroot \
-   -isystem $(NDK_ROOT)/sysroot/usr/include/$(TOOL_PREFIX) \
-   -D__ANDROID_API__=$(API_LEVEL) \
-   -isystem 
$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH)/usr/include
-
-ARCH_LDFLAGS += 
--sysroot=$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH) -lm
+ARCH_CFLAGS += \
+   --target=$(TRIPLE) \
+   --sysroot=$(TOOLCHAIN_SYSROOT) \
+   -D __ANDROID_API__=$(API_LEVEL) \
 
 ARCH_CXXFLAGS += \
-   -isystem $(NDK_ROOT)/sources/cxx-stl/llvm-libc++/include \
-   -isystem $(NDK_ROOT)/sources/android/support/include \
-   -isystem $(NDK_ROOT)/sources/cxx-stl/llvm-libc++abi/include
+   -isystem $(TOOLCHAIN_SYSROOT)/usr/include/c++/v1 \
 
 ARCH_LDFLAGS += \
-   -L$(NDK_ROOT)/sources/cxx-stl/llvm-libc++/libs/$(STL_ARCH) \
-   
$(NDK_ROOT)/sources/cxx-stl/llvm-libc++/libs/$(STL_ARCH)/libc++_static.a \
+   --target=$(TRIPLE) \
+   --sysroot=$(TOOLCHAIN_SYSROOT) \
+   --prefix=$(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/$(API_LEVEL) \
+   
--library-directory=$(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/$(API_LEVEL) \
+   $(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/libc++_static.a \
+   -lm \
-lc++abi \
-   -nostdlib++
+   -nostdlib++ \

labath wrote:

I get the diff benefits of this, but a backslash continuation at the end of a 
file looks very suspicious. I'd just remove all of the final backslashes you 
have here.

https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] lldb: get lldb API tests working with newer Android NDKs (PR #106443)

[Pavel Labath via lldb-commits]

@@ -1,81 +1,55 @@
 NDK_ROOT := $(shell dirname $(CC))/../../../../..
 
-ifeq "$(findstring 64, $(ARCH))" "64"
-   # lowest 64-bit API level
-   API_LEVEL := 21
-else ifeq "$(ARCH)" "i386"
-   # clone(2) declaration is present only since this api level
-   API_LEVEL := 17
+ifeq "$(HOST_OS)" "Linux"
+   HOST_TAG := linux-x86_64
+else ifeq "$(HOST_OS)" "Darwin"
+   HOST_TAG := darwin-x86_64
 else
-   # lowest supported 32-bit API level
-   API_LEVEL := 16
+   HOST_TAG := windows-x86_64
+endif
+
+TOOLCHAIN_SYSROOT := $(NDK_ROOT)/toolchains/llvm/prebuilt/$(HOST_TAG)/sysroot
+
+ifeq "$(wildcard $(TOOLCHAIN_SYSROOT)/.)" ""
+# Compiling test inferiors for Android requires an NDK with the unified
+# toolchain introduced in version r19.
+$(error "No unified toolchain sysroot found in $(NDK_ROOT). NDK must be r19 or 
later.")
 endif
 
 ifeq "$(ARCH)" "arm"
-   SYSROOT_ARCH := arm
-   STL_ARCH := armeabi-v7a
TRIPLE := armv7-none-linux-androideabi
ARCH_CFLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -marm
 else ifeq "$(ARCH)" "aarch64"
-   SYSROOT_ARCH := arm64
-   STL_ARCH := arm64-v8a
TRIPLE := aarch64-none-linux-android
 else ifeq "$(ARCH)" "i386"
-   SYSROOT_ARCH := x86
-   STL_ARCH := x86
TRIPLE := i686-none-linux-android
 else
-   SYSROOT_ARCH := $(ARCH)
-   STL_ARCH := $(ARCH)
TRIPLE := $(ARCH)-none-linux-android
 endif
 
-ifeq "$(findstring 86,$(ARCH))" "86"
-   TOOLCHAIN_DIR := $(STL_ARCH)-4.9
-else ifeq "$(ARCH)" "arm"
-   TOOLCHAIN_DIR := arm-linux-androideabi-4.9
-else
-   TOOLCHAIN_DIR := $(subst -none,,$(TRIPLE))-4.9
-endif
+# lowest 64-bit API level
+API_LEVEL := 21
 
 ifeq "$(ARCH)" "arm"
-   TOOL_PREFIX := arm-linux-androideabi
-else
-   TOOL_PREFIX := $(subst -none,,$(TRIPLE))
-endif
-
-ifeq "$(HOST_OS)" "Linux"
-   HOST_TAG := linux-x86_64
-else ifeq "$(HOST_OS)" "Darwin"
-   HOST_TAG := darwin-x86_64
+   ARCH_DIR := arm-linux-androideabi
 else
-   HOST_TAG := windows-x86_64
-endif
-
-GCC_TOOLCHAIN = $(NDK_ROOT)/toolchains/$(TOOLCHAIN_DIR)/prebuilt/$(HOST_TAG)
-
-OBJCOPY ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-objcopy
-ARCHIVER ?= $(GCC_TOOLCHAIN)/bin/$(TOOL_PREFIX)-ar
-
-ifeq "$(findstring clang,$(CC))" "clang"
-   ARCH_CFLAGS += -target $(TRIPLE) --gcc-toolchain=$(GCC_TOOLCHAIN)
-   ARCH_LDFLAGS += -target $(TRIPLE) --gcc-toolchain=$(GCC_TOOLCHAIN)
+   ARCH_DIR := $(subst -none,,$(TRIPLE))
 endif
 
-ARCH_CFLAGS += --sysroot=$(NDK_ROOT)/sysroot \
-   -isystem $(NDK_ROOT)/sysroot/usr/include/$(TOOL_PREFIX) \
-   -D__ANDROID_API__=$(API_LEVEL) \
-   -isystem 
$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH)/usr/include
-
-ARCH_LDFLAGS += 
--sysroot=$(NDK_ROOT)/platforms/android-$(API_LEVEL)/arch-$(SYSROOT_ARCH) -lm
+ARCH_CFLAGS += \
+   --target=$(TRIPLE) \
+   --sysroot=$(TOOLCHAIN_SYSROOT) \
+   -D __ANDROID_API__=$(API_LEVEL) \
 
 ARCH_CXXFLAGS += \
-   -isystem $(NDK_ROOT)/sources/cxx-stl/llvm-libc++/include \
-   -isystem $(NDK_ROOT)/sources/android/support/include \
-   -isystem $(NDK_ROOT)/sources/cxx-stl/llvm-libc++abi/include
+   -isystem $(TOOLCHAIN_SYSROOT)/usr/include/c++/v1 \
 
 ARCH_LDFLAGS += \
-   -L$(NDK_ROOT)/sources/cxx-stl/llvm-libc++/libs/$(STL_ARCH) \
-   
$(NDK_ROOT)/sources/cxx-stl/llvm-libc++/libs/$(STL_ARCH)/libc++_static.a \
+   --target=$(TRIPLE) \
+   --sysroot=$(TOOLCHAIN_SYSROOT) \
+   --prefix=$(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/$(API_LEVEL) \
+   
--library-directory=$(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/$(API_LEVEL) \

labath wrote:

```suggestion
-L$(TOOLCHAIN_SYSROOT)/usr/lib/$(ARCH_DIR)/$(API_LEVEL) \
```

I haven't seen anyone use the long version of this option (I had to look it up 
to be sure of what it does), so I think it'd be better to stick to `-L`. 
`--prefix` is probably ok, since its short form (`-B`) is also not very common.

https://github.com/llvm/llvm-project/pull/106443
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/104193

>From 7b8b8b699902d2365ea43e5ae015546c4d20fac8 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 14 Aug 2024 19:58:27 +0200
Subject: [PATCH 1/5] [lldb] Fix and speedup the `memory find` command

This patch fixes an issue where the `memory find` command would
effectively stop searching after encountering a memory read error (which
could happen due to unreadable memory), without giving any indication
that it has done so (it would just print it could not find the pattern).

To make matters worse, it would not terminate after encountering this
error, but rather proceed to slowly increment the address pointer, which
meant that searching a large region could take a very long time (and
give the appearance that lldb is actually searching for the thing).

The patch fixes this first problem (*) by detecting read errors and
skipping over (using GetMemoryRegionInfo) the unreadable parts of memory
and resuming the search after them. It also reads the memory in bulk (up
to 1MB), which speeds up the search significantly (up to 6x for live
processes, 18x for core files).

(*) The fix does not work on windows yet, because the ReadMemory API
does not return partial results (like it does for other systems). I'm
preparing a separate patch to deal with that.
---
 lldb/source/Target/Process.cpp| 68 +++
 .../memory/find/TestMemoryFind.py | 30 ++-
 .../API/functionalities/memory/find/main.cpp  | 83 +--
 3 files changed, 136 insertions(+), 45 deletions(-)

diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index b2a0f13b9a1549..5d066d264bd3f5 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -114,33 +114,6 @@ class ProcessOptionValueProperties
   }
 };
 
-class ProcessMemoryIterator {
-public:
-  ProcessMemoryIterator(Process &process, lldb::addr_t base)
-  : m_process(process), m_base_addr(base) {}
-
-  bool IsValid() { return m_is_valid; }
-
-  uint8_t operator[](lldb::addr_t offset) {
-if (!IsValid())
-  return 0;
-
-uint8_t retval = 0;
-Status error;
-if (0 == m_process.ReadMemory(m_base_addr + offset, &retval, 1, error)) {
-  m_is_valid = false;
-  return 0;
-}
-
-return retval;
-  }
-
-private:
-  Process &m_process;
-  const lldb::addr_t m_base_addr;
-  bool m_is_valid = true;
-};
-
 static constexpr OptionEnumValueElement g_follow_fork_mode_values[] = {
 {
 eFollowParent,
@@ -3367,21 +3340,48 @@ lldb::addr_t Process::FindInMemory(lldb::addr_t low, 
lldb::addr_t high,
   if (region_size < size)
 return LLDB_INVALID_ADDRESS;
 
+  // See "Boyer-Moore string search algorithm".
   std::vector bad_char_heuristic(256, size);
-  ProcessMemoryIterator iterator(*this, low);
-
   for (size_t idx = 0; idx < size - 1; idx++) {
 decltype(bad_char_heuristic)::size_type bcu_idx = buf[idx];
 bad_char_heuristic[bcu_idx] = size - idx - 1;
   }
-  for (size_t s = 0; s <= (region_size - size);) {
+
+  // Memory we're currently searching through.
+  llvm::SmallVector mem;
+  // Position of the memory buffer.
+  addr_t mem_pos = low;
+  // Maximum number of bytes read (and buffered). We need to read at least
+  // `size` bytes for a successful match.
+  const size_t max_read_size = std::max(size, 0x1);
+
+  for (addr_t s = low; s <= (high - size);) {
+if (s + size > mem.size() + mem_pos) {
+  // We need to read more data. We don't attempt to reuse the data we've
+  // already read (up to `size-1` bytes from `s` to `mem_pos+mem.size()`).
+  // This is fine for patterns much smaller than max_read_size. For very
+  // long patterns we may need to do something more elaborate.
+  mem.resize_for_overwrite(max_read_size);
+  Status error;
+  mem.resize(
+  ReadMemory(s, mem.data(), std::min(mem.size(), high - s), error));
+  mem_pos = s;
+  if (error.Fail() || size > mem.size()) {
+// We didn't read enough data. Skip to the next memory region.
+MemoryRegionInfo info;
+error = GetMemoryRegionInfo(mem_pos + mem.size(), info);
+if (error.Fail())
+  break;
+s = info.GetRange().GetRangeEnd();
+continue;
+  }
+}
 int64_t j = size - 1;
-while (j >= 0 && buf[j] == iterator[s + j])
+while (j >= 0 && buf[j] == mem[s + j - mem_pos])
   j--;
 if (j < 0)
-  return low + s;
-else
-  s += bad_char_heuristic[iterator[s + size - 1]];
+  return s; // We have a match.
+s += bad_char_heuristic[mem[s + size - 1 - mem_pos]];
   }
 
   return LLDB_INVALID_ADDRESS;
diff --git a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py 
b/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
index 09611cc808777d..72acfb3d600701 100644
--- a/lldb/test/API/functionalities/memory/find/TestMemoryFind.py
+++ b/lldb/test/API/functionalities/memory/fin

[Lldb-commits] [lldb] [lldb] Updated TCPSocket to listen multiple ports on the same single thread (PR #104797)

[Pavel Labath via lldb-commits]

labath wrote:

> @labath
> 
> > Having a single socket listen on multiple ports sounds like a bad idea to 
> > me.
> 
> Note that currently the class TCPSocket already contains a list of 
> NativeSocket `m_listen_sockets`.

I am aware of that, and I'm not entirely happy with how the class implements 
listening. I think it would be better to have a separate class for a listening 
socket, because those need a completely different APIs. But, even ignoring 
that, I think there's a difference between listening on two addresses with the 
same port (I believe the only way to reach that state is if a hostname resolves 
to multiple addresses, in which case one really could argue that it's the same 
"logical" address), and two addresses with completely unrelated ports.

> We do not need 2 TCPSocket instances with 2 separated lists of native sockets 
> even with a common MainLoop.
> 
> We have 2 options:
> 
> * A) 2 threads - first one calls TCPSocket::Accept() for the platform 
> connection, second calls TCPSocket::Accept() for the gdb connection
> 
> * B) 1 thread - a common TCPSocket::Accept() can accept platform and gdb 
> connections from both ports

We have (at least) three options, the third one being what I outlined in the 
previous message. I'm sorry this work of yours is going to waste. I could've 
been more explicit about what I wanted to do on the first PR, but I was more 
focused on what I don't want to do.

> 
> 
> I have implemented the option B. It was easy because the class TCPSocket 
> already contains `m_listen_sockets`.
> 
> > Then we could create two sockets and have them listen on the same main loop 
> > instance.
> 
> It is already implemented inside TCPSocket but for different addresses. 

That's true, but I draw a different conclusion from that. Instead of saying 
"this should be extended to support multiple ports", my take is that "this 
wasn't a good place for multiplexing to begin with".

> I just added different ports.
> 
> The changes are minimal really. 

Yes, but that's because you extended a stringly typed api to do that you 
wanted. That function is used from other places as well, and this means that 
other places in lldb (including user-facing code, I believe) can accept these 
multi-port connection strings. I don't think we want to support that.

https://github.com/llvm/llvm-project/pull/104797
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/linux] Make truncated reads work (PR #106532)

[Pavel Labath via lldb-commits]

https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/106532

Previously, we were returning an error if we couldn't read the whole region. 
This doesn't matter most of the time, because lldb caches memory reads, and in 
that process it aligns them to cache line boundaries. As (LLDB) cache lines are 
smaller than pages, the reads are unlikely to cross page boundaries.

Nonetheless, this can cause a problem for large reads (which bypass the cache), 
where we're unable to read anything even if just a single byte of the memory is 
unreadable. This patch fixes the lldb-server to do that, and also changes the 
linux implementation, to reuse any partial results it got from the 
process_vm_readv call (to avoid having to re-read everything again using 
ptrace, only to find that it stopped at the same place).

This matches debugserver behavior. It is also consistent with the gdb remote 
protocol documentation, but -- notably -- not with actual gdbserver behavior 
(which returns errors instead of partial results). We filed a
[clarification bug](https://sourceware.org/bugzilla/show_bug.cgi?id=24751) 
several years ago. Though we did not really reach a conclusion there, I think 
this is the most logical behavior.

The associated test does not currently pass on windows, because the windows 
memory read APIs don't support partial reads (I have a WIP patch to work around 
that).

>From 610757ced98139d3d10451dcca195692b0c2d832 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 29 Aug 2024 12:26:01 +0200
Subject: [PATCH] [lldb/linux] Make truncated reads work

Previously, we were returning an error if we couldn't read the whole
region. This doesn't matter most of the time, because lldb caches memory
reads, and in that process it aligns them to cache line boundaries. As
(LLDB) cache lines are smaller than pages, the reads are unlikely to
cross page boundaries.

Nonetheless, this can cause a problem for large reads (which bypass the
cache), where we're unable to read anything even if just a single byte
of the memory is unreadable. This patch fixes the lldb-server to do
that, and also changes the linux implementation, to reuse any partial
results it got from the process_vm_readv call (to avoid having to
re-read everything again using ptrace, only to find that it stopped at
the same place).

This matches debugserver behavior. It is also consistent with the gdb
remote protocol documentation, but -- notably -- not with actual
gdbserver behavior (which returns errors instead of partial results). We
filed a
[clarification bug](https://sourceware.org/bugzilla/show_bug.cgi?id=24751)
several years ago. Though we did not really reach a conclusion there, I
think this is the most logical behavior.

The associated test does not currently pass on windows, because the
windows memory read APIs don't support partial reads (I have a WIP patch
to work around that).
---
 .../Process/Linux/NativeProcessLinux.cpp  | 41 -
 .../GDBRemoteCommunicationServerLLGS.cpp  | 20 +
 .../API/functionalities/memory/holes/Makefile |  3 +
 .../memory/holes/TestMemoryHoles.py   | 63 ++
 .../API/functionalities/memory/holes/main.cpp | 87 +++
 5 files changed, 176 insertions(+), 38 deletions(-)
 create mode 100644 lldb/test/API/functionalities/memory/holes/Makefile
 create mode 100644 
lldb/test/API/functionalities/memory/holes/TestMemoryHoles.py
 create mode 100644 lldb/test/API/functionalities/memory/holes/main.cpp

diff --git a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp 
b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
index cb95da9fc72363..1e2e3a80b18bf6 100644
--- a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -1641,6 +1641,10 @@ 
NativeProcessLinux::GetSoftwareBreakpointTrapOpcode(size_t size_hint) {
 
 Status NativeProcessLinux::ReadMemory(lldb::addr_t addr, void *buf, size_t 
size,
   size_t &bytes_read) {
+  Log *log = GetLog(POSIXLog::Memory);
+  LLDB_LOG(log, "addr = {0}, buf = {1}, size = {2}", addr, buf, size);
+
+  bytes_read = 0;
   if (ProcessVmReadvSupported()) {
 // The process_vm_readv path is about 50 times faster than ptrace api. We
 // want to use this syscall if it is supported.
@@ -1651,32 +1655,29 @@ Status NativeProcessLinux::ReadMemory(lldb::addr_t 
addr, void *buf, size_t size,
 remote_iov.iov_base = reinterpret_cast(addr);
 remote_iov.iov_len = size;
 
-bytes_read = process_vm_readv(GetCurrentThreadID(), &local_iov, 1,
-  &remote_iov, 1, 0);
-const bool success = bytes_read == size;
+ssize_t read_result = process_vm_readv(GetCurrentThreadID(), &local_iov, 1,
+   &remote_iov, 1, 0);
+int error = 0;
+if (read_result < 0)
+  error = errno;
+else
+  bytes_read = read_result;
 
-Log *log = GetLog(POSIX

[Lldb-commits] [lldb] [lldb/linux] Make truncated reads work (PR #106532)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,63 @@
+"""
+Test the memory commands operating on memory regions with holes
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.decorators import *
+
+
+class MemoryHolesTestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+super().setUp()
+# Find the line number to break inside main().
+self.line = line_number("main.cpp", "// break here")
+
+def _prepare_inferior(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+# Break in main() after the variables are assigned values.
+lldbutil.run_break_set_by_file_and_line(
+self, "main.cpp", self.line, num_expected_locations=1, 
loc_exact=True
+)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+# The stop reason of the thread should be breakpoint.
+self.expect(
+"thread list",
+STOPPED_DUE_TO_BREAKPOINT,
+substrs=["stopped", "stop reason = breakpoint"],
+)
+
+# The breakpoint should have a hit count of 1.
+lldbutil.check_breakpoint(self, bpno=1, expected_hit_count=1)
+
+# Avoid the expression evaluator, as it can allocate allocate memory
+# inside the holes we've deliberately left empty.
+self.memory = 
self.frame().FindVariable("mem_with_holes").GetValueAsUnsigned()
+self.pagesize = 
self.frame().FindVariable("pagesize").GetValueAsUnsigned()
+positions = self.frame().FindVariable("positions")
+self.positions = [
+positions.GetChildAtIndex(i).GetValueAsUnsigned()
+for i in range(positions.GetNumChildren())
+]
+self.assertEqual(len(self.positions), 5)
+
+@expectedFailureWindows
+def test_memory_read(self):
+self._prepare_inferior()
+
+error = lldb.SBError()
+content = self.process().ReadMemory(self.memory, 2 * self.pagesize, 
error)
+self.assertEqual(len(content), self.pagesize)
+self.assertEqual(content[0:7], b"needle\0")
+self.assertTrue(error.Fail())
+self.assertEqual(
+f"memory read failed for {self.memory+self.pagesize:#x}", 
error.GetCString()
+)

labath wrote:

I guess this kind of error behavior can be useful in some situations (you get 
the memory that can be read *and* the error for the part that cannot), but I've 
found it very counterintuitive to use. I'd definitely be open to changing that 
(returning an error only if we didn't read anything).

https://github.com/llvm/llvm-project/pull/106532
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/linux] Make truncated reads work (PR #106532)

[Pavel Labath via lldb-commits]

@@ -2526,28 +2526,16 @@ GDBRemoteCommunicationServerLLGS::Handle_memory_read(
   size_t bytes_read = 0;
   Status error = m_current_process->ReadMemoryWithoutTrap(
   read_addr, &buf[0], byte_count, bytes_read);
-  if (error.Fail()) {
-LLDB_LOGF(log,
-  "GDBRemoteCommunicationServerLLGS::%s pid %" PRIu64
-  " mem 0x%" PRIx64 ": failed to read. Error: %s",
-  __FUNCTION__, m_current_process->GetID(), read_addr,
-  error.AsCString());
+  LLDB_LOG(log, "ReadMemoryWithoutTrap({0}) read {1}/{2} bytes (error: {3})",
+   read_addr, byte_count, bytes_read, error);
+  if (bytes_read == 0)

labath wrote:

This was changed to not assume that an error means nothing was read.

https://github.com/llvm/llvm-project/pull/106532
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb/linux] Make truncated reads work (PR #106532)

[Pavel Labath via lldb-commits]

https://github.com/labath updated 
https://github.com/llvm/llvm-project/pull/106532

>From 610757ced98139d3d10451dcca195692b0c2d832 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Thu, 29 Aug 2024 12:26:01 +0200
Subject: [PATCH 1/2] [lldb/linux] Make truncated reads work

Previously, we were returning an error if we couldn't read the whole
region. This doesn't matter most of the time, because lldb caches memory
reads, and in that process it aligns them to cache line boundaries. As
(LLDB) cache lines are smaller than pages, the reads are unlikely to
cross page boundaries.

Nonetheless, this can cause a problem for large reads (which bypass the
cache), where we're unable to read anything even if just a single byte
of the memory is unreadable. This patch fixes the lldb-server to do
that, and also changes the linux implementation, to reuse any partial
results it got from the process_vm_readv call (to avoid having to
re-read everything again using ptrace, only to find that it stopped at
the same place).

This matches debugserver behavior. It is also consistent with the gdb
remote protocol documentation, but -- notably -- not with actual
gdbserver behavior (which returns errors instead of partial results). We
filed a
[clarification bug](https://sourceware.org/bugzilla/show_bug.cgi?id=24751)
several years ago. Though we did not really reach a conclusion there, I
think this is the most logical behavior.

The associated test does not currently pass on windows, because the
windows memory read APIs don't support partial reads (I have a WIP patch
to work around that).
---
 .../Process/Linux/NativeProcessLinux.cpp  | 41 -
 .../GDBRemoteCommunicationServerLLGS.cpp  | 20 +
 .../API/functionalities/memory/holes/Makefile |  3 +
 .../memory/holes/TestMemoryHoles.py   | 63 ++
 .../API/functionalities/memory/holes/main.cpp | 87 +++
 5 files changed, 176 insertions(+), 38 deletions(-)
 create mode 100644 lldb/test/API/functionalities/memory/holes/Makefile
 create mode 100644 
lldb/test/API/functionalities/memory/holes/TestMemoryHoles.py
 create mode 100644 lldb/test/API/functionalities/memory/holes/main.cpp

diff --git a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp 
b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
index cb95da9fc72363..1e2e3a80b18bf6 100644
--- a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -1641,6 +1641,10 @@ 
NativeProcessLinux::GetSoftwareBreakpointTrapOpcode(size_t size_hint) {
 
 Status NativeProcessLinux::ReadMemory(lldb::addr_t addr, void *buf, size_t 
size,
   size_t &bytes_read) {
+  Log *log = GetLog(POSIXLog::Memory);
+  LLDB_LOG(log, "addr = {0}, buf = {1}, size = {2}", addr, buf, size);
+
+  bytes_read = 0;
   if (ProcessVmReadvSupported()) {
 // The process_vm_readv path is about 50 times faster than ptrace api. We
 // want to use this syscall if it is supported.
@@ -1651,32 +1655,29 @@ Status NativeProcessLinux::ReadMemory(lldb::addr_t 
addr, void *buf, size_t size,
 remote_iov.iov_base = reinterpret_cast(addr);
 remote_iov.iov_len = size;
 
-bytes_read = process_vm_readv(GetCurrentThreadID(), &local_iov, 1,
-  &remote_iov, 1, 0);
-const bool success = bytes_read == size;
+ssize_t read_result = process_vm_readv(GetCurrentThreadID(), &local_iov, 1,
+   &remote_iov, 1, 0);
+int error = 0;
+if (read_result < 0)
+  error = errno;
+else
+  bytes_read = read_result;
 
-Log *log = GetLog(POSIXLog::Process);
 LLDB_LOG(log,
- "using process_vm_readv to read {0} bytes from inferior "
- "address {1:x}: {2}",
- size, addr, success ? "Success" : llvm::sys::StrError(errno));
-
-if (success)
-  return Status();
-// else the call failed for some reason, let's retry the read using ptrace
-// api.
+ "process_vm_readv({0}, [iovec({1}, {2})], [iovec({3:x}, {2})], 1, 
"
+ "0) => {4} ({5})",
+ GetCurrentThreadID(), buf, size, addr, read_result,
+ error > 0 ? llvm::sys::StrError(errno) : "sucesss");
   }
 
   unsigned char *dst = static_cast(buf);
   size_t remainder;
   long data;
 
-  Log *log = GetLog(POSIXLog::Memory);
-  LLDB_LOG(log, "addr = {0}, buf = {1}, size = {2}", addr, buf, size);
-
-  for (bytes_read = 0; bytes_read < size; bytes_read += remainder) {
+  for (; bytes_read < size; bytes_read += remainder) {
 Status error = NativeProcessLinux::PtraceWrapper(
-PTRACE_PEEKDATA, GetCurrentThreadID(), (void *)addr, nullptr, 0, 
&data);
+PTRACE_PEEKDATA, GetCurrentThreadID(),
+reinterpret_cast(addr + bytes_read), nullptr, 0, &data);
 if (error.Fail())
   return error;
 
@@ -1684,11 +1685,7 @@ Status NativeProcessLinux::ReadMemory(lldb::addr_t addr, 
void *buf, 

[Lldb-commits] [lldb] [lldb] Fix and speedup the `memory find` command (PR #104193)

[Pavel Labath via lldb-commits]

labath wrote:

The linux read fix is in #106532.

https://github.com/llvm/llvm-project/pull/104193
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Better matching of types in anonymous namespaces (PR #102111)

[Pavel Labath via lldb-commits]

labath wrote:

Any more thoughts on this, @clayborg ?

https://github.com/llvm/llvm-project/pull/102111
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,120 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+cc = cc_path.as_posix()
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clamg-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir.as_posix())
+return llvm_tools_dir + "/" + util_name + exe_ext
+
+def getToolchainUtil(util_name):
+return (cc_dir / (cc_prefix + util_name + cc_ext)).as_posix()
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",
+"ARCHIVER": "ar",
+"DWP": "dwp",
+}
+utils = []
+
+# Note: LLVM_AR is currently required by API TestBSDArchives.py 
tests.
+# Assembly a full path to llvm-ar for given LLVM_TOOLS_DIR;
+# otherwise assume we have llvm-ar at the same place where is CC 
specified.
+if not os.getenv("LLVM_AR"):
+llvm_ar = getLlvmUtil("llvm-ar")
+utils.extend(['LLVM_AR="%s"' % llvm_ar])
+
+if not lldbplatformutil.platformIsDarwin():
+if os.getenv("USE_LLVM_TOOLS"):

labath wrote:

I'm still puzzled by this..

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,119 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clang-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir)
+return os.path.join(llvm_tools_dir, util_name + exe_ext)
+
+def getToolchainUtil(util_name):
+return cc_dir / (cc_prefix + util_name + cc_ext)
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",
+"ARCHIVER": "ar",
+"DWP": "dwp",
+}
+utils = []
+
+# Note: LLVM_AR is currently required by API TestBSDArchives.py 
tests.
+# Assembly a full path to llvm-ar for given LLVM_TOOLS_DIR;

labath wrote:

```suggestion
# Assemble a full path to llvm-ar for given LLVM_TOOLS_DIR;
```

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

Looks pretty good now, but I still have some questions.

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -213,7 +229,7 @@ endif
 LIMIT_DEBUG_INFO_FLAGS =
 NO_LIMIT_DEBUG_INFO_FLAGS =
 MODULE_DEBUG_INFO_FLAGS =
-ifneq (,$(findstring clang,$(CC)))
+ifeq ($(CCC), clang)

labath wrote:

So the last `C` stands for "type" ? :)

Can we call it CC_TYPE/KIND (or similar) instead? It's not like we're using it 
that often...

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,119 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:

labath wrote:

```suggestion
if not cc:
  return []
```

.. and then unindent the rest of the code

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Improve toolchain detection in Makefile.rules (PR #102185)

[Pavel Labath via lldb-commits]

@@ -96,16 +98,119 @@ def getArchSpec(self, architecture):
 """
 return ["ARCH=" + architecture] if architecture else []
 
-def getCCSpec(self, compiler):
+def getToolchainSpec(self, compiler):
 """
-Helper function to return the key-value string to specify the compiler
+Helper function to return the key-value strings to specify the 
toolchain
 used for the make system.
 """
 cc = compiler if compiler else None
 if not cc and configuration.compiler:
 cc = configuration.compiler
+
 if cc:
-return ['CC="%s"' % cc]
+exe_ext = ""
+if lldbplatformutil.getHostPlatform() == "windows":
+exe_ext = ".exe"
+
+cc = cc.strip()
+cc_path = pathlib.Path(cc)
+
+# We can get CC compiler string in the following formats:
+#  [] - such as 'xrun clang', 'xrun 
/usr/bin/clang' & etc
+#
+# Where  could contain the following parts:
+#   [.]   - sucn as 
'clang', 'clang.exe' ('clang-cl.exe'?)
+#   -[.]   - such as 
'armv7-linux-gnueabi-gcc'
+#   /[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+#   /-[.]- such as 
'/usr/bin/clang', 'c:\path\to\compiler\clang,exe'
+
+cc_ext = cc_path.suffix
+# Compiler name without extension
+cc_name = cc_path.stem.split(" ")[-1]
+
+# A kind of compiler (canonical name): clang, gcc, cc & etc.
+cc_type = cc_name
+# A triple prefix of compiler name: gcc
+cc_prefix = ""
+if not "clang-cl" in cc_name and not "llvm-gcc" in cc_name:
+cc_name_parts = cc_name.split("-")
+cc_type = cc_name_parts[-1]
+if len(cc_name_parts) > 1:
+cc_prefix = "-".join(cc_name_parts[:-1]) + "-"
+
+# A kind of C++ compiler.
+cxx_types = {
+"icc": "icpc",
+"llvm-gcc": "llvm-g++",
+"gcc": "g++",
+"cc": "c++",
+"clang": "clang++",
+}
+cxx_type = cxx_types.get(cc_type, cc_type)
+
+cc_dir = cc_path.parent
+
+def getLlvmUtil(util_name):
+llvm_tools_dir = os.getenv("LLVM_TOOLS_DIR", cc_dir)
+return os.path.join(llvm_tools_dir, util_name + exe_ext)
+
+def getToolchainUtil(util_name):
+return cc_dir / (cc_prefix + util_name + cc_ext)
+
+cxx = getToolchainUtil(cxx_type)
+
+util_names = {
+"OBJCOPY": "objcopy",
+"STRIP": "objcopy",

labath wrote:

Can we get rid of this variable? I don't think it's very helpful. Even though 
`objcopy` supports (I think) all of the functionality of `strip`, their args 
are different, so I think this could be pretty confusing.

https://github.com/llvm/llvm-project/pull/102185
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add Status::Detail to store expression evaluator diagnostics [… (PR #106442)

[Pavel Labath via lldb-commits]

labath wrote:

Not really (although this might work as well). What I meant was that, AIUI 
you're doing this so that you can plumb structured error information from one 
place (clang expression parser?) to another place (the thing which generates 
the expression errors -- I guess somewhere CommandObjectExpression?). That 
could be done by creating a (custom) llvm::Error in the first place, and 
consuming it in the second one *and* by making sure that all of the functions 
along that path don't lose this information by converting the error to a 
lldb_private::Status. I haven't looked at how hard much changes would that 
require, but I'm hoping that will be a single relatively well defined path that 
can be ported with reasonable effort. Even if there's e.g. a virtual function 
somewhere along the path, we don't necessarily have to port all implementations 
of that function immediately. We could just port the ones we need, and provide 
a shim so that the other implementations can remain unchanged...

https://github.com/llvm/llvm-project/pull/106442
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] aa73ee0 - [lldb/test] Use inline assembly for instruction counting tests

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-06T11:05:07+01:00
New Revision: aa73ee052fffb0d06c6b7d8caf0271652c07a80d

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

LOG: [lldb/test] Use inline assembly for instruction counting tests

We have a test which checks that instruction-step really steps one
instruction, but the way it checks this makes it very susceptible to
codegen changes. This rewrites the test inferior to use inline assembly,
which guarantees a known sequence of instructions that the test can
check. This does mean we have to write separate assembly for each
architecture, but that is no better than having architecture-specific
assertions, which the test was already starting to accumulate.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/main.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-server/main.cpp 
b/lldb/test/API/tools/lldb-server/main.cpp
index 992288355f15..399b5e9033b4 100644
--- a/lldb/test/API/tools/lldb-server/main.cpp
+++ b/lldb/test/API/tools/lldb-server/main.cpp
@@ -150,11 +150,39 @@ static void signal_handler(int signo) {
 }
 
 static void swap_chars() {
+#if defined(__x86_64__) || defined(__i386__)
+  asm volatile("movb %1, (%2)\n\t"
+   "movb %0, (%3)\n\t"
+   "movb %0, (%2)\n\t"
+   "movb %1, (%3)\n\t"
+   :
+   : "i"('0'), "i"('1'), "r"(&g_c1), "r"(&g_c2)
+   : "memory");
+#elif defined(__aarch64__)
+  asm volatile("strb %w1, [%2]\n\t"
+   "strb %w0, [%3]\n\t"
+   "strb %w0, [%2]\n\t"
+   "strb %w1, [%3]\n\t"
+   :
+   : "r"('0'), "r"('1'), "r"(&g_c1), "r"(&g_c2)
+   : "memory");
+#elif defined(__arm__)
+  asm volatile("strb %1, [%2]\n\t"
+   "strb %0, [%3]\n\t"
+   "strb %0, [%2]\n\t"
+   "strb %1, [%3]\n\t"
+   :
+   : "r"('0'), "r"('1'), "r"(&g_c1), "r"(&g_c2)
+   : "memory");
+#else
+#warning This may generate unpredictible assembly and cause the 
single-stepping test to fail.
+#warning Please add appropriate assembly for your target.
   g_c1 = '1';
   g_c2 = '0';
 
   g_c1 = '0';
   g_c2 = '1';
+#endif
 }
 
 static void hello() {



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

[Lldb-commits] [lldb] 92c0cda - [lldb/Disassembler] Move address resolution into the ParseInstructions function

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-06T11:23:41+01:00
New Revision: 92c0cda92847053297ad1f083f13469ff7b43871

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

LOG: [lldb/Disassembler] Move address resolution into the ParseInstructions 
function

The static Disassembler can be thought of as shorthands for three
operations:
- fetch an appropriate disassembler instance (FindPluginForTarget)
- ask it to dissassemble some bytes (ParseInstructions)
- ask it to dump the disassembled instructions (PrintInstructions)

The only thing that's standing in the way of this interpretation is that
the Disassemble function also does some address resolution before
calling ParseInstructions. This patch moves this functionality into
ParseInstructions so that it is available to users who call
ParseInstructions directly.

Added: 


Modified: 
lldb/include/lldb/Core/Disassembler.h
lldb/source/Core/Disassembler.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Disassembler.h 
b/lldb/include/lldb/Core/Disassembler.h
index 5975be096ff7..145bed31a155 100644
--- a/lldb/include/lldb/Core/Disassembler.h
+++ b/lldb/include/lldb/Core/Disassembler.h
@@ -428,10 +428,10 @@ class Disassembler : public 
std::enable_shared_from_this,
  uint32_t num_mixed_context_lines, uint32_t options,
  Stream &strm);
 
-  size_t ParseInstructions(Target &target, const AddressRange &range,
+  size_t ParseInstructions(Target &target, AddressRange range,
Stream *error_strm_ptr, bool prefer_file_cache);
 
-  size_t ParseInstructions(Target &target, const Address &range,
+  size_t ParseInstructions(Target &target, Address address,
uint32_t num_instructions, bool prefer_file_cache);
 
   virtual size_t DecodeInstructions(const Address &base_addr,

diff  --git a/lldb/source/Core/Disassembler.cpp 
b/lldb/source/Core/Disassembler.cpp
index df48469bb316..f5220288c8c1 100644
--- a/lldb/source/Core/Disassembler.cpp
+++ b/lldb/source/Core/Disassembler.cpp
@@ -104,9 +104,9 @@ DisassemblerSP Disassembler::FindPluginForTarget(const 
Target &target,
   return FindPlugin(arch, flavor, plugin_name);
 }
 
-static void ResolveAddress(Target &target, const Address &addr,
-   Address &resolved_addr) {
+static Address ResolveAddress(Target &target, const Address &addr) {
   if (!addr.IsSectionOffset()) {
+Address resolved_addr;
 // If we weren't passed in a section offset address range, try and resolve
 // it to something
 bool is_resolved = target.GetSectionLoadList().IsEmpty()
@@ -117,9 +117,9 @@ static void ResolveAddress(Target &target, const Address 
&addr,
 
 // We weren't able to resolve the address, just treat it as a raw address
 if (is_resolved && resolved_addr.IsValid())
-  return;
+  return resolved_addr;
   }
-  resolved_addr = addr;
+  return addr;
 }
 
 lldb::DisassemblerSP Disassembler::DisassembleRange(
@@ -170,12 +170,12 @@ Disassembler::DisassembleBytes(const ArchSpec &arch, 
const char *plugin_name,
 bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
const char *plugin_name, const char *flavor,
const ExecutionContext &exe_ctx,
-   const AddressRange &disasm_range,
+   const AddressRange &range,
uint32_t num_instructions,
bool mixed_source_and_assembly,
uint32_t num_mixed_context_lines,
uint32_t options, Stream &strm) {
-  if (!disasm_range.GetByteSize() || !exe_ctx.GetTargetPtr())
+  if (!range.GetByteSize() || !exe_ctx.GetTargetPtr())
 return false;
 
   lldb::DisassemblerSP disasm_sp(Disassembler::FindPluginForTarget(
@@ -184,10 +184,6 @@ bool Disassembler::Disassemble(Debugger &debugger, const 
ArchSpec &arch,
   if (!disasm_sp)
 return false;
 
-  AddressRange range;
-  ResolveAddress(exe_ctx.GetTargetRef(), disasm_range.GetBaseAddress(),
- range.GetBaseAddress());
-  range.SetByteSize(disasm_range.GetByteSize());
   const bool prefer_file_cache = false;
   size_t bytes_disassembled = disasm_sp->ParseInstructions(
   exe_ctx.GetTargetRef(), range, &strm, prefer_file_cache);
@@ -200,14 +196,11 @@ bool Disassembler::Disassemble(Debugger &debugger, const 
ArchSpec &arch,
   return true;
 }
 
-bool Disassembler::Disassemble(Debugger &debugger, const ArchSpec &arch,
-   const char *plugin_name, const char *flavor,
-   const ExecutionContext &exe_ctx,
-   const Address &start_address,
- 

[Lldb-commits] [lldb] af3db4e - [lldb] Reduce duplication in the Disassembler class

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-09T13:41:43+01:00
New Revision: af3db4e9aa8fbe7e43f89cdde780c6acc35368be

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

LOG: [lldb] Reduce duplication in the Disassembler class

Summary:
The class has two pairs of functions whose functionalities differ in
only how one specifies how much he wants to disasseble. One limits the
process by the size of the input memory region. The other based on the
total amount of instructions disassembled. They also differ in various
features (like error reporting) that were only added to one of the
versions.

There are various ways in which this could be addressed. This patch
does it by introducing a helper struct called "Limit", which is
effectively a pair specifying the value that you want to limit, and the
actual limit itself.

Reviewers: JDevlieghere

Subscribers: sdardis, jrtc27, atanasyan, lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/include/lldb/Core/Disassembler.h
lldb/source/Commands/CommandObjectDisassemble.cpp
lldb/source/Core/Disassembler.cpp
lldb/source/Plugins/Architecture/Mips/ArchitectureMips.cpp
lldb/source/Target/StackFrame.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Disassembler.h 
b/lldb/include/lldb/Core/Disassembler.h
index 145bed31a155..7ffdac74ccfc 100644
--- a/lldb/include/lldb/Core/Disassembler.h
+++ b/lldb/include/lldb/Core/Disassembler.h
@@ -384,6 +384,11 @@ class Disassembler : public 
std::enable_shared_from_this,
   const char *flavor,
   const char *plugin_name);
 
+  struct Limit {
+enum { Bytes, Instructions } kind;
+lldb::addr_t value;
+  };
+
   static lldb::DisassemblerSP
   DisassembleRange(const ArchSpec &arch, const char *plugin_name,
const char *flavor, Target &target,
@@ -395,19 +400,10 @@ class Disassembler : public 
std::enable_shared_from_this,
size_t length, uint32_t max_num_instructions,
bool data_from_file);
 
-  static bool Disassemble(Debugger &debugger, const ArchSpec &arch,
-  const char *plugin_name, const char *flavor,
-  const ExecutionContext &exe_ctx,
-  const AddressRange &range, uint32_t num_instructions,
-  bool mixed_source_and_assembly,
-  uint32_t num_mixed_context_lines, uint32_t options,
-  Stream &strm);
-
   static bool Disassemble(Debugger &debugger, const ArchSpec &arch,
   const char *plugin_name, const char *flavor,
   const ExecutionContext &exe_ctx, const Address 
&start,
-  uint32_t num_instructions,
-  bool mixed_source_and_assembly,
+  Limit limit, bool mixed_source_and_assembly,
   uint32_t num_mixed_context_lines, uint32_t options,
   Stream &strm);
 
@@ -423,17 +419,13 @@ class Disassembler : public 
std::enable_shared_from_this,
 
   void PrintInstructions(Debugger &debugger, const ArchSpec &arch,
  const ExecutionContext &exe_ctx,
- uint32_t num_instructions,
  bool mixed_source_and_assembly,
  uint32_t num_mixed_context_lines, uint32_t options,
  Stream &strm);
 
-  size_t ParseInstructions(Target &target, AddressRange range,
+  size_t ParseInstructions(Target &target, Address address, Limit limit,
Stream *error_strm_ptr, bool prefer_file_cache);
 
-  size_t ParseInstructions(Target &target, Address address,
-   uint32_t num_instructions, bool prefer_file_cache);
-
   virtual size_t DecodeInstructions(const Address &base_addr,
 const DataExtractor &data,
 lldb::offset_t data_offset,

diff  --git a/lldb/source/Commands/CommandObjectDisassemble.cpp 
b/lldb/source/Commands/CommandObjectDisassemble.cpp
index a11af68835d9..bd1c7a43afad 100644
--- a/lldb/source/Commands/CommandObjectDisassemble.cpp
+++ b/lldb/source/Commands/CommandObjectDisassemble.cpp
@@ -459,25 +459,19 @@ bool CommandObjectDisassemble::DoExecute(Args &command,
 
   bool print_sc_header = ranges.size() > 1;
   for (AddressRange cur_range : ranges) {
-bool success;
-if (m_options.num_instructions != 0) {
-  success = Disassembler::Disassemble(
-  GetDebugger(), m_options.arch, plugin_name, flavor_string, m_exe_ctx,
-  cur_range.GetBaseAddress(

[Lldb-commits] [lldb] c0b1af6 - [lldb] Return Unwinder& from Thread::GetUnwinder

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-09T14:13:22+01:00
New Revision: c0b1af6878444f075a17d87f523bc6be3343db35

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

LOG: [lldb] Return Unwinder& from Thread::GetUnwinder

The function always returns a valid object. Let the return type reflect
that, and remove some null checks.

Added: 


Modified: 
lldb/include/lldb/Target/StackFrameList.h
lldb/include/lldb/Target/Thread.h
lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
lldb/source/Plugins/Process/mach-core/ThreadMachCore.cpp
lldb/source/Target/StackFrameList.cpp
lldb/source/Target/Thread.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/StackFrameList.h 
b/lldb/include/lldb/Target/StackFrameList.h
index 44b389764bc6..be5e009e8a1e 100644
--- a/lldb/include/lldb/Target/StackFrameList.h
+++ b/lldb/include/lldb/Target/StackFrameList.h
@@ -94,7 +94,7 @@ class StackFrameList {
 
   void GetFramesUpTo(uint32_t end_idx);
 
-  void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind *unwinder);
+  void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind &unwinder);
 
   void SynthesizeTailCallFrames(StackFrame &next_frame);
 

diff  --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index 02e0d3369729..b0bc1b29eb78 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -1195,7 +1195,7 @@ class Thread : public 
std::enable_shared_from_this,
 
   typedef std::vector plan_stack;
 
-  virtual lldb_private::Unwind *GetUnwinder();
+  virtual Unwind &GetUnwinder();
 
   // Check to see whether the thread is still at the last breakpoint hit that
   // stopped it.

diff  --git a/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp 
b/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
index 9016e14f93b6..7469e7633e71 100644
--- a/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
+++ b/lldb/source/Plugins/Process/Utility/ThreadMemory.cpp
@@ -54,20 +54,14 @@ RegisterContextSP ThreadMemory::GetRegisterContext() {
 
 RegisterContextSP
 ThreadMemory::CreateRegisterContextForFrame(StackFrame *frame) {
-  RegisterContextSP reg_ctx_sp;
   uint32_t concrete_frame_idx = 0;
 
   if (frame)
 concrete_frame_idx = frame->GetConcreteFrameIndex();
 
-  if (concrete_frame_idx == 0) {
-reg_ctx_sp = GetRegisterContext();
-  } else {
-Unwind *unwinder = GetUnwinder();
-if (unwinder != nullptr)
-  reg_ctx_sp = unwinder->CreateRegisterContextForFrame(frame);
-  }
-  return reg_ctx_sp;
+  if (concrete_frame_idx == 0)
+return GetRegisterContext();
+  return GetUnwinder().CreateRegisterContextForFrame(frame);
 }
 
 bool ThreadMemory::CalculateStopInfo() {

diff  --git a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
index c3ae95a13b31..714090459cbb 100644
--- a/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -229,9 +229,7 @@ ThreadElfCore::CreateRegisterContextForFrame(StackFrame 
*frame) {
 
 reg_ctx_sp = m_thread_reg_ctx_sp;
   } else {
-Unwind *unwinder = GetUnwinder();
-if (unwinder != nullptr)
-  reg_ctx_sp = unwinder->CreateRegisterContextForFrame(frame);
+reg_ctx_sp = GetUnwinder().CreateRegisterContextForFrame(frame);
   }
   return reg_ctx_sp;
 }

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
index 7615ae290d0d..6deabf8d5d71 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
@@ -311,9 +311,7 @@ ThreadGDBRemote::CreateRegisterContextForFrame(StackFrame 
*frame) {
   read_all_registers_at_once, write_all_registers_at_once);
 }
   } else {
-Unwind *unwinder = GetUnwinder();
-if (unwinder != nullptr)
-  reg_ctx_sp = unwinder->CreateRegisterContextForFrame(frame);
+reg_ctx_sp = GetUnwinder().CreateRegisterContextForFrame(frame);
   }
   return reg_ctx_sp;
 }

diff  --git a/lldb/source/Plugins/Process/mach-core/ThreadMachCore.cpp 
b/lldb/source/Plugins/Process/mach-core/ThreadMachCore.cpp
index 4c3d2a5004a5..1950baea4127 100644
--- a/lldb/source/Plugins/Process/mach-core/ThreadMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ThreadMachCore.cpp
@@ -83,9 +83,7 @@ ThreadMachCore::CreateRegisterContextForFrame(StackFrame 
*frame) {
 }
 reg_ctx_sp = m_thread_reg_ctx_sp;
   } else {
-Unwind *unwinder = GetUnwinder();
-if (unwinder != nullptr)
-  reg_ctx_sp = unwinder->CreateRegisterContextForFrame(frame);
+

[Lldb-commits] [lldb] 24b1831 - [lldb] Fix windows&freebsd builds for c0b1af68

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-09T14:55:43+01:00
New Revision: 24b1831ebfb50a2ded01506049d6c1c2f34c4a27

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

LOG: [lldb] Fix windows&freebsd builds for c0b1af68

Added: 


Modified: 
lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.h
lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.h

Removed: 




diff  --git a/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp 
b/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
index 7d6ecf0b445a..c01ab750b948 100644
--- a/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
@@ -26,7 +26,6 @@
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
-#include "Plugins/Process/Utility/UnwindLLDB.h"
 #include "ProcessFreeBSD.h"
 #include "ProcessMonitor.h"
 #include "RegisterContextPOSIXProcessMonitor_arm.h"
@@ -254,8 +253,7 @@ 
FreeBSDThread::CreateRegisterContextForFrame(lldb_private::StackFrame *frame) {
   if (concrete_frame_idx == 0)
 reg_ctx_sp = GetRegisterContext();
   else {
-assert(GetUnwinder());
-reg_ctx_sp = GetUnwinder()->CreateRegisterContextForFrame(frame);
+reg_ctx_sp = GetUnwinder().CreateRegisterContextForFrame(frame);
   }
 
   return reg_ctx_sp;
@@ -275,13 +273,6 @@ bool FreeBSDThread::CalculateStopInfo() {
   return true;
 }
 
-Unwind *FreeBSDThread::GetUnwinder() {
-  if (!m_unwinder_up)
-m_unwinder_up.reset(new UnwindLLDB(*this));
-
-  return m_unwinder_up.get();
-}
-
 void FreeBSDThread::DidStop() {
   // Don't set the thread state to stopped unless we really stopped.
 }

diff  --git a/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.h 
b/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.h
index 6d3c253a519e..774ffb511bc6 100644
--- a/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.h
+++ b/lldb/source/Plugins/Process/FreeBSD/FreeBSDThread.h
@@ -102,8 +102,6 @@ class FreeBSDThread : public lldb_private::Thread {
   void ExitNotify(const ProcessMessage &message);
   void ExecNotify(const ProcessMessage &message);
 
-  lldb_private::Unwind *GetUnwinder() override;
-
   // FreeBSDThread internal API.
 
   // POSIXThread override

diff  --git 
a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp 
b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
index 8e700ced97e5..782edfe68279 100644
--- a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
+++ b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
@@ -15,7 +15,6 @@
 #include "lldb/Utility/Logging.h"
 #include "lldb/Utility/State.h"
 
-#include "Plugins/Process/Utility/UnwindLLDB.h"
 #include "ProcessWindows.h"
 #include "ProcessWindowsLog.h"
 #include "TargetThreadWindows.h"
@@ -113,9 +112,7 @@ 
TargetThreadWindows::CreateRegisterContextForFrame(StackFrame *frame) {
 }
 reg_ctx_sp = m_thread_reg_ctx_sp;
   } else {
-Unwind *unwinder = GetUnwinder();
-if (unwinder != nullptr)
-  reg_ctx_sp = unwinder->CreateRegisterContextForFrame(frame);
+reg_ctx_sp = GetUnwinder().CreateRegisterContextForFrame(frame);
   }
 
   return reg_ctx_sp;
@@ -126,14 +123,6 @@ bool TargetThreadWindows::CalculateStopInfo() {
   return true;
 }
 
-Unwind *TargetThreadWindows::GetUnwinder() {
-  // FIXME: Implement an unwinder based on the Windows unwinder exposed through
-  // DIA SDK.
-  if (!m_unwinder_up)
-m_unwinder_up.reset(new UnwindLLDB(*this));
-  return m_unwinder_up.get();
-}
-
 Status TargetThreadWindows::DoResume() {
   StateType resume_state = GetTemporaryResumeState();
   StateType current_state = GetState();

diff  --git a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.h 
b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.h
index fc68cb73db91..2845847738f6 100644
--- a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.h
+++ b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.h
@@ -34,7 +34,6 @@ class TargetThreadWindows : public lldb_private::Thread {
   lldb::RegisterContextSP
   CreateRegisterContextForFrame(StackFrame *frame) override;
   bool CalculateStopInfo() override;
-  Unwind *GetUnwinder() override;
 
   Status DoResume();
 



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

[Lldb-commits] [lldb] 34d7143 - [lldb] Fix windows build, second attempt

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-09T16:24:34+01:00
New Revision: 34d7143b035b3db64077968a09185834c1e7e9a7

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

LOG: [lldb] Fix windows build, second attempt

Added: 


Modified: 
lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp 
b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
index 782edfe68279..6d608b2b6ce3 100644
--- a/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
+++ b/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
@@ -11,6 +11,7 @@
 #include "lldb/Host/windows/HostThreadWindows.h"
 #include "lldb/Host/windows/windows.h"
 #include "lldb/Target/RegisterContext.h"
+#include "lldb/Target/Unwind.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/Logging.h"
 #include "lldb/Utility/State.h"



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

[Lldb-commits] [lldb] d00dff8 - [lldb] Make UnwindLLDB a non-plugin

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-10T13:56:15+01:00
New Revision: d00dff88b402ea9074b87aa5d3faddfd50c4bc0f

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

LOG: [lldb] Make UnwindLLDB a non-plugin

Summary:
This is the only real unwinder, and things have been this way for quite
a long time. At this point, the class has accumulated so many features
it is unlikely that anyone will want to reimplement the whole thing.

The class is also fairly closely coupled (through UnwindPlans and
FuncUnwinders) with a lot of other lldb components that it is hard to
imagine a different unwinder implementation being substantially
different without reimplementing all of those.

The existing unwinding functionality is nonetheless fairly complex and
there is space for adding more structure to it, but I believe a more
worthwhile effort would be to take the existing UnwindLLDB class and try
to break it down and introduce extension/customization points, instead
of writing a brand new Unwind implementation.

Reviewers: jasonmolenda, JDevlieghere, xiaobai

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

Added: 
lldb/include/lldb/Target/RegisterContextUnwind.h
lldb/include/lldb/Target/UnwindLLDB.h
lldb/source/Target/RegisterContextUnwind.cpp
lldb/source/Target/UnwindLLDB.cpp

Modified: 
lldb/source/Plugins/Process/Utility/CMakeLists.txt
lldb/source/Target/CMakeLists.txt
lldb/source/Target/Thread.cpp

Removed: 
lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp
lldb/source/Plugins/Process/Utility/UnwindLLDB.h



diff  --git a/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h 
b/lldb/include/lldb/Target/RegisterContextUnwind.h
similarity index 91%
rename from lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
rename to lldb/include/lldb/Target/RegisterContextUnwind.h
index 5bbc24c81c6a..6c91a649684e 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
+++ b/lldb/include/lldb/Target/RegisterContextUnwind.h
@@ -1,5 +1,4 @@
-//===-- RegisterContextLLDB.h *- 
C++
-//-*-===//
+//===-- RegisterContextUnwind.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.
@@ -7,32 +6,33 @@
 //
 
//===--===//
 
-#ifndef LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERCONTEXTLLDB_H
-#define LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERCONTEXTLLDB_H
+#ifndef LLDB_TARGET_REGISTERCONTEXTUNWIND_H
+#define LLDB_TARGET_REGISTERCONTEXTUNWIND_H
 
 #include 
 
-#include "UnwindLLDB.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Symbol/UnwindPlan.h"
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/RegisterNumber.h"
+#include "lldb/Target/UnwindLLDB.h"
 #include "lldb/lldb-private.h"
 
 namespace lldb_private {
 
 class UnwindLLDB;
 
-class RegisterContextLLDB : public lldb_private::RegisterContext {
+class RegisterContextUnwind : public lldb_private::RegisterContext {
 public:
-  typedef std::shared_ptr SharedPtr;
+  typedef std::shared_ptr SharedPtr;
 
-  RegisterContextLLDB(lldb_private::Thread &thread, const SharedPtr 
&next_frame,
-  lldb_private::SymbolContext &sym_ctx,
-  uint32_t frame_number,
-  lldb_private::UnwindLLDB &unwind_lldb);
+  RegisterContextUnwind(lldb_private::Thread &thread,
+const SharedPtr &next_frame,
+lldb_private::SymbolContext &sym_ctx,
+uint32_t frame_number,
+lldb_private::UnwindLLDB &unwind_lldb);
 
-  ~RegisterContextLLDB() override = default;
+  ~RegisterContextUnwind() override = default;
 
   void InvalidateAllRegisters() override;
 
@@ -247,13 +247,11 @@ class RegisterContextLLDB : public 
lldb_private::RegisterContext {
   m_registers; // where to find reg values for this frame
 
   lldb_private::UnwindLLDB &m_parent_unwind; // The UnwindLLDB that is creating
- // this RegisterContextLLDB
+ // this RegisterContextUnwind
 
-  // For RegisterContextLLDB only
-
-  DISALLOW_COPY_AND_ASSIGN(RegisterContextLLDB);
+  DISALLOW_COPY_AND_ASSIGN(RegisterContextUnwind);
 };
 
 } // namespace lldb_private
 
-#endif // LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERCONTEXTLLDB_H
+#endif // LLDB_TARGET_REGISTERCONTEXTUNWIND_H

diff  --git a/lldb/source/Plugins/

[Lldb-commits] [lldb] 1ca1e08 - [lldb] Break up CommandObjectDisassemble::DoExecute

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-10T14:03:16+01:00
New Revision: 1ca1e08e7544aea88d5978284a1c18086458d6c0

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

LOG: [lldb] Break up CommandObjectDisassemble::DoExecute

The function consisted of a complicated set of conditions to compute the
address ranges which are to be disassembled (depending on the mode
selected by command line switches). This patch creates a separate
function for each mode, so that DoExecute is only left with the task of
figuring out how to dump the relevant ranges.

This is NFC-ish, except for one change in the error message, which is
actually an improvement.

Added: 


Modified: 
lldb/source/Commands/CommandObjectDisassemble.cpp
lldb/source/Commands/CommandObjectDisassemble.h
lldb/test/Shell/Commands/command-disassemble.s

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectDisassemble.cpp 
b/lldb/source/Commands/CommandObjectDisassemble.cpp
index bd1c7a43afad..511cd6995404 100644
--- a/lldb/source/Commands/CommandObjectDisassemble.cpp
+++ b/lldb/source/Commands/CommandObjectDisassemble.cpp
@@ -214,6 +214,165 @@ CommandObjectDisassemble::CommandObjectDisassemble(
 
 CommandObjectDisassemble::~CommandObjectDisassemble() = default;
 
+llvm::Expected>
+CommandObjectDisassemble::GetContainingAddressRanges() {
+  std::vector ranges;
+  const auto &get_range = [&](Address addr) {
+ModuleSP module_sp(addr.GetModule());
+SymbolContext sc;
+bool resolve_tail_call_address = true;
+addr.GetModule()->ResolveSymbolContextForAddress(
+addr, eSymbolContextEverything, sc, resolve_tail_call_address);
+if (sc.function || sc.symbol) {
+  AddressRange range;
+  sc.GetAddressRange(eSymbolContextFunction | eSymbolContextSymbol, 0,
+ false, range);
+  ranges.push_back(range);
+}
+  };
+
+  Target &target = GetSelectedTarget();
+  if (!target.GetSectionLoadList().IsEmpty()) {
+Address symbol_containing_address;
+if (target.GetSectionLoadList().ResolveLoadAddress(
+m_options.symbol_containing_addr, symbol_containing_address)) {
+  get_range(symbol_containing_address);
+}
+  } else {
+for (lldb::ModuleSP module_sp : target.GetImages().Modules()) {
+  Address file_address;
+  if (module_sp->ResolveFileAddress(m_options.symbol_containing_addr,
+file_address)) {
+get_range(file_address);
+  }
+}
+  }
+
+  if (ranges.empty()) {
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+"Could not find function bounds for address 0x%" PRIx64,
+m_options.symbol_containing_addr);
+  }
+  return ranges;
+}
+
+llvm::Expected>
+CommandObjectDisassemble::GetCurrentFunctionRanges() {
+  StackFrame *frame = m_exe_ctx.GetFramePtr();
+  if (!frame) {
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "Cannot disassemble around the current "
+   "function without a selected frame.\n");
+  }
+  SymbolContext sc(
+  frame->GetSymbolContext(eSymbolContextFunction | eSymbolContextSymbol));
+  AddressRange range;
+  if (sc.function)
+range = sc.function->GetAddressRange();
+  else if (sc.symbol && sc.symbol->ValueIsAddress()) {
+range = {sc.symbol->GetAddress(), sc.symbol->GetByteSize()};
+  } else
+range = {frame->GetFrameCodeAddress(), DEFAULT_DISASM_BYTE_SIZE};
+
+  return std::vector{range};
+}
+
+llvm::Expected>
+CommandObjectDisassemble::GetCurrentLineRanges() {
+  StackFrame *frame = m_exe_ctx.GetFramePtr();
+  if (!frame) {
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "Cannot disassemble around the current "
+   "line without a selected frame.\n");
+  }
+
+  LineEntry pc_line_entry(
+  frame->GetSymbolContext(eSymbolContextLineEntry).line_entry);
+  if (pc_line_entry.IsValid())
+return std::vector{pc_line_entry.range};
+
+  // No line entry, so just disassemble around the current pc
+  m_options.show_mixed = false;
+  return GetPCRanges();
+}
+
+llvm::Expected>
+CommandObjectDisassemble::GetNameRanges() {
+  ConstString name(m_options.func_name.c_str());
+  const bool include_symbols = true;
+  const bool include_inlines = true;
+
+  // Find functions matching the given name.
+  SymbolContextList sc_list;
+  GetSelectedTarget().GetImages().FindFunctions(
+  name, eFunctionNameTypeAuto, include_symbols, include_inlines, sc_list);
+
+  std::vector ranges;
+  AddressRange range;
+  const uint32_t scope =
+  eSymbolContextBlock | eSymbolContextFunction | eSymbolContextSymbol;
+  const bool use_inline_block_range = true;
+  for (Symb

[Lldb-commits] [lldb] 6b37c47 - [lldb] Improve test failure messages in vscode tests

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-10T14:32:45+01:00
New Revision: 6b37c476a2d4e63f6c02ca8996e0e92ae3db3282

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

LOG: [lldb] Improve test failure messages in vscode tests

A couple of tests sporadically fail on these assertions, but the error
messages do not give a clue as to what has actually happened.

Improve them so that we can better understand what is going wrong.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
index 1eb23ce56212..54f09e2cdbee 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
@@ -230,11 +230,11 @@ def continue_to_exception_breakpoint(self, filter_label):
 def continue_to_exit(self, exitCode=0):
 self.vscode.request_continue()
 stopped_events = self.vscode.wait_for_stopped()
-self.assertTrue(len(stopped_events) == 1,
-"expecting single 'exited' event")
-self.assertTrue(stopped_events[0]['event'] == 'exited',
+self.assertEquals(len(stopped_events), 1,
+"stopped_events = {}".format(stopped_events))
+self.assertEquals(stopped_events[0]['event'], 'exited',
 'make sure program ran to completion')
-self.assertTrue(stopped_events[0]['body']['exitCode'] == exitCode,
+self.assertEquals(stopped_events[0]['body']['exitCode'], exitCode,
 'exitCode == %i' % (exitCode))
 
 def attach(self, program=None, pid=None, waitFor=None, trace=None,



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

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

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-16T12:12:59+01:00
New Revision: 5abfa3226da67cf00cefe6365ec62049a7592e61

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

LOG: [lldb/DWARF] Fix crash when a dwo compile unit refers to a non-dwo type

In this case dwo_num can be None => stop assuming it can't.

Added: 
lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s

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

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
index cfb841621566..da8fec46dba7 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -125,7 +125,7 @@ SymbolFileDWARFDwo::GetTypeSystemForLanguage(LanguageType 
language) {
 
 DWARFDIE
 SymbolFileDWARFDwo::GetDIE(const DIERef &die_ref) {
-  if (*die_ref.dwo_num() == GetDwoNum())
+  if (die_ref.dwo_num() == GetDwoNum())
 return DebugInfo().GetDIE(die_ref);
   return GetBaseSymbolFile().GetDIE(die_ref);
 }

diff  --git a/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s 
b/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s
new file mode 100644
index ..26d8b56ccf06
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s
@@ -0,0 +1,178 @@
+# This tests the scenario where a (split) compile unit contains reference to a
+# type, but that type is defined in another compile unit in the main object
+# file.
+
+# RUN: llvm-mc %s -o %t --filetype=obj --defsym MAIN=0
+# RUN: llvm-mc %s -o %T/dwo-type-in-main-file-cu2.dwo --filetype=obj --defsym 
DWO=0
+# RUN: cd %T
+# RUN: %lldb %t -o "target var a" -b 2>&1 | FileCheck %s
+
+# CHECK: (A) a = (b = 47)
+
+.ifdef MAIN
+.type   a,@object   # @a
+.data
+.globl  a
+.quad   0 # padding
+a:
+.long   47  # 0x2f
+.size   a, 4
+
+.section.debug_addr,"",@progbits
+.Laddr_table_base0:
+.quad   a
+
+.section.debug_info,"",@progbits
+.Lcu_begin0:
+.long   .Ldebug_info_end0-.Ldebug_info_start0 # Length of Unit
+.Ldebug_info_start0:
+.short  4   # DWARF version number
+.long   .debug_abbrev   # Offset Into Abbrev. Section
+.byte   8   # Address Size (in bytes)
+.byte   1   # Abbrev [1] 0xb:0x89 
DW_TAG_compile_unit
+.asciz  "Hand-written DWARF"# DW_AT_producer
+.asciz  "cu1.cc"# DW_AT_name
+.byte   2   # Abbrev [2] 0x2a:0x2d 
DW_TAG_structure_type
+.asciz  "A" # DW_AT_name
+.byte   4   # DW_AT_byte_size
+.byte   3   # Abbrev [3] 0x33:0xc DW_TAG_member
+.asciz  "b" # DW_AT_name
+.long   .Lint   # DW_AT_type
+.byte   0   # DW_AT_data_member_location
+.byte   0   # End Of Children Mark
+.Lint:
+.byte   7   # Abbrev [7] 0x57:0x7 DW_TAG_base_type
+.asciz  "int"   # DW_AT_name
+.byte   5   # DW_AT_encoding
+.byte   4   # DW_AT_byte_size
+.byte   0   # End Of Children Mark
+.Ldebug_info_end0:
+
+.Lcu_begin1:
+.long   .Ldebug_info_end1-.Ldebug_info_start1 # Length of Unit
+.Ldebug_info_start1:
+.short  4   # DWARF version number
+.long   .debug_abbrev   # Offset Into Abbrev. Section
+.byte   8   # Address Size (in bytes)
+.byte   8   # Abbrev DW_TAG_compile_unit
+.asciz  "dwo-type-in-main-file-cu2.dwo" # DW_AT_GNU_dwo_name
+.quad   5578312047953902346 # DW_AT_GNU_dwo_id
+.long   .Laddr_table_base0  # DW_AT_GNU_addr_base
+.Ldebug_info_end1:
+
+.section.debug_abbrev,"",@progbits
+.byte   1   # Abbreviation Code
+.byte   17  # DW_TAG_compile_unit
+.byte   1   # DW_CHILDREN_yes
+.byte   37  # DW_AT_producer
+.byte   8   # DW_FORM_string
+.byte   3   # DW_AT_name
+.byte   8   # DW_FORM_string
+.byte   0   # EOM(1)
+.byte   0   # EOM(2)
+.byte   2   # Abbreviation Code
+.byte   19  # DW_TAG_struc

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

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-16T13:25:10+01:00
New Revision: c5ff3df839321847ab7558ffb292f725d0356dfe

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

LOG: [lldb] Hardcode target in dwo-type-in-main-file.s test

Added: 


Modified: 
lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s

Removed: 




diff  --git a/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s 
b/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s
index 26d8b56ccf06..3b6d52c9042a 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/dwo-type-in-main-file.s
@@ -2,8 +2,10 @@
 # type, but that type is defined in another compile unit in the main object
 # file.
 
-# RUN: llvm-mc %s -o %t --filetype=obj --defsym MAIN=0
-# RUN: llvm-mc %s -o %T/dwo-type-in-main-file-cu2.dwo --filetype=obj --defsym 
DWO=0
+# REQUIRES: x86
+
+# RUN: llvm-mc %s -o %t --triple=x86_64-pc-linux --filetype=obj --defsym MAIN=0
+# RUN: llvm-mc %s -o %T/dwo-type-in-main-file-cu2.dwo --triple=x86_64-pc-linux 
--filetype=obj --defsym DWO=0
 # RUN: cd %T
 # RUN: %lldb %t -o "target var a" -b 2>&1 | FileCheck %s
 



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

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

[Pavel Labath via lldb-commits]

[Splitting this off to not derail the review]

On 14/03/2020 00:45, Greg Clayton via Phabricator wrote:
> labath wrote:
>> This will return a dangling pointer as Envp is a temporary object. It's 
>> intended to be used to pass the environment object to execve-like function. 
>> The current "state of the art" is to ConstStringify all temporary strings 
>> that go out of the SB api. (Though I think we should start using 
>> std::string).
>>
>> Also, constructing the Envp object just to fetch a single string out of it 
>> is pretty expensive. You can fetch the desired result from the Environment 
>> object directly.
>>
>> Putting it all together, this kind of an API would be implemented via 
>> something like:
>> ```
>>   if (idx >= m_opaque_up->size())
>> return nullptr;
>>   return ConstString(Environment::compose(*std::next(m_opaque_up.begin(), 
>> idx)).AsCString();
>> ```
>>
>> ... but I am not sure this is really the right api. More on that in a 
>> separate comment.
> Yes, any C strings returned from the SB API should use 
> ConstString(cstr).AsCString() as the ConstString puts the string into a 
> string pool and there is no need to clients to destruct the string or take 
> ownership.
> 
> No STL in the SB API please, so no std::string. std::string isn't stable on 
> all platforms and competing C++ runtimes on different platforms can cause 
> problems. If we need string ownership, we can introduce SBString as a class.

What do you exactly mean by "not stable"? All major C++ standard
libraries I have knowledge of (libstdc++, libc++, msvc stl) take abi
stability very seriously (more seriously than we do for SB api).

I can see how returning std::strings would be a problem if one builds
liblldb with one c++ library (say libstdc++) and then tries to build the
dependant program with libc++ (are those the competing runtimes you
mentioned?), but.. is that something we have signed up to support?

The main reason I am even thinking about this is because swig already
knows how to map common stl types onto native types of other languages.
This is particularly important if we are going to have multiple
scripting languages, as we wouldn't need to redo the mapping for each
script language and each stl-like class we have (e.g. all SBXXXLists)

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

[Lldb-commits] [lldb] 089cfe1 - Improve step over performance

[Pavel Labath via lldb-commits]

Author: Jaroslav Sevcik
Date: 2020-03-20T11:41:56+01:00
New Revision: 089cfe113da1395427dd31f21067d5b618b89d7c

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

LOG: Improve step over performance

Summary:
This patch improves step over performance for the case when we are
stepping over a call with a next-branch-breakpoint (see
https://reviews.llvm.org/D58678), and we encounter a stop during the
call. Currently, this causes the thread plan to step-out //each frame//
until it reaches the step-over range. This is a regression introduced by
https://reviews.llvm.org/D58678 (which did improve other things!). Prior
to that change, the step-over plan would always step-out just once.

With this patch, if we find ourselves stopped in a deeper stack frame
and we already have a next branch breakpoint, we simply return from the
step-over plan's ShouldStop handler without pushing the step out plan.

In my experiments this improved the time of stepping over a call that
loads 12 dlls from 14s to 5s. This was in remote debugging scenario with
10ms RTT, the call in question was Vulkan initialization
(vkCreateInstance), which loads various driver dlls. Loading those dlls
must stop on the rendezvous breakpoint, causing the perf problem
described above.

Reviewers: clayborg, labath, jingham

Reviewed By: jingham

Subscribers: lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Target/ThreadPlanStepOverRange.cpp

Removed: 




diff  --git a/lldb/source/Target/ThreadPlanStepOverRange.cpp 
b/lldb/source/Target/ThreadPlanStepOverRange.cpp
index efffcb165018..37795176119a 100644
--- a/lldb/source/Target/ThreadPlanStepOverRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepOverRange.cpp
@@ -171,6 +171,10 @@ bool ThreadPlanStepOverRange::ShouldStop(Event *event_ptr) 
{
   const SymbolContext &older_context =
   older_frame_sp->GetSymbolContext(eSymbolContextEverything);
   if (IsEquivalentContext(older_context)) {
+// If we have the  next-branch-breakpoint in the range, we can just
+// rely on that breakpoint to trigger once we return to the range.
+if (m_next_branch_bp_sp)
+  return false;
 new_plan_sp = m_thread.QueueThreadPlanForStepOutNoShouldStop(
 false, nullptr, true, stop_others, eVoteNo, eVoteNoOpinion, 0,
 m_status, true);



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

Re: [Lldb-commits] [lldb] b4a6e63 - [lldb/Target] Rework the way the inferior environment is created

[Pavel Labath via lldb-commits]

On 23/03/2020 17:17, Frédéric Riss via lldb-commits wrote:
> The new testing for “inherit-env=false” is failing on Windows. I skipped the 
> test for now.
> 
> Could it be that it never worked there? (In which case XFail would be a 
> better resolution)
> Does anyone have easy access to a Windows build to try it out?
> 
> Thanks,
> Fred

My guess is that this "defensive check"

prevents us from passing a completely blank environment. I am tempted to
just delete it and see what happens, but maybe Adrian is able to do a
quick test of this?

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

[Lldb-commits] [lldb] c726753 - [lldb] add lit.local.cfg for breakpad tests

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-25T17:00:46+01:00
New Revision: c72675394a8592dbe9733c6eef305d094f7f8119

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

LOG: [lldb] add lit.local.cfg for breakpad tests

The reason is to add .yaml as a valid test suffix. The test folder
contains one yaml file, which wasn't being run because of that.

Unsurprisingly the test fails, but this was not because the underlying
functionality was broken, but rather because the test was setup
incorrectly (most likely due to overly aggressive simplification of the
test data on my part).

Therefore this patch also tweaks the test inputs in order to test what
they are supposed to test, and also updates some other breakpad tests
(because they depend on the same inputs as this one) to be more
realistic -- specifically it avoids putting symbols to the first page of
the module, as that's where normally the COFF header would reside.

Added: 
lldb/test/Shell/SymbolFile/Breakpad/lit.local.cfg

Modified: 
lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms
lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.syms
lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.yaml
lldb/test/Shell/SymbolFile/Breakpad/unwind-via-raSearch.test
lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win-no-memory-info.yaml
lldb/test/Shell/SymbolFile/Breakpad/unwind-via-stack-win.test

Removed: 




diff  --git 
a/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms 
b/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms
index 329a280bde85..eb4d615da044 100644
--- a/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms
+++ b/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-raSearch.syms
@@ -1,15 +1,15 @@
 MODULE windows x86 897DD83EA8C8411897F3A925EE4BF7411 unwind-via-stack-win.pdb
 INFO CODE_ID 5D499B5C5000 unwind-via-stack-win.exe
-PUBLIC  0 0 dummy
-PUBLIC 10 0 call_many
-PUBLIC 80 0 main
-PUBLIC 90 0 many_pointer_args
-PUBLIC 100 0 complex_rasearch
-PUBLIC 110 0 esp_rasearch
-PUBLIC 120 0 nonzero_frame_size
-STACK WIN 4 10 6d 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 80 8 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 90 5 0 0 50 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 100 4 0 0 0 0 0 0 1 $T0 .raSearch 80 + = $eip $T0 ^ = $esp $T0 4 + 
=
-STACK WIN 4 110 4 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp .raSearch 4 
+ =
-STACK WIN 4 120 4 0 0 0 4 8 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
+PUBLIC 1000  0 dummy
+PUBLIC 1010 0 call_many
+PUBLIC 1080 0 main
+PUBLIC 1090 0 many_pointer_args
+PUBLIC 1100 0 complex_rasearch
+PUBLIC 1110 0 esp_rasearch
+PUBLIC 1120 0 nonzero_frame_size
+STACK WIN 4 1010 6d 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
+STACK WIN 4 1080 8 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
+STACK WIN 4 1090 5 0 0 50 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =
+STACK WIN 4 1100 4 0 0 0 0 0 0 1 $T0 .raSearch 80 + = $eip $T0 ^ = $esp $T0 4 
+ =
+STACK WIN 4 1110 4 0 0 0 0 0 0 1 $T0 .raSearch = $eip $T0 ^ = $esp .raSearch 4 
+ =
+STACK WIN 4 1120 4 0 0 0 4 8 0 1 $T0 .raSearch = $eip $T0 ^ = $esp $T0 4 + =

diff  --git 
a/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.syms 
b/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.syms
index b9b8a67095f0..24b6a21c9232 100644
--- a/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.syms
+++ b/lldb/test/Shell/SymbolFile/Breakpad/Inputs/unwind-via-stack-win.syms
@@ -1,17 +1,17 @@
 MODULE windows x86 897DD83EA8C8411897F3A925EE4BF7411 unwind-via-stack-win.pdb
 INFO CODE_ID 5D499B5C5000 unwind-via-stack-win.exe
-PUBLIC  0 0 dummy
-PUBLIC 10 0 call_many
-PUBLIC 80 0 main
-PUBLIC 90 0 many_pointer_args
-PUBLIC 100 0 bogus_rule
-PUBLIC 110 0 bogus_cfa_rhs
-PUBLIC 120 0 bogus_esp_rhs
-PUBLIC 130 0 temporary_var
-STACK WIN 4 10 6d 0 0 0 0 0 0 1 $T0 $esp 80 + = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 80 8 0 0 0 0 0 0 1 $T0 $esp = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 90 5 0 0 50 0 0 0 1 $T0 $esp = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 100 4 0 0 0 0 0 0 1 bogus
-STACK WIN 4 110 4 0 0 0 0 0 0 1 $T0 $bogus = $eip $T0 ^ = $esp $T0 4 + =
-STACK WIN 4 120 4 0 0 0 0 0 0 1 $T0 $esp = $eip $T0 ^ = $esp $bogus 4 + =
-STACK WIN 4 130 4 0 0 0 0 0 0 1 $T0 $esp = $bogus $T0 = $eip $bogus ^ = $esp 
$T0 4 + =
+PUBLIC 1000 0 dummy
+PUBLIC 1010 0 call_many
+PUBLIC 1080 0 main
+PUBLIC 1090 0 many_pointer_args
+PUBLIC 1100 0 bogus_rule
+PUBLIC 1110 0 bogus_cfa_rhs
+PUBLIC 1120 0 bogus_esp_rhs
+PUBLIC 1130 0 temporary_var
+STACK WIN 4 1010 6d 0 0 0 0 0 0 1 $T0 $esp 80 + = $eip $T0 ^ = $esp $T0 4 + =
+STACK WIN 4 1080 8 0 0 0 0 0 

[Lldb-commits] [lldb] 703a856 - [lldb] Fix TestVSCode_completions for clang 159a9f7

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-26T10:24:33+01:00
New Revision: 703a856a1005b651a9087ad16b6df2cc19883dc0

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

LOG: [lldb] Fix TestVSCode_completions for clang 159a9f7

Printing of types has changed slightly.

Also improve the error messages the test gives when it fails.

Added: 


Modified: 
lldb/test/API/tools/lldb-vscode/completions/TestVSCode_completions.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-vscode/completions/TestVSCode_completions.py 
b/lldb/test/API/tools/lldb-vscode/completions/TestVSCode_completions.py
index 155d476bb58a..06ab8f414549 100644
--- a/lldb/test/API/tools/lldb-vscode/completions/TestVSCode_completions.py
+++ b/lldb/test/API/tools/lldb-vscode/completions/TestVSCode_completions.py
@@ -17,10 +17,10 @@ class 
TestVSCode_variables(lldbvscode_testcase.VSCodeTestCaseBase):
 
 def verify_completions(self, actual_list, expected_list, 
not_expected_list=[]):
 for expected_item in expected_list:
-self.assertTrue(expected_item in actual_list)
+self.assertIn(expected_item, actual_list)
 
 for not_expected_item in not_expected_list:
-self.assertFalse(not_expected_item in actual_list)
+self.assertNotIn(not_expected_item, actual_list)
 
 @skipIfWindows
 @skipIfDarwin # Skip this test for now until we can figure out why tings 
aren't working on build bots
@@ -44,7 +44,7 @@ def test_completions(self):
 [
 {
 "text": "var",
-"label": "var -- vector, allocator >, allocator, allocator > > > &",
+"label": "var -- vector, allocator>, allocator, allocator>>> &",
 }
 ],
 [{"text": "var1", "label": "var1 -- int &"}],



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

[Lldb-commits] [lldb] 57be22f - [LLDB] Fix parsing of IPv6 host:port inside brackets

[Pavel Labath via lldb-commits]

Author: Emre Kultursay
Date: 2020-03-26T11:35:54+01:00
New Revision: 57be22fa179703b78b1807217b72eaffa0c518bf

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

LOG: [LLDB] Fix parsing of IPv6 host:port inside brackets

Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601:1234:...:0213]:, and the UriParser
can handle this format.

However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.

Test: BracketedHostnameWithPortIPv6 covers the case mentioned above

Reviewers: #lldb, labath

Reviewed By: labath

Subscribers: kwk, shafik, lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Utility/UriParser.cpp
lldb/unittests/Utility/UriParserTest.cpp

Removed: 




diff  --git a/lldb/source/Utility/UriParser.cpp 
b/lldb/source/Utility/UriParser.cpp
index a6172caa8c5c..8169b0eee121 100644
--- a/lldb/source/Utility/UriParser.cpp
+++ b/lldb/source/Utility/UriParser.cpp
@@ -42,7 +42,7 @@ bool UriParser::Parse(llvm::StringRef uri, llvm::StringRef 
&scheme,
   // Extract hostname
   if (!host_port.empty() && host_port[0] == '[') {
 // hostname is enclosed with square brackets.
-pos = host_port.find(']');
+pos = host_port.rfind(']');
 if (pos == std::string::npos)
   return false;
 

diff  --git a/lldb/unittests/Utility/UriParserTest.cpp 
b/lldb/unittests/Utility/UriParserTest.cpp
index c07d59a55e01..c88a647ef937 100644
--- a/lldb/unittests/Utility/UriParserTest.cpp
+++ b/lldb/unittests/Utility/UriParserTest.cpp
@@ -74,12 +74,19 @@ TEST(UriParserTest, LongPath) {
   VALIDATE
 }
 
-TEST(UriParserTest, TypicalPortPath) {
+TEST(UriParserTest, TypicalPortPathIPv4) {
   const UriTestCase testCase("connect://192.168.100.132:5432/", "connect",
  "192.168.100.132", 5432, "/");
   VALIDATE;
 }
 
+TEST(UriParserTest, TypicalPortPathIPv6) {
+  const UriTestCase testCase(
+  "connect://[2601:600:107f:db64:a42b:4faa:284:3082]:5432/", "connect",
+  "2601:600:107f:db64:a42b:4faa:284:3082", 5432, "/");
+  VALIDATE;
+}
+
 TEST(UriParserTest, BracketedHostnamePort) {
   const UriTestCase testCase("connect://[192.168.100.132]:5432/", "connect",
  "192.168.100.132", 5432, "/");
@@ -102,6 +109,21 @@ TEST(UriParserTest, BracketedHostname) {
   VALIDATE
 }
 
+TEST(UriParserTest, BracketedHostnameWithPortIPv4) {
+  // Android device over IPv4: port is a part of the hostname.
+  const UriTestCase testCase("connect://[192.168.100.132:1234]", "connect",
+ "192.168.100.132:1234", -1, "/");
+  VALIDATE
+}
+
+TEST(UriParserTest, BracketedHostnameWithPortIPv6) {
+  // Android device over IPv6: port is a part of the hostname.
+  const UriTestCase testCase(
+  "connect://[[2601:600:107f:db64:a42b:4faa:284]:1234]", "connect",
+  "[2601:600:107f:db64:a42b:4faa:284]:1234", -1, "/");
+  VALIDATE
+}
+
 TEST(UriParserTest, BracketedHostnameWithColon) {
   const UriTestCase testCase("connect://[192.168.100.132:]:1234", 
"connect",
  "192.168.100.132:", 1234, "/");



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

Re: [Lldb-commits] [lldb] b4a6e63 - [lldb/Target] Rework the way the inferior environment is created

[Pavel Labath via lldb-commits]

On 25/03/2020 17:51, Adrian McCarthy via lldb-commits wrote:
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Adrian McCarthy  > wrote:
> 
> 
> 
> On Wed, Mar 25, 2020 at 9:10 AM Pavel Labath  > wrote:
> 
> On 25/03/2020 01:04, Adrian McCarthy wrote:
> > I took a stab at this, but I'm not seeing any new test failures.
> 
> That is odd.
> 
> I was doing some stuff on windows today, so I figured I'd take a
> stab at
> this. I was kind of right that the check in ProcessLauncher windows
> prevents us from passing an empty environment.
> 
> However, the interesting part starts when I tried to remove that
> check.
> Then the test started behaving nondeterministically -- sometimes
> passing
> and sometimes failing due to ERROR_INVALID_PARAMETER being
> returned from
> CreateProcessW. I can see how windows might need some environment
> variables to start up a process correctly, but I do not
> understand why
> this should be nondeterministic...
> 
> 
> Oh, I have a guess.  CreateProcessW takes a pointer to an
> environment block.  If that pointer is null, the process will
> inherit the parent environment.  If you want to pass it an empty
> environment, you have to have a valid pointer to an empty string (or
> possibly to a string with TWO terminating '\0's).
> 
> 
> Scratch the "or possibly."  You definitely need two terminating zeros. 
> Since it's in UTF-16, it wants two L'\0', which is four consecutive zero
> bytes.
>  

Thanks. This is exactly what was needed. It's not what I would have
expected, as the documentation says this is "null-terminated block of
null-terminated strings" -- in my book that would mean that an empty
list of null-terminated strings ends with a single L'\0'. But I guess
this is a very weird corner case, as an empty environment is literally
the only way to *not* need a double null terminator.

Anyway, D76835 is the patch for that.

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

[Lldb-commits] [lldb] e22f0da - [lldb/breakpad] Fix register resolution on arm

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-26T13:51:27+01:00
New Revision: e22f0dabcf976668d35595e17645095e97a8177a

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

LOG: [lldb/breakpad] Fix register resolution on arm

In breakpad, only x86 (and mips) registers have a leading '$' in their
names. Arm architectures use plain register names.

Previously, lldb was assuming all registers have a '$'. Fix the code to
match the (unfortunately, inconsistent) reality.

Added: 
lldb/test/Shell/SymbolFile/Breakpad/Inputs/stack-cfi-arm.syms
lldb/test/Shell/SymbolFile/Breakpad/stack-cfi-arm.yaml

Modified: 
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp 
b/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
index 9c2cea4d9727..eeec7296747e 100644
--- a/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
+++ b/lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
@@ -408,20 +408,25 @@ GetRule(llvm::StringRef &unwind_rules) {
 }
 
 static const RegisterInfo *
-ResolveRegister(const SymbolFile::RegisterInfoResolver &resolver,
+ResolveRegister(const llvm::Triple &triple,
+const SymbolFile::RegisterInfoResolver &resolver,
 llvm::StringRef name) {
-  if (name.consume_front("$"))
-return resolver.ResolveName(name);
-
-  return nullptr;
+  if (triple.isX86() || triple.isMIPS()) {
+// X86 and MIPS registers have '$' in front of their register names. Arm 
and
+// AArch64 don't.
+if (!name.consume_front("$"))
+  return nullptr;
+  }
+  return resolver.ResolveName(name);
 }
 
 static const RegisterInfo *
-ResolveRegisterOrRA(const SymbolFile::RegisterInfoResolver &resolver,
+ResolveRegisterOrRA(const llvm::Triple &triple,
+const SymbolFile::RegisterInfoResolver &resolver,
 llvm::StringRef name) {
   if (name == ".ra")
 return resolver.ResolveNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
-  return ResolveRegister(resolver, name);
+  return ResolveRegister(triple, resolver, name);
 }
 
 llvm::ArrayRef SymbolFileBreakpad::SaveAsDWARF(postfix::Node &node) {
@@ -440,6 +445,7 @@ bool SymbolFileBreakpad::ParseCFIUnwindRow(llvm::StringRef 
unwind_rules,
   Log *log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_SYMBOLS);
 
   llvm::BumpPtrAllocator node_alloc;
+  llvm::Triple triple = m_objfile_sp->GetArchitecture().GetTriple();
   while (auto rule = GetRule(unwind_rules)) {
 node_alloc.Reset();
 llvm::StringRef lhs = rule->first;
@@ -455,7 +461,8 @@ bool SymbolFileBreakpad::ParseCFIUnwindRow(llvm::StringRef 
unwind_rules,
   if (name == ".cfa" && lhs != ".cfa")
 return postfix::MakeNode(node_alloc);
 
-  if (const RegisterInfo *info = ResolveRegister(resolver, name)) {
+  if (const RegisterInfo *info =
+  ResolveRegister(triple, resolver, name)) {
 return postfix::MakeNode(
 node_alloc, info->kinds[eRegisterKindLLDB]);
   }
@@ -470,7 +477,8 @@ bool SymbolFileBreakpad::ParseCFIUnwindRow(llvm::StringRef 
unwind_rules,
 llvm::ArrayRef saved = SaveAsDWARF(*rhs);
 if (lhs == ".cfa") {
   row.GetCFAValue().SetIsDWARFExpression(saved.data(), saved.size());
-} else if (const RegisterInfo *info = ResolveRegisterOrRA(resolver, lhs)) {
+} else if (const RegisterInfo *info =
+   ResolveRegisterOrRA(triple, resolver, lhs)) {
   UnwindPlan::Row::RegisterLocation loc;
   loc.SetIsDWARFExpression(saved.data(), saved.size());
   row.SetRegisterInfo(info->kinds[eRegisterKindLLDB], loc);
@@ -574,6 +582,7 @@ SymbolFileBreakpad::ParseWinUnwindPlan(const Bookmark 
&bookmark,
 return nullptr;
   }
   auto it = program.begin();
+  llvm::Triple triple = m_objfile_sp->GetArchitecture().GetTriple();
   const auto &symbol_resolver =
   [&](postfix::SymbolNode &symbol) -> postfix::Node * {
 llvm::StringRef name = symbol.GetName();
@@ -581,7 +590,7 @@ SymbolFileBreakpad::ParseWinUnwindPlan(const Bookmark 
&bookmark,
   if (rule.first == name)
 return rule.second;
 }
-if (const RegisterInfo *info = ResolveRegister(resolver, name))
+if (const RegisterInfo *info = ResolveRegister(triple, resolver, name))
   return postfix::MakeNode(
   node_alloc, info->kinds[eRegisterKindLLDB]);
 return nullptr;
@@ -611,7 +620,7 @@ SymbolFileBreakpad::ParseWinUnwindPlan(const Bookmark 
&bookmark,
 
   // Now process the rest of the assignments.
   for (++it; it != program.end(); ++it) {
-const RegisterInfo *info = ResolveRegister(resolver, it->first);
+const RegisterInfo *info = ResolveRegister(triple, resolver, it->first);
 /

Re: [Lldb-commits] [lldb] b4a6e63 - [lldb/Target] Rework the way the inferior environment is created

[Pavel Labath via lldb-commits]

On 25/03/2020 01:04, Adrian McCarthy wrote:
> I took a stab at this, but I'm not seeing any new test failures. 

That is odd.

I was doing some stuff on windows today, so I figured I'd take a stab at
this. I was kind of right that the check in ProcessLauncher windows
prevents us from passing an empty environment.

However, the interesting part starts when I tried to remove that check.
Then the test started behaving nondeterministically -- sometimes passing
and sometimes failing due to ERROR_INVALID_PARAMETER being returned from
CreateProcessW. I can see how windows might need some environment
variables to start up a process correctly, but I do not understand why
this should be nondeterministic...

This is beyond my knowledge of windows. It might be interesting to
reduce this to a simple test case (independent of lldb) and show it to
some windows expert.

I am attaching a patch with the lldb changes I've made, in case you want
to play around with it.

> I assume
> the problem you're seeing is in TestSettings.py, but I've never figured
> out how to run individual Python-based lldb tests since all the
> dotest.py stuff was re-written.

These days we have multiple ways of achieving that. :)

One way would be via the "check-lldb-api-commands-settings" target which
would run all tests under api/commands/settings (i.e. TestSettings.py
and TestQuoting.py).

Another option would be via the lldb-dotest script.
"python bin\lldb-dotest -p TestSettings.py" would just run that single
file. That script passes all of its options to dotest, so you can use
any of the dotest options that you used to use.

pl
From 0e01f02b9b01c9700787c640ac96923acdf0cb0f Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Wed, 25 Mar 2020 13:39:05 +0100
Subject: [PATCH] [lldb] (Almost?) fix TestSettings.test_pass_host_env_vars

A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead.

After applying this fix, the relevant test starts to pass, but it does
so (at least on my machine) only sporadically. Sometimes, CreateProcessW
seems to fail with ERROR_INVALID_PARAMETER.

My windows-fu is not sufficient to understand what is going on here.
---
 lldb/source/Host/windows/ProcessLauncherWindows.cpp | 6 +-
 lldb/test/API/commands/settings/TestSettings.py | 1 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index 31101944d..77c7bc269 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -23,9 +23,6 @@ using namespace lldb_private;
 namespace {
 void CreateEnvironmentBuffer(const Environment &env,
  std::vector &buffer) {
-  if (env.size() == 0)
-return;
-
   // Environment buffer is a null terminated list of null terminated strings
   for (const auto &KV : env) {
 std::wstring warg;
@@ -94,8 +91,7 @@ ProcessLauncherWindows::LaunchProcess(const ProcessLaunchInfo &launch_info,
 
   LPVOID env_block = nullptr;
   ::CreateEnvironmentBuffer(launch_info.GetEnvironment(), environment);
-  if (!environment.empty())
-env_block = environment.data();
+  env_block = environment.data();
 
   executable = launch_info.GetExecutableFile().GetPath();
   GetFlattenedWindowsCommandString(launch_info.GetArguments(), commandLine);
diff --git a/lldb/test/API/commands/settings/TestSettings.py b/lldb/test/API/commands/settings/TestSettings.py
index c0cdc085f..29360856a 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -286,7 +286,6 @@ class SettingsCommandTestCase(TestBase):
 "Environment variable 'MY_ENV_VAR' successfully passed."])
 
 @skipIfRemote  # it doesn't make sense to send host env to remote target
-@skipIf(oslist=["windows"])
 def test_pass_host_env_vars(self):
 """Test that the host env vars are passed to the launched process."""
 self.build()
-- 
2.19.2.windows.1

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

[Lldb-commits] [lldb] 7b00eeb - [lldb] Fix another crash in covariant type handling

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-30T16:00:21+02:00
New Revision: 7b00eeb53de06c7979fd2a88436c3387d0492ee8

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

LOG: [lldb] Fix another crash in covariant type handling

Summary:
D73024 seems to have fixed one set crash, but it introduced another.
Namely, if a class contains a covariant method returning itself, the
logic in MaybeCompleteReturnType could cause us to attempt a recursive
import, which would result in an assertion failure in
clang::DeclContext::removeDecl.

For some reason, this only manifested itself if the class contained at
least two member variables, and the class itself was imported as a
result of a recursive covariant import.

This patch fixes the crash by not attempting to import classes which are
already completed in MaybeCompleteReturnType. However, it's not clear to
me if this is the right fix, or if this should be handled automatically
by functions lower in the stack.

Reviewers: teemperor, shafik

Subscribers: lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
lldb/test/API/lang/cpp/covariant-return-types/TestCovariantReturnTypes.py
lldb/test/API/lang/cpp/covariant-return-types/main.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
index 479cb64deefd..4b3e237dc62c 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTImporter.cpp
@@ -997,6 +997,8 @@ static void MaybeCompleteReturnType(ClangASTImporter 
&importer,
   clang::RecordDecl *rd = return_type->getPointeeType()->getAsRecordDecl();
   if (!rd)
 return;
+  if (rd->getDefinition())
+return;
 
   importer.CompleteTagDecl(rd);
 }

diff  --git 
a/lldb/test/API/lang/cpp/covariant-return-types/TestCovariantReturnTypes.py 
b/lldb/test/API/lang/cpp/covariant-return-types/TestCovariantReturnTypes.py
index 86a6ddd6e47b..6f2b3eafd2e9 100644
--- a/lldb/test/API/lang/cpp/covariant-return-types/TestCovariantReturnTypes.py
+++ b/lldb/test/API/lang/cpp/covariant-return-types/TestCovariantReturnTypes.py
@@ -38,3 +38,5 @@ def test(self):
 self.expect_expr("derived.getOtherRef().value()", 
result_summary='"derived"')
 self.expect_expr("base_ptr_to_derived->getOtherRef().value()", 
result_summary='"derived"')
 self.expect_expr("base.getOtherRef().value()", result_summary='"base"')
+
+self.expect_expr("referencing_derived.getOther()->get()->a", 
result_value='42')

diff  --git a/lldb/test/API/lang/cpp/covariant-return-types/main.cpp 
b/lldb/test/API/lang/cpp/covariant-return-types/main.cpp
index 2a6fc682c39a..ea05043d6cf9 100644
--- a/lldb/test/API/lang/cpp/covariant-return-types/main.cpp
+++ b/lldb/test/API/lang/cpp/covariant-return-types/main.cpp
@@ -28,6 +28,23 @@ struct Derived : public Base {
   OtherDerived& getOtherRef() override { return other_derived; }
 };
 
+// A regression test for a class with at least two members containing a
+// covariant function, which is referenced through another covariant function.
+struct BaseWithMembers {
+  int a = 42;
+  int b = 47;
+  virtual BaseWithMembers *get() { return this; }
+};
+struct DerivedWithMembers: BaseWithMembers {
+  DerivedWithMembers *get() override { return this; }
+};
+struct ReferencingBase {
+  virtual BaseWithMembers *getOther() { return new BaseWithMembers(); }
+};
+struct ReferencingDerived: ReferencingBase {
+  DerivedWithMembers *getOther() { return new DerivedWithMembers(); }
+};
+
 int main() {
   Derived derived;
   Base base;
@@ -36,5 +53,7 @@ int main() {
   (void)base_ptr_to_derived->getRef();
   (void)base_ptr_to_derived->getOtherPtr();
   (void)base_ptr_to_derived->getOtherRef();
+
+  ReferencingDerived referencing_derived;
   return 0; // break here
 }



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

[Lldb-commits] [lldb] 908f78f - [lldb] Fix TestSettings.test_pass_host_env_vars on windows

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-30T16:06:52+02:00
New Revision: 908f78f3c19805ee7386186072407a541c9fb167

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

LOG: [lldb] Fix TestSettings.test_pass_host_env_vars on windows

Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.

Reviewers: amccarth, friss

Subscribers: lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Host/windows/ProcessLauncherWindows.cpp
lldb/test/API/commands/settings/TestSettings.py

Removed: 




diff  --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp 
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index 31101944d75c..00470f558e94 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -23,10 +23,9 @@ using namespace lldb_private;
 namespace {
 void CreateEnvironmentBuffer(const Environment &env,
  std::vector &buffer) {
-  if (env.size() == 0)
-return;
-
-  // Environment buffer is a null terminated list of null terminated strings
+  // The buffer is a list of null-terminated UTF-16 strings, followed by an
+  // extra L'\0' (two bytes of 0).  An empty environment must have one
+  // empty string, followed by an extra L'\0'.
   for (const auto &KV : env) {
 std::wstring warg;
 if (llvm::ConvertUTF8toWide(Environment::compose(KV), warg)) {
@@ -38,6 +37,9 @@ void CreateEnvironmentBuffer(const Environment &env,
   // One null wchar_t (to end the block) is two null bytes
   buffer.push_back(0);
   buffer.push_back(0);
+  // Insert extra two bytes, just in case the environment was empty.
+  buffer.push_back(0);
+  buffer.push_back(0);
 }
 
 bool GetFlattenedWindowsCommandString(Args args, std::string &command) {
@@ -94,8 +96,7 @@ ProcessLauncherWindows::LaunchProcess(const ProcessLaunchInfo 
&launch_info,
 
   LPVOID env_block = nullptr;
   ::CreateEnvironmentBuffer(launch_info.GetEnvironment(), environment);
-  if (!environment.empty())
-env_block = environment.data();
+  env_block = environment.data();
 
   executable = launch_info.GetExecutableFile().GetPath();
   GetFlattenedWindowsCommandString(launch_info.GetArguments(), commandLine);

diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index c0cdc085f129..29360856a735 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -286,7 +286,6 @@ def do_test_run_args_and_env_vars(self, use_launchsimple):
 "Environment variable 'MY_ENV_VAR' successfully passed."])
 
 @skipIfRemote  # it doesn't make sense to send host env to remote target
-@skipIf(oslist=["windows"])
 def test_pass_host_env_vars(self):
 """Test that the host env vars are passed to the launched process."""
 self.build()



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

[Lldb-commits] [lldb] 3788978 - Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-03-30T17:32:42+02:00
New Revision: 37889786b040bd2bc48e5a01c6b92de777564a8f

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

LOG: Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This reverts commit because of test failures in TestHelloWorld.

It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.

The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.

Added: 


Modified: 
lldb/source/Host/windows/ProcessLauncherWindows.cpp
lldb/test/API/commands/settings/TestSettings.py

Removed: 




diff  --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp 
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index 00470f558e94..31101944d75c 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -23,9 +23,10 @@ using namespace lldb_private;
 namespace {
 void CreateEnvironmentBuffer(const Environment &env,
  std::vector &buffer) {
-  // The buffer is a list of null-terminated UTF-16 strings, followed by an
-  // extra L'\0' (two bytes of 0).  An empty environment must have one
-  // empty string, followed by an extra L'\0'.
+  if (env.size() == 0)
+return;
+
+  // Environment buffer is a null terminated list of null terminated strings
   for (const auto &KV : env) {
 std::wstring warg;
 if (llvm::ConvertUTF8toWide(Environment::compose(KV), warg)) {
@@ -37,9 +38,6 @@ void CreateEnvironmentBuffer(const Environment &env,
   // One null wchar_t (to end the block) is two null bytes
   buffer.push_back(0);
   buffer.push_back(0);
-  // Insert extra two bytes, just in case the environment was empty.
-  buffer.push_back(0);
-  buffer.push_back(0);
 }
 
 bool GetFlattenedWindowsCommandString(Args args, std::string &command) {
@@ -96,7 +94,8 @@ ProcessLauncherWindows::LaunchProcess(const ProcessLaunchInfo 
&launch_info,
 
   LPVOID env_block = nullptr;
   ::CreateEnvironmentBuffer(launch_info.GetEnvironment(), environment);
-  env_block = environment.data();
+  if (!environment.empty())
+env_block = environment.data();
 
   executable = launch_info.GetExecutableFile().GetPath();
   GetFlattenedWindowsCommandString(launch_info.GetArguments(), commandLine);

diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index 29360856a735..c0cdc085f129 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -286,6 +286,7 @@ def do_test_run_args_and_env_vars(self, use_launchsimple):
 "Environment variable 'MY_ENV_VAR' successfully passed."])
 
 @skipIfRemote  # it doesn't make sense to send host env to remote target
+@skipIf(oslist=["windows"])
 def test_pass_host_env_vars(self):
 """Test that the host env vars are passed to the launched process."""
 self.build()



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

[Lldb-commits] [lldb] 0ec88d0 - [lldb] Inherit host environment when running shell commands

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-01T11:20:13+02:00
New Revision: 0ec88d031ad5abcd78068a8377494ec84ea6a1e1

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

LOG: [lldb] Inherit host environment when running shell commands

Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.

Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment.  This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.

Reviewers: jingham, friss

Subscribers: lldb-commits

Tags: #lldb

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

Added: 
lldb/test/API/python_api/sbplatform/Makefile
lldb/test/API/python_api/sbplatform/TestSBPlatform.py
lldb/test/API/python_api/sbplatform/main.cpp

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

Removed: 




diff  --git a/lldb/source/Host/common/Host.cpp 
b/lldb/source/Host/common/Host.cpp
index b2485393cd6a..8a6af3881a0f 100644
--- a/lldb/source/Host/common/Host.cpp
+++ b/lldb/source/Host/common/Host.cpp
@@ -501,6 +501,8 @@ Status Host::RunShellCommand(const Args &args, const 
FileSpec &working_dir,
 launch_info.SetArguments(args, first_arg_is_executable);
   }
 
+  launch_info.GetEnvironment() = Host::GetEnvironment();
+
   if (working_dir)
 launch_info.SetWorkingDirectory(working_dir);
   llvm::SmallString<64> output_file_path;

diff  --git a/lldb/test/API/python_api/sbplatform/Makefile 
b/lldb/test/API/python_api/sbplatform/Makefile
new file mode 100644
index ..8b20bcb0
--- /dev/null
+++ b/lldb/test/API/python_api/sbplatform/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

diff  --git a/lldb/test/API/python_api/sbplatform/TestSBPlatform.py 
b/lldb/test/API/python_api/sbplatform/TestSBPlatform.py
new file mode 100644
index ..4735f6ea3b49
--- /dev/null
+++ b/lldb/test/API/python_api/sbplatform/TestSBPlatform.py
@@ -0,0 +1,22 @@
+"""Test the SBPlatform APIs."""
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+class SBPlatformAPICase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+@add_test_categories(['pyapi'])
+def test_run(self):
+self.build()
+plat = lldb.SBPlatform.GetHostPlatform()
+
+os.environ["MY_TEST_ENV_VAR"]="SBPlatformAPICase.test_run"
+def cleanup():
+del os.environ["MY_TEST_ENV_VAR"]
+self.addTearDownHook(cleanup)
+cmd = lldb.SBPlatformShellCommand(self.getBuildArtifact("a.out"))
+self.assertTrue(plat.Run(cmd).Success())
+self.assertIn("MY_TEST_ENV_VAR=SBPlatformAPICase.test_run", 
cmd.GetOutput())

diff  --git a/lldb/test/API/python_api/sbplatform/main.cpp 
b/lldb/test/API/python_api/sbplatform/main.cpp
new file mode 100644
index ..9f2aca26ab8d
--- /dev/null
+++ b/lldb/test/API/python_api/sbplatform/main.cpp
@@ -0,0 +1,8 @@
+#include 
+#include 
+
+int main() {
+  printf("MY_TEST_ENV_VAR=%s\n", getenv("MY_TEST_ENV_VAR"));
+
+  return 0;
+}



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

Re: [Lldb-commits] [lldb] c911cc6 - [intel-pt] Implement a basic test case

[Pavel Labath via lldb-commits]

Walter,

you were already told to write more informative messages when reverting
and recommiting patches. If you're reverting a patch, please give a
short explanation of the reason (does it fail on the bots? which ones?
what fails?). When recommiting a patch, please give a summary of what
has changed since the last version, so one does not have to diff the
patches just to see what happened.

If you're unsure about why a test fails somewhere you can ask the bot
owner for help, instead of just trying over and over..

pl

On 01/04/2020 22:44, Walter Erquinigo via lldb-commits wrote:
> 
> Author: Walter Erquinigo
> Date: 2020-04-01T13:44:03-07:00
> New Revision: c911cc6c49394909a335c8d7baffcfd8bdcc424b
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/c911cc6c49394909a335c8d7baffcfd8bdcc424b
> DIFF: 
> https://github.com/llvm/llvm-project/commit/c911cc6c49394909a335c8d7baffcfd8bdcc424b.diff
> 
> LOG: [intel-pt] Implement a basic test case
> 
> Summary:
> Depends on D76872.
> 
> There was no test for the Intel PT support on LLDB, so I'm creating one, which
> will help making progress on solid grounds.
> 
> The test is skipped if the Intel PT plugin library is not built.
> 
> Reviewers: clayborg, labath, kusmour, aadsm
> 
> Subscribers: lldb-commits
> 
> Tags: #lldb
> 
> Differential Revision: https://reviews.llvm.org/D77107
> 
> Added: 
> lldb/test/API/tools/intel-features/intel-pt/test/Makefile
> 
> lldb/test/API/tools/intel-features/intel-pt/test/TestIntelPTSimpleBinary.py
> lldb/test/API/tools/intel-features/intel-pt/test/main.cpp
> 
> Modified: 
> lldb/tools/intel-features/intel-pt/cli-wrapper-pt.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/test/API/tools/intel-features/intel-pt/test/Makefile 
> b/lldb/test/API/tools/intel-features/intel-pt/test/Makefile
> new file mode 100644
> index ..8b20bcb0
> --- /dev/null
> +++ b/lldb/test/API/tools/intel-features/intel-pt/test/Makefile
> @@ -0,0 +1,3 @@
> +CXX_SOURCES := main.cpp
> +
> +include Makefile.rules
> 
> diff  --git 
> a/lldb/test/API/tools/intel-features/intel-pt/test/TestIntelPTSimpleBinary.py 
> b/lldb/test/API/tools/intel-features/intel-pt/test/TestIntelPTSimpleBinary.py
> new file mode 100644
> index ..9bbae290a7d0
> --- /dev/null
> +++ 
> b/lldb/test/API/tools/intel-features/intel-pt/test/TestIntelPTSimpleBinary.py
> @@ -0,0 +1,60 @@
> +from __future__ import print_function
> +
> +import os
> +import lldb
> +import time
> +
> +from lldbsuite.test.decorators import *
> +from lldbsuite.test.lldbtest import *
> +from lldbsuite.test import lldbutil
> +
> +
> +class TestIntelPTSimpleBinary(TestBase):
> +
> +mydir = TestBase.compute_mydir(__file__)
> +NO_DEBUG_INFO_TESTCASE = True
> +
> +@skipIf(oslist=no_match(['linux']))
> +@skipIf(archs=no_match(['i386', 'x86_64']))
> +@skipIfRemote
> +def test_basic_flow(self):
> +"""Test collection, decoding, and dumping instructions"""
> +lldb_exec_dir = os.environ["LLDB_IMPLIB_DIR"]
> +lldb_lib_dir = os.path.join(lldb_exec_dir, os.pardir, "lib")
> +plugin_file = os.path.join(lldb_lib_dir, "liblldbIntelFeatures.so")
> +if not os.path.isfile(plugin_file):
> +self.skipTest("features plugin missing.")
> +return
> +
> +self.build()
> +
> +self.runCmd("plugin load " + plugin_file)
> +
> +exe = self.getBuildArtifact("a.out")
> +lldbutil.run_to_name_breakpoint(self, "main", exe_name=exe)
> +# We start tracing from main
> +self.runCmd("processor-trace start all")
> +
> +# We check the trace after the for loop
> +self.runCmd("b " + str(line_number('main.cpp', '// Break 1')))
> +self.runCmd("c")
> +
> +# We wait a little bit to ensure the processor has send the PT 
> packets to
> +# the memory
> +time.sleep(.1)
> +
> +# We find the start address of the 'fun' function for a later check
> +target = self.dbg.GetSelectedTarget()
> +fun_start_adddress = target.FindFunctions("fun")[0].GetSymbol() \
> +.GetStartAddress().GetLoadAddress(target)
> +
> +# We print the last instructions
> +self.expect("processor-trace show-instr-log -c 100",
> +patterns=[
> +# We expect to have seen the first instruction of 'fun'
> +hex(fun_start_adddress),  
> +# We expect to see the exit condition of the for loop
> +"at main.cpp:" + str(line_number('main.cpp', '// Break for 
> loop')) 
> +])
> +
> +self.runCmd("processor-trace stop")
> 
> diff  --git a/lldb/test/API/tools/intel-features/intel-pt/test/main.cpp 
> b/lldb/test/API/tools/intel-features/intel-pt/test/main.cpp
> new file mode 100644
> index ..ea826a2ac0c6
> --- /dev/null
> +++ b/lldb/test/API/tools/intel-features/in

[Lldb-commits] [lldb] 62be834 - Recommit "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-02T11:52:56+02:00
New Revision: 62be83463a3713612bd85cfa45140ef92c130d57

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

LOG: Recommit "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.

The original commit message was:

A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.

Reviewers: amccarth, friss

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

Added: 


Modified: 
lldb/source/Host/windows/ProcessLauncherWindows.cpp
lldb/test/API/commands/settings/TestSettings.py

Removed: 




diff  --git a/lldb/source/Host/windows/ProcessLauncherWindows.cpp 
b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
index 31101944d75c..00470f558e94 100644
--- a/lldb/source/Host/windows/ProcessLauncherWindows.cpp
+++ b/lldb/source/Host/windows/ProcessLauncherWindows.cpp
@@ -23,10 +23,9 @@ using namespace lldb_private;
 namespace {
 void CreateEnvironmentBuffer(const Environment &env,
  std::vector &buffer) {
-  if (env.size() == 0)
-return;
-
-  // Environment buffer is a null terminated list of null terminated strings
+  // The buffer is a list of null-terminated UTF-16 strings, followed by an
+  // extra L'\0' (two bytes of 0).  An empty environment must have one
+  // empty string, followed by an extra L'\0'.
   for (const auto &KV : env) {
 std::wstring warg;
 if (llvm::ConvertUTF8toWide(Environment::compose(KV), warg)) {
@@ -38,6 +37,9 @@ void CreateEnvironmentBuffer(const Environment &env,
   // One null wchar_t (to end the block) is two null bytes
   buffer.push_back(0);
   buffer.push_back(0);
+  // Insert extra two bytes, just in case the environment was empty.
+  buffer.push_back(0);
+  buffer.push_back(0);
 }
 
 bool GetFlattenedWindowsCommandString(Args args, std::string &command) {
@@ -94,8 +96,7 @@ ProcessLauncherWindows::LaunchProcess(const ProcessLaunchInfo 
&launch_info,
 
   LPVOID env_block = nullptr;
   ::CreateEnvironmentBuffer(launch_info.GetEnvironment(), environment);
-  if (!environment.empty())
-env_block = environment.data();
+  env_block = environment.data();
 
   executable = launch_info.GetExecutableFile().GetPath();
   GetFlattenedWindowsCommandString(launch_info.GetArguments(), commandLine);

diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index c0cdc085f129..29360856a735 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -286,7 +286,6 @@ def do_test_run_args_and_env_vars(self, use_launchsimple):
 "Environment variable 'MY_ENV_VAR' successfully passed."])
 
 @skipIfRemote  # it doesn't make sense to send host env to remote target
-@skipIf(oslist=["windows"])
 def test_pass_host_env_vars(self):
 """Test that the host env vars are passed to the launched process."""
 self.build()



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

[Lldb-commits] [lldb] 451741a - [lldb] Change Communication::SetConnection to take a unique_ptr

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-02T14:42:25+02:00
New Revision: 451741a9d778a260ceee608a26b5fdf2d9926982

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

LOG: [lldb] Change Communication::SetConnection to take a unique_ptr

The function takes ownership of the object. This makes that explicit,
and avoids unowned pointers floating around.

Added: 


Modified: 
lldb/include/lldb/Core/Communication.h
lldb/source/API/SBCommunication.cpp
lldb/source/Core/Communication.cpp
lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Target/Process.cpp
lldb/tools/lldb-server/lldb-platform.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
lldb/unittests/tools/lldb-server/tests/TestClient.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Communication.h 
b/lldb/include/lldb/Core/Communication.h
index 048541aa4c7c..4233d5bf5f81 100644
--- a/lldb/include/lldb/Core/Communication.h
+++ b/lldb/include/lldb/Core/Communication.h
@@ -221,7 +221,7 @@ class Communication : public Broadcaster {
   ///
   /// \see
   /// class Connection
-  void SetConnection(Connection *connection);
+  void SetConnection(std::unique_ptr connection);
 
   /// Starts a read thread whose sole purpose it to read bytes from the
   /// current connection. This function will call connection's read function:

diff  --git a/lldb/source/API/SBCommunication.cpp 
b/lldb/source/API/SBCommunication.cpp
index 7c7ba39257d9..d55ecd35b557 100644
--- a/lldb/source/API/SBCommunication.cpp
+++ b/lldb/source/API/SBCommunication.cpp
@@ -63,7 +63,7 @@ ConnectionStatus SBCommunication::Connect(const char *url) {
 
   if (m_opaque) {
 if (!m_opaque->HasConnection())
-  m_opaque->SetConnection(Host::CreateDefaultConnection(url).release());
+  m_opaque->SetConnection(Host::CreateDefaultConnection(url));
 return m_opaque->Connect(url, nullptr);
   }
   return eConnectionStatusNoConnection;
@@ -79,7 +79,8 @@ ConnectionStatus SBCommunication::AdoptFileDesriptor(int fd, 
bool owns_fd) {
   if (m_opaque->IsConnected())
 m_opaque->Disconnect();
 }
-m_opaque->SetConnection(new ConnectionFileDescriptor(fd, owns_fd));
+m_opaque->SetConnection(
+std::make_unique(fd, owns_fd));
 if (m_opaque->IsConnected())
   status = eConnectionStatusSuccess;
 else

diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index 88f6a21ea4d5..f4163847e4bb 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -399,10 +399,10 @@ void Communication::SynchronizeWithReadThread() {
   listener_sp->GetEvent(event_sp, llvm::None);
 }
 
-void Communication::SetConnection(Connection *connection) {
+void Communication::SetConnection(std::unique_ptr connection) {
   Disconnect(nullptr);
   StopReadThread(nullptr);
-  m_connection_sp.reset(connection);
+  m_connection_sp = std::move(connection);
 }
 
 const char *

diff  --git 
a/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp 
b/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
index b0467555665c..657b8fdc729a 100644
--- a/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
+++ b/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
@@ -290,7 +290,7 @@ Status PlatformRemoteGDBServer::ConnectRemote(Args &args) {
GetHostname());
   } else {
 if (args.GetArgumentCount() == 1) {
-  m_gdb_client.SetConnection(new ConnectionFileDescriptor());
+  m_gdb_client.SetConnection(std::make_unique());
   // we're going to reuse the hostname when we connect to the debugserver
   int port;
   std::string path;

diff  --git a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
index 09d1965f25ed..5b728a5f2960 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
@@ -250,7 +250,7 @@ Status ProcessKDP::DoConnectRemote(Stream *strm, 
llvm::StringRef remote_url) {
 const uint16_t reply_port = socket.GetLocalPortNumber();
 
 if (reply_port != 0) {
-  m_comm.SetConnection(conn_up.release());
+  m_comm.SetConnection(std::move(conn_up));
 
   if (m_comm.

Re: [Lldb-commits] [lldb] b78157c - [intel-pt] Implement a basic test case

[Pavel Labath via lldb-commits]

On 02/04/2020 20:37, Walter Erquinigo via lldb-commits wrote:
> - Now using a env var to determine whether to run the test, as
> someone might have built liblldbIntelFeatures.so without intelPT
> support, which would make this test fail.

That's a very nonstandard way of doing things. I don't think we should
be doing that.

Is there any way of checking this automatically (for example, by looking
at /proc/cpuinfo)? We could then have a test decorator or a test
category to annotate these tests with...

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

[Lldb-commits] [lldb] 4f644ff - [lldb] XFAIL TestThreadPlanCommands _only_ on aarch64

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-06T10:36:02+02:00
New Revision: 4f644ff9e8738b5fde4825b929ec69d0b78ed2ea

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

LOG: [lldb] XFAIL TestThreadPlanCommands _only_ on aarch64

The test works fine on x86-linux.

Added: 


Modified: 
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
index 5214a3f6b0fe..ddc88cce75f1 100644
--- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
+++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
@@ -17,7 +17,7 @@ class TestThreadPlanCommands(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @skipIfWindows
-@expectedFailureAll(oslist=["linux"])
+@expectedFailureAll(oslist=["linux"], archs=["aarch64"])
 def test_thread_plan_actions(self):
 self.build()
 self.main_source_file = lldb.SBFileSpec("main.c")



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

Re: [Lldb-commits] [lldb] b6cd964 - Fix typo in xfail decorator for lldb thread plan list tests

[Pavel Labath via lldb-commits]

I guess these should go away after 4f644ff9e (which restrict the
decorator to aarch64). Judging by
,
Jim is going to look into a better solution for that this week.

pl


On 06/04/2020 11:50, Jan Kratochvil wrote:
> Hi,
> 
> I get XPASSes now on Fedora 31 x86_64:
> 
> http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/7169
> http://lab.llvm.org:8014/builders/lldb-x86_64-fedora?numbuilds=1000
> 
> So maybe to remove the expected failure?
> 
> 
> Jan
> 
> 
> 
> On Sun, 05 Apr 2020 17:18:54 +0200, Muhammad Omair Javaid via lldb-commits 
> wrote:
>>
>> Author: Muhammad Omair Javaid
>> Date: 2020-04-05T20:16:46+05:00
>> New Revision: b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc
>>
>> URL: 
>> https://github.com/llvm/llvm-project/commit/b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc.diff
>>
>> LOG: Fix typo in xfail decorator for lldb thread plan list tests
>>
>> Added: 
>> 
>>
>> Modified: 
>> lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>>
>> Removed: 
>> 
>>
>>
>> 
>> diff  --git 
>> a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
>> b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>> index b4ae9107aceb..5214a3f6b0fe 100644
>> --- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>> +++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>> @@ -17,7 +17,7 @@ class TestThreadPlanCommands(TestBase):
>>  NO_DEBUG_INFO_TESTCASE = True
>>  
>>  @skipIfWindows
>> -@expectedFailureAll(oslist=["Linux"])
>> +@expectedFailureAll(oslist=["linux"])
>>  def test_thread_plan_actions(self):
>>  self.build()
>>  self.main_source_file = lldb.SBFileSpec("main.c")
>>
>>
>> 
>> ___
>> 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] [lldb] a53bf9b - [lldb-server] jThreadsInfo returns stack memory

[Pavel Labath via lldb-commits]

Author: Jaroslav Sevcik
Date: 2020-04-06T15:43:19+02:00
New Revision: a53bf9b7c8f1ca950226a55c0e99fd706a7b6ad2

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

LOG: [lldb-server] jThreadsInfo returns stack memory

This patch adds parts of the stack that should be useful for unwinding
to the jThreadsInfo reply from lldb-server. We return the top of the
stack (12 words), and we also try to walk the frame pointer linked list
and return the memory containing frame pointer and return address pairs.
The idea is to cover the cases with and without frame pointer omission.

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

Added: 
lldb/test/API/tools/lldb-server/threads-info/Makefile

lldb/test/API/tools/lldb-server/threads-info/TestGdbRemoteThreadsInfoMemory.py
lldb/test/API/tools/lldb-server/threads-info/main.cpp

Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/test/API/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 7d6cb2a3484b..ce889c94d512 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -31,6 +31,7 @@
 #include "lldb/Target/MemoryRegionInfo.h"
 #include "lldb/Utility/Args.h"
 #include "lldb/Utility/DataBuffer.h"
+#include "lldb/Utility/DataExtractor.h"
 #include "lldb/Utility/Endian.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
@@ -562,6 +563,119 @@ GetRegistersAsJSON(NativeThreadProtocol &thread) {
   return register_object;
 }
 
+static llvm::Optional
+GetRegisterValue(NativeRegisterContext ®_ctx, uint32_t generic_regnum) {
+  Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_THREAD));
+  uint32_t reg_num = reg_ctx.ConvertRegisterKindToRegisterNumber(
+  eRegisterKindGeneric, generic_regnum);
+  const RegisterInfo *const reg_info_p =
+  reg_ctx.GetRegisterInfoAtIndex(reg_num);
+
+  if (reg_info_p == nullptr || reg_info_p->value_regs != nullptr) {
+LLDB_LOGF(log, "%s failed to get register info for register index %" 
PRIu32,
+  __FUNCTION__, reg_num);
+return {};
+  }
+
+  RegisterValue reg_value;
+  Status error = reg_ctx.ReadRegister(reg_info_p, reg_value);
+  if (error.Fail()) {
+LLDB_LOGF(log, "%s failed to read register '%s' index %" PRIu32 ": %s",
+  __FUNCTION__,
+  reg_info_p->name ? reg_info_p->name : "",
+  reg_num, error.AsCString());
+return {};
+  }
+  return reg_value;
+}
+
+static json::Object CreateMemoryChunk(json::Array &stack_memory_chunks,
+  addr_t address,
+  std::vector &bytes) {
+  json::Object chunk;
+  chunk.try_emplace("address", static_cast(address));
+  StreamString stream;
+  for (uint8_t b : bytes)
+stream.PutHex8(b);
+  chunk.try_emplace("bytes", stream.GetString().str());
+  return chunk;
+}
+
+static json::Array GetStackMemoryAsJSON(NativeProcessProtocol &process,
+NativeThreadProtocol &thread) {
+  uint32_t address_size = process.GetArchitecture().GetAddressByteSize();
+  const size_t kStackTopMemoryInfoWordSize = 12;
+  size_t stack_top_memory_info_byte_size =
+  kStackTopMemoryInfoWordSize * address_size;
+  const size_t kMaxStackSize = 128 * 1024;
+  const size_t kMaxFrameSize = 4 * 1024;
+  size_t fp_and_ra_size = 2 * address_size;
+  const size_t kMaxFrameCount = 128;
+
+  NativeRegisterContext ®_ctx = thread.GetRegisterContext();
+
+  json::Array stack_memory_chunks;
+
+  lldb::addr_t sp_value;
+  if (llvm::Optional optional_sp_value =
+  GetRegisterValue(reg_ctx, LLDB_REGNUM_GENERIC_SP)) {
+sp_value = optional_sp_value->GetAsUInt64();
+  } else {
+return stack_memory_chunks;
+  }
+  lldb::addr_t fp_value;
+  if (llvm::Optional optional_fp_value =
+  GetRegisterValue(reg_ctx, LLDB_REGNUM_GENERIC_FP)) {
+fp_value = optional_fp_value->GetAsUInt64();
+  } else {
+return stack_memory_chunks;
+  }
+
+  // First, make sure we copy the top stack_top_memory_info_byte_size bytes
+  // from the stack.
+  size_t byte_count = std::min(stack_top_memory_info_byte_size,
+   static_cast(fp_value - sp_value));
+  std::vector buf(byte_count, 0);
+
+  size_t bytes_read = 0;
+  Status error = process.ReadMemoryWithoutTrap(sp_value, buf.data(), 
byte_count,
+   bytes_read);
+  if (error.Success() && bytes_read > 0) {
+buf.resize(bytes_read);
+stack_memory_chunk

[Lldb-commits] [lldb] ebb0713 - [lldb/Core] Fix a race in the Communication class

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-09T12:06:47+02:00
New Revision: ebb071345cdae2509c55f9eec76090926fee86a2

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

LOG: [lldb/Core] Fix a race in the Communication class

Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.

However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.

This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.

The fix is to hold the synchronization mutex while closing the
connection.

I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.

The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

Added: 
lldb/unittests/Core/CommunicationTest.cpp

Modified: 
lldb/source/Core/Communication.cpp
lldb/unittests/Core/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index f4163847e4bb..c3e421191b01 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -315,16 +315,12 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   Status error;
   ConnectionStatus status = eConnectionStatusSuccess;
   bool done = false;
+  bool disconnect = false;
   while (!done && comm->m_read_thread_enabled) {
 size_t bytes_read = comm->ReadFromConnection(
 buf, sizeof(buf), std::chrono::seconds(5), status, &error);
-if (bytes_read > 0)
+if (bytes_read > 0 || status == eConnectionStatusEndOfFile)
   comm->AppendBytesToCache(buf, bytes_read, true, status);
-else if ((bytes_read == 0) && status == eConnectionStatusEndOfFile) {
-  if (comm->GetCloseOnEOF())
-comm->Disconnect();
-  comm->AppendBytesToCache(buf, bytes_read, true, status);
-}
 
 switch (status) {
 case eConnectionStatusSuccess:
@@ -332,11 +328,12 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
 
 case eConnectionStatusEndOfFile:
   done = true;
+  disconnect = comm->GetCloseOnEOF();
   break;
 case eConnectionStatusError: // Check GetError() for details
   if (error.GetType() == eErrorTypePOSIX && error.GetError() == EIO) {
 // EIO on a pipe is usually caused by remote shutdown
-comm->Disconnect();
+disconnect = comm->GetCloseOnEOF();
 done = true;
   }
   if (error.Fail())
@@ -365,9 +362,15 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   if (log)
 LLDB_LOGF(log, "%p Communication::ReadThread () thread exiting...", p);
 
-  comm->m_read_thread_did_exit = true;
-  // Let clients know that this thread is exiting
   comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
+  {
+std::lock_guard guard(comm->m_synchronize_mutex);
+comm->m_read_thread_did_exit = true;
+if (disconnect)
+  comm->Disconnect();
+  }
+
+  // Let clients know that this thread is exiting
   comm->BroadcastEvent(eBroadcastBitReadThreadDidExit);
   return {};
 }

diff  --git a/lldb/unittests/Core/CMakeLists.txt 
b/lldb/unittests/Core/CMakeLists.txt
index 688a39d9a10f..6393c6fe38c2 100644
--- a/lldb/unittests/Core/CMakeLists.txt
+++ b/lldb/unittests/Core/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(LLDBCoreTests
+  CommunicationTest.cpp
   MangledTest.cpp
   RichManglingContextTest.cpp
   StreamCallbackTest.cpp

diff  --git a/lldb/unittests/Core/CommunicationTest.cpp 
b/lldb/unittests/Core/CommunicationTest.cpp
new file mode 100644
index ..6ad0bc720d93
--- /dev/null
+++ b/lldb/unittests/Core/CommunicationTest.cpp
@@ -0,0 +1,35 @@
+//===-- CommunicationTest.cpp 
-===//
+//
+// 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 "l

[Lldb-commits] [lldb] 76975c7 - Revert "[lldb/Core] Fix a race in the Communication class"

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-09T12:49:56+02:00
New Revision: 76975c744da1e82ca6bdbe6883c799340acaf4f0

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

LOG: Revert "[lldb/Core] Fix a race in the Communication class"

This reverts commit ebb071345cdae2509c55f9eec76090926fee86a2 -- it seems
to introduce a deadlock in some circumstances.

Added: 


Modified: 
lldb/source/Core/Communication.cpp
lldb/unittests/Core/CMakeLists.txt

Removed: 
lldb/unittests/Core/CommunicationTest.cpp



diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index c3e421191b01..f4163847e4bb 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -315,12 +315,16 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   Status error;
   ConnectionStatus status = eConnectionStatusSuccess;
   bool done = false;
-  bool disconnect = false;
   while (!done && comm->m_read_thread_enabled) {
 size_t bytes_read = comm->ReadFromConnection(
 buf, sizeof(buf), std::chrono::seconds(5), status, &error);
-if (bytes_read > 0 || status == eConnectionStatusEndOfFile)
+if (bytes_read > 0)
   comm->AppendBytesToCache(buf, bytes_read, true, status);
+else if ((bytes_read == 0) && status == eConnectionStatusEndOfFile) {
+  if (comm->GetCloseOnEOF())
+comm->Disconnect();
+  comm->AppendBytesToCache(buf, bytes_read, true, status);
+}
 
 switch (status) {
 case eConnectionStatusSuccess:
@@ -328,12 +332,11 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
 
 case eConnectionStatusEndOfFile:
   done = true;
-  disconnect = comm->GetCloseOnEOF();
   break;
 case eConnectionStatusError: // Check GetError() for details
   if (error.GetType() == eErrorTypePOSIX && error.GetError() == EIO) {
 // EIO on a pipe is usually caused by remote shutdown
-disconnect = comm->GetCloseOnEOF();
+comm->Disconnect();
 done = true;
   }
   if (error.Fail())
@@ -362,15 +365,9 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   if (log)
 LLDB_LOGF(log, "%p Communication::ReadThread () thread exiting...", p);
 
-  comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
-  {
-std::lock_guard guard(comm->m_synchronize_mutex);
-comm->m_read_thread_did_exit = true;
-if (disconnect)
-  comm->Disconnect();
-  }
-
+  comm->m_read_thread_did_exit = true;
   // Let clients know that this thread is exiting
+  comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
   comm->BroadcastEvent(eBroadcastBitReadThreadDidExit);
   return {};
 }

diff  --git a/lldb/unittests/Core/CMakeLists.txt 
b/lldb/unittests/Core/CMakeLists.txt
index 6393c6fe38c2..688a39d9a10f 100644
--- a/lldb/unittests/Core/CMakeLists.txt
+++ b/lldb/unittests/Core/CMakeLists.txt
@@ -1,5 +1,4 @@
 add_lldb_unittest(LLDBCoreTests
-  CommunicationTest.cpp
   MangledTest.cpp
   RichManglingContextTest.cpp
   StreamCallbackTest.cpp

diff  --git a/lldb/unittests/Core/CommunicationTest.cpp 
b/lldb/unittests/Core/CommunicationTest.cpp
deleted file mode 100644
index 6ad0bc720d93..
--- a/lldb/unittests/Core/CommunicationTest.cpp
+++ /dev/null
@@ -1,35 +0,0 @@
-//===-- CommunicationTest.cpp 
-===//
-//
-// 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 "lldb/Core/Communication.h"
-#include "lldb/Host/ConnectionFileDescriptor.h"
-#include "lldb/Host/Pipe.h"
-#include "llvm/Testing/Support/Error.h"
-#include "gtest/gtest.h"
-
-using namespace lldb_private;
-
-TEST(CommunicationTest, SynchronizeWhileClosing) {
-  // Set up a communication object reading from a pipe.
-  Pipe pipe;
-  ASSERT_THAT_ERROR(pipe.CreateNew(/*child_process_inherit=*/false).ToError(),
-llvm::Succeeded());
-
-  Communication comm("test");
-  comm.SetConnection(std::make_unique(
-  pipe.ReleaseReadFileDescriptor(), /*owns_fd=*/true));
-  comm.SetCloseOnEOF(true);
-  ASSERT_TRUE(comm.StartReadThread());
-
-  // Ensure that we can safely synchronize with the read thread while it is
-  // closing the read end (in response to us closing the write end).
-  pipe.CloseWriteFileDescriptor();
-  comm.SynchronizeWithReadThread();
-
-  ASSERT_TRUE(comm.StopReadThread());
-}



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

[Lldb-commits] [lldb] 769d704 - Recommit "[lldb/Core] Fix a race in the Communication class"

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-09T13:39:00+02:00
New Revision: 769d7041cc1457dc2c5bcd040f24d530af48b76b

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

LOG: Recommit "[lldb/Core] Fix a race in the Communication class"

The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.

The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
  events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
  for the event
- Disconnect(): close the connection. This is the only bit that needs to
  be in the critical section, and this is to ensure that we don't close
  the connection while the synchronizing thread is mucking with it.

Original commit message follows:

Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.

However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.

This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.

The fix is to hold the synchronization mutex while closing the
connection.

I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.

The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

Added: 
lldb/unittests/Core/CommunicationTest.cpp

Modified: 
lldb/source/Core/Communication.cpp
lldb/unittests/Core/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index f4163847e4bb..c3e421191b01 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -315,16 +315,12 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   Status error;
   ConnectionStatus status = eConnectionStatusSuccess;
   bool done = false;
+  bool disconnect = false;
   while (!done && comm->m_read_thread_enabled) {
 size_t bytes_read = comm->ReadFromConnection(
 buf, sizeof(buf), std::chrono::seconds(5), status, &error);
-if (bytes_read > 0)
+if (bytes_read > 0 || status == eConnectionStatusEndOfFile)
   comm->AppendBytesToCache(buf, bytes_read, true, status);
-else if ((bytes_read == 0) && status == eConnectionStatusEndOfFile) {
-  if (comm->GetCloseOnEOF())
-comm->Disconnect();
-  comm->AppendBytesToCache(buf, bytes_read, true, status);
-}
 
 switch (status) {
 case eConnectionStatusSuccess:
@@ -332,11 +328,12 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
 
 case eConnectionStatusEndOfFile:
   done = true;
+  disconnect = comm->GetCloseOnEOF();
   break;
 case eConnectionStatusError: // Check GetError() for details
   if (error.GetType() == eErrorTypePOSIX && error.GetError() == EIO) {
 // EIO on a pipe is usually caused by remote shutdown
-comm->Disconnect();
+disconnect = comm->GetCloseOnEOF();
 done = true;
   }
   if (error.Fail())
@@ -365,9 +362,15 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   if (log)
 LLDB_LOGF(log, "%p Communication::ReadThread () thread exiting...", p);
 
-  comm->m_read_thread_did_exit = true;
-  // Let clients know that this thread is exiting
   comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
+  {
+std::lock_guard guard(comm->m_synchronize_mutex);
+comm->m_read_thread_did_exit = true;
+if (disconnect)
+  comm->Disconnect();
+  

[Lldb-commits] [lldb] a9406da - [lldb] Add parts accidentally left out of 769d704: Recommit "[lldb/Core] Fix a race in the Communication class"

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-09T14:45:23+02:00
New Revision: a9406daaa60f9899955a59c27f39db5519a9

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

LOG: [lldb] Add parts accidentally left out of 769d704: Recommit "[lldb/Core] 
Fix a race in the Communication class"

I went to a great length to explain the reason why these changes were
needed, but I did not actually ammend the patch to include them. :(

Added: 


Modified: 
lldb/source/Core/Communication.cpp

Removed: 




diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index c3e421191b01..2990f4157584 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -362,10 +362,17 @@ lldb::thread_result_t 
Communication::ReadThread(lldb::thread_arg_t p) {
   if (log)
 LLDB_LOGF(log, "%p Communication::ReadThread () thread exiting...", p);
 
-  comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
+  // Handle threads wishing to synchronize with us.
   {
-std::lock_guard guard(comm->m_synchronize_mutex);
+// Prevent new ones from showing up.
 comm->m_read_thread_did_exit = true;
+
+// Unblock any existing thread waiting for the synchronization signal.
+comm->BroadcastEvent(eBroadcastBitNoMorePendingInput);
+
+// Wait for the thread to finish...
+std::lock_guard guard(comm->m_synchronize_mutex);
+// ... and disconnect.
 if (disconnect)
   comm->Disconnect();
   }



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

[Lldb-commits] [lldb] 9aa5fbb - [lldb] Disable the new Communication test on windows

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-09T15:19:24+02:00
New Revision: 9aa5fbb3afed00deb2faad4ac7963c5d3247815d

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

LOG: [lldb] Disable the new Communication test on windows

The ConnectionFileDescriptor class on windows does not support
interruption (see the BytesAvailable method). Therefore this test makes
no sense there.

Added: 


Modified: 
lldb/unittests/Core/CommunicationTest.cpp

Removed: 




diff  --git a/lldb/unittests/Core/CommunicationTest.cpp 
b/lldb/unittests/Core/CommunicationTest.cpp
index 6ad0bc720d93..3ddc78d4a5af 100644
--- a/lldb/unittests/Core/CommunicationTest.cpp
+++ b/lldb/unittests/Core/CommunicationTest.cpp
@@ -14,6 +14,7 @@
 
 using namespace lldb_private;
 
+#ifndef _WIN32
 TEST(CommunicationTest, SynchronizeWhileClosing) {
   // Set up a communication object reading from a pipe.
   Pipe pipe;
@@ -33,3 +34,4 @@ TEST(CommunicationTest, SynchronizeWhileClosing) {
 
   ASSERT_TRUE(comm.StopReadThread());
 }
+#endif



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

Re: [Lldb-commits] [lldb] 680082a - [lldb/Reproducers] Add a small artificial delay before exiting

[Pavel Labath via lldb-commits]

On 09/04/2020 20:51, Jonas Devlieghere via lldb-commits wrote:
> 
> 
> On Thu, Apr 9, 2020 at 11:39 AM Davide Italiano  > wrote:
> 
> 
> 
> > On Apr 9, 2020, at 11:05, Jonas Devlieghere via lldb-commits
> mailto:lldb-commits@lists.llvm.org>>
> wrote:
> >
> >
> > Author: Jonas Devlieghere
> > Date: 2020-04-09T11:03:24-07:00
> > New Revision: 680082a408dd2df7410d77696100eac8ce9d5530
> >
> > URL:
> 
> https://github.com/llvm/llvm-project/commit/680082a408dd2df7410d77696100eac8ce9d5530
> > DIFF:
> 
> https://github.com/llvm/llvm-project/commit/680082a408dd2df7410d77696100eac8ce9d5530.diff
> >
> > LOG: [lldb/Reproducers] Add a small artificial delay before exiting
> >
> > Add a small artificial delay in replay mode before exiting to ensure
> > that all asynchronous events have completed. This should reduce the
> > level of replay flakiness on some of the slower bots.
> >
> > Added:
> >
> >
> > Modified:
> >    lldb/source/Utility/ReproducerInstrumentation.cpp
> >
> > Removed:
> >
> >
> >
> >
> 
> 
> > diff  --git a/lldb/source/Utility/ReproducerInstrumentation.cpp
> b/lldb/source/Utility/ReproducerInstrumentation.cpp
> > index 4c32d9407830..3bf81286bbe9 100644
> > --- a/lldb/source/Utility/ReproducerInstrumentation.cpp
> > +++ b/lldb/source/Utility/ReproducerInstrumentation.cpp
> > @@ -8,6 +8,7 @@
> >
> > #include "lldb/Utility/ReproducerInstrumentation.h"
> > #include "lldb/Utility/Reproducer.h"
> > +#include 
> > #include 
> > #include 
> >
> > @@ -94,6 +95,10 @@ bool Registry::Replay(llvm::StringRef buffer) {
> >     GetReplayer(id)->operator()(deserializer);
> >   }
> >
> > +  // Add a small artificial delay to ensure that all asynchronous
> events have
> > +  // completed before we exit.
> > +  std::this_thread::sleep_for (std::chrono::milliseconds(100));
> > +
> >   return true;
> > }
> >
> 
> I understand this is (unfortunately) sorely needed, but I’m somehow
> skeptical of random delays.
> You probably thought about this and dropped the idea on the floor —
> but, is there a way to make the sync more explicit?
> If you can’t, at least you can detect not everything is in order and
> sleep, for, e.g. another 100 milliseconds in a retry-loop?
> 
> 
> Yeah, it's a hack, and I'm not really happy with it. The last replayed
> API call can be literaly anything, so you don't know what you might have
> to wait for. I can't think of a good way to do the synchronization
> without breaking layering/abstractions. The issue on GreenDragon was
> that we exited before the stop event came in, and while we could
> probably synchronize that, it would be even more ad-hoc than this...  
>  
> 

Wouldn't the original session suffer from the same problem? I.e., if the
thread making the last SB call exited very quickly (or the other thread
was slightly delayed), then we'd get the same crash even without
reproducers. It probably doesn't happen very often because the path
taken by real code is slower than the reproducer main loop, but it could
still happen in theory.

If so, than that would mean we either have a bug in lldb, or in the code
which uses it (lack of SBDebugger::Terminate ?). And that this code is
papering over that bug...

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

[Lldb-commits] [lldb] e0dbd02 - [lldb/test] Make TestLoadUnload compatible with windows

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-14T11:10:59+02:00
New Revision: e0dbd025131c4d77d8a5050a91d391d950529a8c

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

LOG: [lldb/test] Make TestLoadUnload compatible with windows

Summary:
This patch introduces a header "dylib.h" which can be used in tests to
handle shared libraries semi-portably. The shared library APIs on
windows and posix systems look very different, but their underlying
functionality is relatively similar, so the mapping is not difficult.

It also introduces two new macros to wrap the functinality necessary to
export/import function across the dll boundary on windows. Previously we
had the LLDB_TEST_API macro for this purpose, which automagically
changed meaning depending on whether we were building the shared library
or the executable. While convenient for simple cases, this approach was
not sufficient for the more complicated setups where one deals with
multiple shared libraries.

Lastly it rewrites TestLoadUnload, to make use of the new APIs. The
trickiest aspect there is the handling of DYLD_LIBRARY_PATH on macos --
previously setting this variable was not needed as the test used
@executable_path-relative dlopens, but the new generic api does not
support that. Other systems do not support such dlopens either so the
test already contained support for setting the appropriate path
variable, and this patch just makes that logic more generic. In doesn't
seem that the purpose of this test was to exercise @executable_path
imports, so this should not be a problem.

These changes are sufficient to make some of the TestLoadUnload tests
pass on windows. Two other tests will start to pass once D77287 lands.

Reviewers: amccarth, jingham, JDevlieghere, compnerd

Subscribers: lldb-commits

Tags: #lldb

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

Added: 
lldb/packages/Python/lldbsuite/test/make/dylib.h

Modified: 
lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
lldb/packages/Python/lldbsuite/test/make/test_common.h
lldb/test/API/functionalities/load_unload/Makefile
lldb/test/API/functionalities/load_unload/TestLoadUnload.py
lldb/test/API/functionalities/load_unload/a.cpp
lldb/test/API/functionalities/load_unload/b.cpp
lldb/test/API/functionalities/load_unload/d.cpp
lldb/test/API/functionalities/load_unload/main.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py 
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index 32c9c20d6eea..44659cac4c77 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -166,19 +166,20 @@ def findMainThreadCheckerDylib():
 class _PlatformContext(object):
 """Value object class which contains platform-specific options."""
 
-def __init__(self, shlib_environment_var, shlib_prefix, shlib_extension):
+def __init__(self, shlib_environment_var, shlib_path_separator, 
shlib_prefix, shlib_extension):
 self.shlib_environment_var = shlib_environment_var
+self.shlib_path_separator = shlib_path_separator
 self.shlib_prefix = shlib_prefix
 self.shlib_extension = shlib_extension
 
 
 def createPlatformContext():
 if platformIsDarwin():
-return _PlatformContext('DYLD_LIBRARY_PATH', 'lib', 'dylib')
+return _PlatformContext('DYLD_LIBRARY_PATH', ':', 'lib', 'dylib')
 elif getPlatform() in ("freebsd", "linux", "netbsd"):
-return _PlatformContext('LD_LIBRARY_PATH', 'lib', 'so')
+return _PlatformContext('LD_LIBRARY_PATH', ':', 'lib', 'so')
 else:
-return None
+return _PlatformContext('PATH', ';', '', 'dll')
 
 
 def hasChattyStderr(test_case):

diff  --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules 
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index 4ae54561a28f..ea0fa748bc36 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -474,7 +474,7 @@ endif
 # Additional system libraries
 #--
 ifeq (1,$(USE_LIBDL))
-   ifneq ($(OS),NetBSD)
+   ifeq (,$(filter $(OS), NetBSD Windows_NT))
LDFLAGS += -ldl
endif
 endif

diff  --git a/lldb/packages/Python/lldbsuite/test/make/dylib.h 
b/lldb/packages/Python/lldbsuite/test/make/dylib.h
new file mode 100644
index ..50abcdbca9a2
--- /dev/null
+++ b/lldb/packages/Python/lldbsuite/test/make/dylib.h
@@ -0,0 +1,55 @@
+#ifndef LLDB_TEST_DYLIB_H
+#define LLDB_TEST_DYLIB_H
+
+#include 
+
+#ifdef _WIN32
+#include 
+
+#define dylib_get_symbol(handle,

[Lldb-commits] [lldb] ff18a6a - [lldb] Fix -Wparentheses in ThreadPlanStack.cpp

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-15T12:47:57+02:00
New Revision: ff18a6acea318f739ced2a1d35a39cb874d2be91

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

LOG: [lldb] Fix -Wparentheses in ThreadPlanStack.cpp

Added: 


Modified: 
lldb/source/Target/ThreadPlanStack.cpp

Removed: 




diff  --git a/lldb/source/Target/ThreadPlanStack.cpp 
b/lldb/source/Target/ThreadPlanStack.cpp
index c51946aae71c..1cfc41dcd390 100644
--- a/lldb/source/Target/ThreadPlanStack.cpp
+++ b/lldb/source/Target/ThreadPlanStack.cpp
@@ -142,8 +142,8 @@ void ThreadPlanStack::PushPlan(lldb::ThreadPlanSP 
new_plan_sp) {
   // If the thread plan doesn't already have a tracer, give it its parent's
   // tracer:
   // The first plan has to be a base plan:
-  assert(m_plans.size() > 0 ||
- new_plan_sp->IsBasePlan() && "Zeroth plan must be a base plan");
+  assert((m_plans.size() > 0 || new_plan_sp->IsBasePlan()) &&
+ "Zeroth plan must be a base plan");
 
   if (!new_plan_sp->GetThreadPlanTracer()) {
 assert(!m_plans.empty());



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

[Lldb-commits] [lldb] d5c26f8 - [lldb/unittests] Better error messages when creating sockets fails

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-16T11:59:37+02:00
New Revision: d5c26f871b7ee81e7bc6cc17cfddc9d08befe971

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

LOG: [lldb/unittests] Better error messages when creating sockets fails

We get failures in SocketTestUtilities on the pre-merge bots. This
might give us a clue as to what's wrong.

Added: 


Modified: 
lldb/unittests/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/Host/SocketTestUtilities.cpp 
b/lldb/unittests/Host/SocketTestUtilities.cpp
index 858d64f9b4fc..ab883531bdf2 100644
--- a/lldb/unittests/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/Host/SocketTestUtilities.cpp
@@ -33,10 +33,10 @@ void lldb_private::CreateConnectedSockets(
   Status error;
   std::unique_ptr listen_socket_up(
   new SocketType(true, child_processes_inherit));
-  EXPECT_FALSE(error.Fail());
+  ASSERT_THAT_ERROR(error.ToError(), llvm::Succeeded());
   error = listen_socket_up->Listen(listen_remote_address, 5);
-  EXPECT_FALSE(error.Fail());
-  EXPECT_TRUE(listen_socket_up->IsValid());
+  ASSERT_THAT_ERROR(error.ToError(), llvm::Succeeded());
+  ASSERT_TRUE(listen_socket_up->IsValid());
 
   Status accept_error;
   Socket *accept_socket;
@@ -47,21 +47,19 @@ void lldb_private::CreateConnectedSockets(
   std::string connect_remote_address = get_connect_addr(*listen_socket_up);
   std::unique_ptr connect_socket_up(
   new SocketType(true, child_processes_inherit));
-  EXPECT_FALSE(error.Fail());
+  ASSERT_THAT_ERROR(error.ToError(), llvm::Succeeded());
   error = connect_socket_up->Connect(connect_remote_address);
-  EXPECT_FALSE(error.Fail());
-  EXPECT_TRUE(connect_socket_up->IsValid());
+  ASSERT_THAT_ERROR(error.ToError(), llvm::Succeeded());
+  ASSERT_TRUE(connect_socket_up->IsValid());
 
   a_up->swap(connect_socket_up);
-  EXPECT_TRUE(error.Success());
-  EXPECT_NE(nullptr, a_up->get());
-  EXPECT_TRUE((*a_up)->IsValid());
+  ASSERT_TRUE((*a_up)->IsValid());
 
   accept_thread.join();
   b_up->reset(static_cast(accept_socket));
-  EXPECT_TRUE(accept_error.Success());
-  EXPECT_NE(nullptr, b_up->get());
-  EXPECT_TRUE((*b_up)->IsValid());
+  ASSERT_THAT_ERROR(accept_error.ToError(), llvm::Succeeded());
+  ASSERT_NE(nullptr, b_up->get());
+  ASSERT_TRUE((*b_up)->IsValid());
 
   listen_socket_up.reset();
 }



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

[Lldb-commits] [lldb] 6afa5c4 - [lldb] Prefer executable files from sysroot over files from local filesystem

[Pavel Labath via lldb-commits]

Author: Yuri Per
Date: 2020-04-20T16:12:51+02:00
New Revision: 6afa5c407c1330efcadb75b8f85993660bf275a7

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

LOG: [lldb] Prefer executable files from sysroot over files from local 
filesystem

Summary:
In D49685 sysroot behaviour was partially fixed. But files from local 
filesystem with same path still has priority over files from sysroot.

This patch fixes it by removing fallback to local filesystem from 
RemoteAwarePlatform::GetModuleSpec(). It is not actually required because 
higher level code do such fallback itself. See, for example, resolver in 
Platform::GetSharedModule().

Reviewers: labath, clayborg, EugeneBi

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Target/RemoteAwarePlatform.cpp
lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64.core

Removed: 




diff  --git a/lldb/source/Target/RemoteAwarePlatform.cpp 
b/lldb/source/Target/RemoteAwarePlatform.cpp
index 86f6b9045f70..d45e8e644a71 100644
--- a/lldb/source/Target/RemoteAwarePlatform.cpp
+++ b/lldb/source/Target/RemoteAwarePlatform.cpp
@@ -21,7 +21,7 @@ bool RemoteAwarePlatform::GetModuleSpec(const FileSpec 
&module_file_spec,
 return m_remote_platform_sp->GetModuleSpec(module_file_spec, arch,
module_spec);
 
-  return Platform::GetModuleSpec(module_file_spec, arch, module_spec);
+  return false;
 }
 
 Status RemoteAwarePlatform::RunShellCommand(

diff  --git 
a/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py 
b/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
index 5a1eab3f9018..435d3358b030 100644
--- a/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ b/lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -209,6 +209,44 @@ def test_i386_sysroot(self):
 
 self.dbg.DeleteTarget(target)
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("X86")
+@skipIfWindows
+def test_x86_64_sysroot(self):
+"""Test that sysroot has more priority then local filesystem."""
+
+# Copy wrong executable to the location outside of sysroot
+exe_outside = os.path.join(self.getBuildDir(), "bin", "a.out")
+lldbutil.mkdir_p(os.path.dirname(exe_outside))
+shutil.copyfile("altmain.out", exe_outside)
+
+# Copy correct executable to the location inside sysroot
+tmp_sysroot = os.path.join(self.getBuildDir(), "mock_sysroot")
+exe_inside = os.path.join(tmp_sysroot, os.path.relpath(exe_outside, 
"/"))
+lldbutil.mkdir_p(os.path.dirname(exe_inside))
+shutil.copyfile("linux-x86_64.out", exe_inside)
+
+# Prepare patched core file
+core_file = os.path.join(self.getBuildDir(), "patched.core")
+with open("linux-x86_64.core", "rb") as f:
+core = f.read()
+core = replace_path(core, "/test" * 817 + "/a.out", exe_outside)
+with open(core_file, "wb") as f:
+f.write(core)
+
+# Set sysroot and load core
+self.runCmd("platform select remote-linux --sysroot '%s'" % 
tmp_sysroot)
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore(core_file)
+
+# Check that we found executable from the sysroot
+mod_path = str(target.GetModuleAtIndex(0).GetFileSpec())
+self.assertEqual(mod_path, exe_inside)
+self.check_all(process, self._x86_64_pid, self._x86_64_regions, 
"a.out")
+
+self.dbg.DeleteTarget(target)
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("ARM")
 def test_arm_core(self):
@@ -369,3 +407,9 @@ def do_test(self, filename, pid, region_count, thread_name):
 self.check_all(process, pid, region_count, thread_name)
 
 self.dbg.DeleteTarget(target)
+
+def replace_path(binary, replace_from, replace_to):
+src = replace_from.encode()
+dst = replace_to.encode()
+dst += b"\0" * (len(src) - len(dst))
+return binary.replace(src, dst)

diff  --git 
a/lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64.core 
b/lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64.core
index e2fa69e4558e..2675eadd6a7f 100644
Binary files 
a/lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64.core and 
b/lldb/test/API/functionalities/postmortem/elf-core/linux-x86_64.core 
diff er



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

[Lldb-commits] [lldb] 9cd9f3f - [lldb] Fix gcc warnings in TypeCategory.cpp

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-20T16:12:51+02:00
New Revision: 9cd9f3f1b8b7bfd30f7140c4c0006be5cead3e9a

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

LOG: [lldb] Fix gcc warnings in TypeCategory.cpp

The cleanup in 3e3701f8a0bf left these variable unused.

Added: 


Modified: 
lldb/source/DataFormatters/TypeCategory.cpp

Removed: 




diff  --git a/lldb/source/DataFormatters/TypeCategory.cpp 
b/lldb/source/DataFormatters/TypeCategory.cpp
index 0cfa8d7eff78..8368c91a57f1 100644
--- a/lldb/source/DataFormatters/TypeCategory.cpp
+++ b/lldb/source/DataFormatters/TypeCategory.cpp
@@ -112,17 +112,15 @@ bool TypeCategoryImpl::Get(lldb::LanguageType lang,
   if (!IsEnabled() || !IsApplicable(lang))
 return false;
   TypeFilterImpl::SharedPointer filter_sp;
-  bool regex_filter = false;
   // first find both Filter and Synth, and then check which is most recent
 
   if (!GetTypeFiltersContainer()->Get(candidates, filter_sp))
-regex_filter = GetRegexTypeFiltersContainer()->Get(candidates, filter_sp);
+GetRegexTypeFiltersContainer()->Get(candidates, filter_sp);
 
-  bool regex_synth = false;
   bool pick_synth = false;
   ScriptedSyntheticChildren::SharedPointer synth;
   if (!GetTypeSyntheticsContainer()->Get(candidates, synth))
-regex_synth = GetRegexTypeSyntheticsContainer()->Get(candidates, synth);
+GetRegexTypeSyntheticsContainer()->Get(candidates, synth);
   if (!filter_sp.get() && !synth.get())
 return false;
   else if (!filter_sp.get() && synth.get())



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

[Lldb-commits] [lldb] 865996d - [lldb] Remove m_last_file_sp from SourceManager

[Pavel Labath via lldb-commits]

Author: Emre Kultursay
Date: 2020-04-20T16:27:19+02:00
New Revision: 865996ddf626a4d6e2a9c401b1fffc731a1946aa

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

LOG: [lldb] Remove m_last_file_sp from SourceManager

Summary:
...and replace it with m_last_file_spec instead.

When Source Cache is enabled, the value stored in m_last_file_sp is
already in the Source Cache, and caching it again in SourceManager
brings no extra benefit. All we need is to "remember" the last used
file, and FileSpec can serve the same purpose.

When Source Cache is disabled, the user explicitly requested no caching
of source files, and therefore, m_last_file_sp should NOT be used.

Bug: llvm.org/PR45310

Depends on D76805.

Reviewers: labath, jingham

Reviewed By: jingham

Subscribers: labath, lldb-commits

Tags: #lldb

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

Added: 
lldb/test/API/commands/settings/use_source_cache/Makefile
lldb/test/API/commands/settings/use_source_cache/TestUseSourceCache.py
lldb/test/API/commands/settings/use_source_cache/main.cpp

Modified: 
lldb/include/lldb/Core/SourceManager.h
lldb/source/Core/SourceManager.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/SourceManager.h 
b/lldb/include/lldb/Core/SourceManager.h
index 90ee59402d98..2bbb36e50456 100644
--- a/lldb/include/lldb/Core/SourceManager.h
+++ b/lldb/include/lldb/Core/SourceManager.h
@@ -119,7 +119,7 @@ class SourceManager {
 
   ~SourceManager();
 
-  FileSP GetLastFile() { return m_last_file_sp; }
+  FileSP GetLastFile() { return GetFile(m_last_file_spec); }
 
   size_t
   DisplaySourceLinesWithLineNumbers(const FileSpec &file, uint32_t line,
@@ -141,7 +141,9 @@ class SourceManager {
 
   bool GetDefaultFileAndLine(FileSpec &file_spec, uint32_t &line);
 
-  bool DefaultFileAndLineSet() { return (m_last_file_sp.get() != nullptr); }
+  bool DefaultFileAndLineSet() {
+return (GetFile(m_last_file_spec).get() != nullptr);
+  }
 
   void FindLinesMatchingRegex(FileSpec &file_spec, RegularExpression ®ex,
   uint32_t start_line, uint32_t end_line,
@@ -150,7 +152,7 @@ class SourceManager {
   FileSP GetFile(const FileSpec &file_spec);
 
 protected:
-  FileSP m_last_file_sp;
+  FileSpec m_last_file_spec;
   uint32_t m_last_line;
   uint32_t m_last_count;
   bool m_default_set;

diff  --git a/lldb/source/Core/SourceManager.cpp 
b/lldb/source/Core/SourceManager.cpp
index 4edc11c99bf1..7414dd281d43 100644
--- a/lldb/source/Core/SourceManager.cpp
+++ b/lldb/source/Core/SourceManager.cpp
@@ -52,27 +52,24 @@ static inline bool is_newline_char(char ch) { return ch == 
'\n' || ch == '\r'; }
 
 // SourceManager constructor
 SourceManager::SourceManager(const TargetSP &target_sp)
-: m_last_file_sp(), m_last_line(0), m_last_count(0), m_default_set(false),
+: m_last_line(0), m_last_count(0), m_default_set(false),
   m_target_wp(target_sp),
   m_debugger_wp(target_sp->GetDebugger().shared_from_this()) {}
 
 SourceManager::SourceManager(const DebuggerSP &debugger_sp)
-: m_last_file_sp(), m_last_line(0), m_last_count(0), m_default_set(false),
-  m_target_wp(), m_debugger_wp(debugger_sp) {}
+: m_last_line(0), m_last_count(0), m_default_set(false), m_target_wp(),
+  m_debugger_wp(debugger_sp) {}
 
 // Destructor
 SourceManager::~SourceManager() {}
 
 SourceManager::FileSP SourceManager::GetFile(const FileSpec &file_spec) {
-  bool same_as_previous =
-  m_last_file_sp &&
-  FileSpec::Match(file_spec, m_last_file_sp->GetFileSpec());
+  if (!file_spec)
+return nullptr;
 
   DebuggerSP debugger_sp(m_debugger_wp.lock());
   FileSP file_sp;
-  if (same_as_previous)
-file_sp = m_last_file_sp;
-  else if (debugger_sp && debugger_sp->GetUseSourceCache())
+  if (debugger_sp && debugger_sp->GetUseSourceCache())
 file_sp = debugger_sp->GetSourceFileCache().FindSourceFile(file_spec);
 
   TargetSP target_sp(m_target_wp.lock());
@@ -178,10 +175,10 @@ size_t 
SourceManager::DisplaySourceLinesWithLineNumbersUsingLastFile(
   m_last_line = start_line;
   m_last_count = count;
 
-  if (m_last_file_sp.get()) {
+  if (FileSP last_file_sp = GetLastFile()) {
 const uint32_t end_line = start_line + count - 1;
 for (uint32_t line = start_line; line <= end_line; ++line) {
-  if (!m_last_file_sp->LineIsValid(line)) {
+  if (!last_file_sp->LineIsValid(line)) {
 m_last_line = UINT32_MAX;
 break;
   }
@@ -219,12 +216,12 @@ size_t 
SourceManager::DisplaySourceLinesWithLineNumbersUsingLastFile(
 columnToHighlight = column - 1;
 
   size_t this_line_size =
-  m_last_file_sp->DisplaySourceLines(line, columnToHighlight, 0, 0, s);
+  last_file_sp->DisplaySourceLines(line, columnToHighlight, 0, 0, s);
   

[Lldb-commits] [lldb] acae69d - [lldb] Add new LLDB setting: use-source-cache

[Pavel Labath via lldb-commits]

Author: Emre Kultursay
Date: 2020-04-20T16:24:25+02:00
New Revision: acae69d08c88b701e25318f8d4100f5542c44407

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

LOG: [lldb] Add new LLDB setting: use-source-cache

Summary:
LLDB memory-maps large source files, and at the same time, caches
all source files in the Source Cache.

On Windows, memory-mapped source files are not writeable, causing
bad user experience in IDEs (such as errors when saving edited files).
IDEs should have the ability to disable the Source Cache at LLDB
startup, so that users can edit source files while debugging.

Bug: llvm.org/PR45310

Reviewers: labath, JDevlieghere, jingham

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/include/lldb/API/SBDebugger.h
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Core/SourceManager.h
lldb/source/API/SBDebugger.cpp
lldb/source/Core/CoreProperties.td
lldb/source/Core/Debugger.cpp
lldb/source/Core/SourceManager.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 84879be5e0db..21fe77fa4f15 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -199,6 +199,10 @@ class LLDB_API SBDebugger {
 
   bool GetUseColor() const;
 
+  bool SetUseSourceCache(bool use_source_cache);
+
+  bool GetUseSourceCache() const;
+
   static bool GetDefaultArchitecture(char *arch_name, size_t arch_name_len);
 
   static bool SetDefaultArchitecture(const char *arch_name);

diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 4340f32fd6f3..0524e63beb59 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -273,6 +273,10 @@ class Debugger : public 
std::enable_shared_from_this,
 
   bool SetUseColor(bool use_color);
 
+  bool GetUseSourceCache() const;
+
+  bool SetUseSourceCache(bool use_source_cache);
+
   bool GetHighlightSource() const;
 
   lldb::StopShowColumn GetStopShowColumn() const;

diff  --git a/lldb/include/lldb/Core/SourceManager.h 
b/lldb/include/lldb/Core/SourceManager.h
index c039200ca442..90ee59402d98 100644
--- a/lldb/include/lldb/Core/SourceManager.h
+++ b/lldb/include/lldb/Core/SourceManager.h
@@ -101,6 +101,9 @@ class SourceManager {
 void AddSourceFile(const FileSP &file_sp);
 FileSP FindSourceFile(const FileSpec &file_spec) const;
 
+// Removes all elements from the cache.
+void Clear() { m_file_cache.clear(); }
+
   protected:
 typedef std::map FileCache;
 FileCache m_file_cache;

diff  --git a/lldb/source/API/SBDebugger.cpp b/lldb/source/API/SBDebugger.cpp
index 1aeb5e2ca9ff..414d85e64363 100644
--- a/lldb/source/API/SBDebugger.cpp
+++ b/lldb/source/API/SBDebugger.cpp
@@ -1374,6 +1374,18 @@ bool SBDebugger::GetUseColor() const {
   return (m_opaque_sp ? m_opaque_sp->GetUseColor() : false);
 }
 
+bool SBDebugger::SetUseSourceCache(bool value) {
+  LLDB_RECORD_METHOD(bool, SBDebugger, SetUseSourceCache, (bool), value);
+
+  return (m_opaque_sp ? m_opaque_sp->SetUseSourceCache(value) : false);
+}
+
+bool SBDebugger::GetUseSourceCache() const {
+  LLDB_RECORD_METHOD_CONST_NO_ARGS(bool, SBDebugger, GetUseSourceCache);
+
+  return (m_opaque_sp ? m_opaque_sp->GetUseSourceCache() : false);
+}
+
 bool SBDebugger::GetDescription(SBStream &description) {
   LLDB_RECORD_METHOD(bool, SBDebugger, GetDescription, (lldb::SBStream &),
  description);

diff  --git a/lldb/source/Core/CoreProperties.td 
b/lldb/source/Core/CoreProperties.td
index 73294349438a..b04738175f34 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -103,6 +103,10 @@ let Definition = "debugger" in {
 Global,
 DefaultTrue,
 Desc<"Whether to use Ansi color codes or not.">;
+  def UseSourceCache: Property<"use-source-cache", "Boolean">,
+Global,
+DefaultTrue,
+Desc<"Whether to cache source files in memory or not.">;
   def AutoOneLineSummaries: Property<"auto-one-line-summaries", "Boolean">,
 Global,
 DefaultTrue,

diff  --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 68eb856b85f0..1d4bf0dafb72 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -212,6 +212,11 @@ Status Debugger::SetPropertyValue(const ExecutionContext 
*exe_ctx,
   // use-color changed. Ping the prompt so it can reset the ansi terminal
   // codes.
   SetPrompt(GetPrompt());
+} else if (property_path == 
g_debugger_properties[ePropertyUseSourceCache].name) {
+  // use-source-cache changed. Wipe out the cache contents if it was 
disabled.
+  if (!GetUseSourceCache()) {
+

[Lldb-commits] [lldb] 1f820fa - [lldb] Fix SourceManager::SourceFileCache insertion

[Pavel Labath via lldb-commits]

Author: Emre Kultursay
Date: 2020-04-20T16:25:54+02:00
New Revision: 1f820fa4feda34d25e62762392c50049e5282330

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

LOG: [lldb] Fix SourceManager::SourceFileCache insertion

Summary:
Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.

Bug: llvm.org/PR45310

Depends on D76804.

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: mgorny, jingham, lldb-commits

Tags: #lldb

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

Added: 
lldb/unittests/Core/SourceManagerTest.cpp

Modified: 
lldb/source/Core/SourceManager.cpp
lldb/unittests/Core/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Core/SourceManager.cpp 
b/lldb/source/Core/SourceManager.cpp
index 593459ba4509..4edc11c99bf1 100644
--- a/lldb/source/Core/SourceManager.cpp
+++ b/lldb/source/Core/SourceManager.cpp
@@ -696,7 +696,7 @@ bool SourceManager::File::GetLine(uint32_t line_no, 
std::string &buffer) {
 }
 
 void SourceManager::SourceFileCache::AddSourceFile(const FileSP &file_sp) {
-  FileSpec file_spec;
+  FileSpec file_spec = file_sp->GetFileSpec();
   FileCache::iterator pos = m_file_cache.find(file_spec);
   if (pos == m_file_cache.end())
 m_file_cache[file_spec] = file_sp;

diff  --git a/lldb/unittests/Core/CMakeLists.txt 
b/lldb/unittests/Core/CMakeLists.txt
index 6393c6fe38c2..a2cc5a7f1f6d 100644
--- a/lldb/unittests/Core/CMakeLists.txt
+++ b/lldb/unittests/Core/CMakeLists.txt
@@ -2,6 +2,7 @@ add_lldb_unittest(LLDBCoreTests
   CommunicationTest.cpp
   MangledTest.cpp
   RichManglingContextTest.cpp
+  SourceManagerTest.cpp
   StreamCallbackTest.cpp
   UniqueCStringMapTest.cpp
 

diff  --git a/lldb/unittests/Core/SourceManagerTest.cpp 
b/lldb/unittests/Core/SourceManagerTest.cpp
new file mode 100644
index ..9dcd048ce3fb
--- /dev/null
+++ b/lldb/unittests/Core/SourceManagerTest.cpp
@@ -0,0 +1,48 @@
+//===-- SourceManagerTest.cpp 
-===//
+//
+// 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 "lldb/Core/SourceManager.h"
+#include "lldb/Host/FileSystem.h"
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+class SourceFileCache : public ::testing::Test {
+public:
+  void SetUp() override { FileSystem::Initialize(); }
+  void TearDown() override { FileSystem::Terminate(); }
+};
+
+TEST_F(SourceFileCache, FindSourceFileFound) {
+  SourceManager::SourceFileCache cache;
+
+  // Insert: foo
+  FileSpec foo_file_spec("foo");
+  auto foo_file_sp =
+  std::make_shared(foo_file_spec, nullptr);
+  cache.AddSourceFile(foo_file_sp);
+
+  // Query: foo, expect found.
+  FileSpec another_foo_file_spec("foo");
+  ASSERT_EQ(cache.FindSourceFile(another_foo_file_spec), foo_file_sp);
+}
+
+TEST_F(SourceFileCache, FindSourceFileNotFound) {
+  SourceManager::SourceFileCache cache;
+
+  // Insert: foo
+  FileSpec foo_file_spec("foo");
+  auto foo_file_sp =
+  std::make_shared(foo_file_spec, nullptr);
+  cache.AddSourceFile(foo_file_sp);
+
+  // Query: bar, expect not found.
+  FileSpec bar_file_spec("bar");
+  ASSERT_EQ(cache.FindSourceFile(bar_file_spec), nullptr);
+}



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

[Lldb-commits] [lldb] c9e6b70 - [lldb/Host] Modernize some socket functions

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-23T14:20:26+02:00
New Revision: c9e6b7010c6998b6df50ff376425d1d4e4937bea

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

LOG: [lldb/Host] Modernize some socket functions

return Expected instead of a Status object plus a Socket*&
argument.

Added: 


Modified: 
lldb/include/lldb/Host/Socket.h
lldb/include/lldb/Host/common/UDPSocket.h
lldb/source/Host/common/Socket.cpp
lldb/source/Host/common/UDPSocket.cpp
lldb/source/Host/posix/ConnectionFileDescriptorPosix.cpp
lldb/unittests/Host/SocketTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Host/Socket.h b/lldb/include/lldb/Host/Socket.h
index 77562276d352..36db0ec63e9d 100644
--- a/lldb/include/lldb/Host/Socket.h
+++ b/lldb/include/lldb/Host/Socket.h
@@ -36,6 +36,8 @@ typedef SOCKET NativeSocket;
 #else
 typedef int NativeSocket;
 #endif
+class TCPSocket;
+class UDPSocket;
 
 class Socket : public IOObject {
 public:
@@ -64,13 +66,16 @@ class Socket : public IOObject {
   // Initialize a Tcp Socket object in listening mode.  listen and accept are
   // implemented separately because the caller may wish to manipulate or query
   // the socket after it is initialized, but before entering a blocking accept.
-  static Status TcpListen(llvm::StringRef host_and_port,
-  bool child_processes_inherit, Socket *&socket,
-  Predicate *predicate, int backlog = 5);
-  static Status TcpConnect(llvm::StringRef host_and_port,
-   bool child_processes_inherit, Socket *&socket);
-  static Status UdpConnect(llvm::StringRef host_and_port,
-   bool child_processes_inherit, Socket *&socket);
+  static llvm::Expected>
+  TcpListen(llvm::StringRef host_and_port, bool child_processes_inherit,
+Predicate *predicate, int backlog = 5);
+
+  static llvm::Expected>
+  TcpConnect(llvm::StringRef host_and_port, bool child_processes_inherit);
+
+  static llvm::Expected>
+  UdpConnect(llvm::StringRef host_and_port, bool child_processes_inherit);
+
   static Status UnixDomainConnect(llvm::StringRef host_and_port,
   bool child_processes_inherit,
   Socket *&socket);

diff  --git a/lldb/include/lldb/Host/common/UDPSocket.h 
b/lldb/include/lldb/Host/common/UDPSocket.h
index b3db4fa29f6e..bae707e345d8 100644
--- a/lldb/include/lldb/Host/common/UDPSocket.h
+++ b/lldb/include/lldb/Host/common/UDPSocket.h
@@ -16,8 +16,8 @@ class UDPSocket : public Socket {
 public:
   UDPSocket(bool should_close, bool child_processes_inherit);
 
-  static Status Connect(llvm::StringRef name, bool child_processes_inherit,
-Socket *&socket);
+  static llvm::Expected>
+  Connect(llvm::StringRef name, bool child_processes_inherit);
 
   std::string GetRemoteConnectionURI() const override;
 

diff  --git a/lldb/source/Host/common/Socket.cpp 
b/lldb/source/Host/common/Socket.cpp
index 45c2f9eb1e41..4bcf34a6b456 100644
--- a/lldb/source/Host/common/Socket.cpp
+++ b/lldb/source/Host/common/Socket.cpp
@@ -147,71 +147,65 @@ std::unique_ptr Socket::Create(const 
SocketProtocol protocol,
   return socket_up;
 }
 
-Status Socket::TcpConnect(llvm::StringRef host_and_port,
-  bool child_processes_inherit, Socket *&socket) {
-  Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_COMMUNICATION));
-  LLDB_LOGF(log, "Socket::%s (host/port = %s)", __FUNCTION__,
-host_and_port.str().c_str());
+llvm::Expected>
+Socket::TcpConnect(llvm::StringRef host_and_port,
+   bool child_processes_inherit) {
+  Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_CONNECTION));
+  LLDB_LOG(log, "host_and_port = {0}", host_and_port);
 
   Status error;
   std::unique_ptr connect_socket(
   Create(ProtocolTcp, child_processes_inherit, error));
   if (error.Fail())
-return error;
+return error.ToError();
 
   error = connect_socket->Connect(host_and_port);
   if (error.Success())
-socket = connect_socket.release();
+return std::move(connect_socket);
 
-  return error;
+  return error.ToError();
 }
 
-Status Socket::TcpListen(llvm::StringRef host_and_port,
- bool child_processes_inherit, Socket *&socket,
- Predicate *predicate, int backlog) {
+llvm::Expected>
+Socket::TcpListen(llvm::StringRef host_and_port, bool child_processes_inherit,
+  Predicate *predicate, int backlog) {
   Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_CONNECTION));
-  LLDB_LOGF(log, "Socket::%s (%s)", __FUNCTION__, host_and_port.str().c_str());
+  LLDB_LOG(log, "host_and_port = {0}", host_and_port);
 
   Status error;
   std::string host_

[Lldb-commits] [lldb] 7cfa74f - [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-23T16:12:41+02:00
New Revision: 7cfa74fc6948cc1969244a4e800de6a728951897

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

LOG: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address 
tables

Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for compile unit range information, and
this logic is a big cause of llvm/lldb divergence in the lowest layers
of dwarf parsing code.

The implicit assumption in that code is that this information (as opposed to
DW_AT_ranges) is unreliable. However, I have not been able to verify
that assumption. It is definitely not true for all present-day
compilers (gcc, clang, icc), and it was also not the case for the
historic compilers that I have been able to get a hold of (thanks Matt
Godbolt).

All compiler included in my research either produced correct
DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo
pc at all. The detailed findings are:
- gcc >= 4.4: produces DW_AT_ranges and .debug_aranges
- 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
  present. The upper version range here is uncertain as godbolt.org does
  not have intermediate versions.
- gcc < 4.1: no versions on godbolt.org
- clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges
- 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
  present.
- clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges
- icc >= 16.0.1: produces DW_AT_ranges
- icc < 16.0.1: no functional versions on godbolt.org (some are present
  but fail to compile)

Based on this analysis, I believe it is safe to start trusting
DW_AT_low/high_pc information in dwarf as well as remove the code for
manually reconstructing range information by traversing the DIE
structure, and just keep the line table fallback. The only compilers
where this will change behavior are pre-3.4 clangs, which are almost 7
years old now. However, the functionality should remain unchanged
because we will be able to reconstruct this information from the line
table, which seems to be needed for some line-tables-only scenarios
anyway (haven't researched this too much, but at least some compilers
seem to emit DW_AT_ranges even in these situations).

In addition, benchmarks showed that for these compilers computing the
ranges via line tables is noticably faster than doing so via the DIE
tree.

Other advantages include simplifying the code base, removing some
untested code (the only test changes are recent tests with overly
reduced synthetic dwarf), and increasing llvm convergence.

Tags: #lldb

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

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
lldb/test/Shell/SymbolFile/DWARF/DW_AT_loclists_base.s
lldb/test/Shell/SymbolFile/DWARF/debug_loc.s

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
index 66fcbfdcc0ec..f54fe0662aa2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
@@ -33,41 +33,27 @@ void DWARFCompileUnit::BuildAddressRangeTable(
 
   size_t num_debug_aranges = debug_aranges->GetNumRanges();
 
-  // First get the compile unit DIE only and check if it has a DW_AT_ranges
+  // First get the compile unit DIE only and check contains ranges information.
   const DWARFDebugInfoEntry *die = GetUnitDIEPtrOnly();
 
   const dw_offset_t cu_offset = GetOffset();
   if (die) {
 DWARFRangeList ranges;
 const size_t num_ranges =
-die->GetAttributeAddressRanges(this, ranges, false);
+die->GetAttributeAddressRanges(this, ranges, /*check_hi_lo_pc=*/true);
 if (num_ranges > 0) {
-  // This compile unit has DW_AT_ranges, assume this is correct if it is
-  // present since clang no longer makes .debug_aranges by default and it
-  // emits DW_AT_ranges for DW_TAG_compile_units. GCC also does this with
-  // recent GCC builds.
   for (size_t i = 0; i < num_ranges; ++i) {
 const DWARFRangeList::Entry &range = ranges.GetEntryRef(i);
 debug_aranges->AppendRange(cu_offset, range.GetRangeBase(),
range.GetRangeEnd());
   }
 
-  return; // We got all of our ranges from the DW_AT_ranges attribute
+  return;
 }
   }
-  // We don't have a DW_AT_ranges attribute, so we need to parse the DWARF
-
-  // If the DIEs weren't parsed, then we don't want all dies for all compi

[Lldb-commits] [lldb] f512b97 - [lldb/Utility] Improve error_code->Status conversion

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-23T16:12:41+02:00
New Revision: f512b978b0ebd09be08d879acb4feb7846370cd5

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

LOG: [lldb/Utility] Improve error_code->Status conversion

Both entities have the notion of error "namespaces". Map the errno
namespace correctly.

Added: 


Modified: 
lldb/source/Utility/Status.cpp
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/source/Utility/Status.cpp b/lldb/source/Utility/Status.cpp
index c8ca485cdd3b..e3c4284a8e8a 100644
--- a/lldb/source/Utility/Status.cpp
+++ b/lldb/source/Utility/Status.cpp
@@ -42,8 +42,13 @@ Status::Status() : m_code(0), m_type(eErrorTypeInvalid), 
m_string() {}
 Status::Status(ValueType err, ErrorType type)
 : m_code(err), m_type(type), m_string() {}
 
+// This logic is confusing because c++ calls the traditional (posix) errno 
codes
+// "generic errors", while we use the term "generic" to mean completely
+// arbitrary (text-based) errors.
 Status::Status(std::error_code EC)
-: m_code(EC.value()), m_type(ErrorType::eErrorTypeGeneric),
+: m_code(EC.value()),
+  m_type(EC.category() == std::generic_category() ? eErrorTypePOSIX
+  : eErrorTypeGeneric),
   m_string(EC.message()) {}
 
 Status::Status(const char *format, ...)

diff  --git a/lldb/unittests/Utility/StatusTest.cpp 
b/lldb/unittests/Utility/StatusTest.cpp
index 516f10b5b439..862c063b2e06 100644
--- a/lldb/unittests/Utility/StatusTest.cpp
+++ b/lldb/unittests/Utility/StatusTest.cpp
@@ -41,6 +41,15 @@ TEST(StatusTest, ErrorConstructor) {
   EXPECT_TRUE(foo.Success());
 }
 
+TEST(StatusTest, ErrorCodeConstructor) {
+  EXPECT_TRUE(Status(std::error_code()).Success());
+
+  Status eagain = std::error_code(EAGAIN, std::generic_category());
+  EXPECT_TRUE(eagain.Fail());
+  EXPECT_EQ(eErrorTypePOSIX, eagain.GetType());
+  EXPECT_EQ(Status::ValueType(EAGAIN), eagain.GetError());
+}
+
 TEST(StatusTest, ErrorConversion) {
   EXPECT_FALSE(bool(Status().ToError()));
 



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

[Lldb-commits] [lldb] 9321255 - [lldb/Core] Avoid more Communication::Disconnect races

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-23T16:36:21+02:00
New Revision: 9321255b8825d9165b2884204348a353af36d212

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

LOG: [lldb/Core] Avoid more Communication::Disconnect races

Calling Disconnect while the read thread is running is racy because the
thread can also call Disconnect.  This is a follow-up to b424b0bf, which
reorders other occurences of Disconnect/StopReadThread I can find, and also
adds an assertion to guard against new occurences being introduced.

Added: 


Modified: 
lldb/source/Core/Communication.cpp
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/source/Core/Communication.cpp 
b/lldb/source/Core/Communication.cpp
index 2990f4157584..b358e70b1a91 100644
--- a/lldb/source/Core/Communication.cpp
+++ b/lldb/source/Core/Communication.cpp
@@ -71,8 +71,8 @@ Communication::~Communication() {
 
 void Communication::Clear() {
   SetReadThreadBytesReceivedCallback(nullptr, nullptr);
-  Disconnect(nullptr);
   StopReadThread(nullptr);
+  Disconnect(nullptr);
 }
 
 ConnectionStatus Communication::Connect(const char *url, Status *error_ptr) {
@@ -93,6 +93,8 @@ ConnectionStatus Communication::Disconnect(Status *error_ptr) 
{
   LLDB_LOG(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_COMMUNICATION),
"{0} Communication::Disconnect ()", this);
 
+  assert((!m_read_thread_enabled || m_read_thread_did_exit) &&
+ "Disconnecting while the read thread is running is racy!");
   lldb::ConnectionSP connection_sp(m_connection_sp);
   if (connection_sp) {
 ConnectionStatus status = connection_sp->Disconnect(error_ptr);

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 45dcfc489d81..989cdae8b402 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -3316,8 +3316,8 @@ Status Process::Destroy(bool force_kill) {
   DidDestroy();
   StopPrivateStateThread();
 }
-m_stdio_communication.Disconnect();
 m_stdio_communication.StopReadThread();
+m_stdio_communication.Disconnect();
 m_stdin_forward = false;
 
 if (m_process_input_reader) {



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

[Lldb-commits] [lldb] 18e96a3 - [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-27T17:33:20+02:00
New Revision: 18e96a31fe0214eb435e131e6ff585a899694576

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

LOG: [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured

Sadly IPv6 is still not present anywhere. The test was attempting to
detect&skip such hosts, but the way it did that (essentially, by calling
getaddrinfo) meant that it only detected hosts which have IPv6 support
completely compiled out. It did not do anything about hosts which have
it compiled in, but lack runtime configuration even for the ::1 loopback
address.

This patch changes the detection logic to use a new method. It does it
by attempting to bind a socket to the appropriate loopback address. That
should ensure the hosts loopback interface is fully set up. In an effort
to avoid silently skipping the test on too many hosts, the test is
fairly strict about the kind of error it expects in these cases -- it
will only skip the test when receiving EADDRNOTAVAIL. If we find other
error codes that can be reasonably returned in these situations, we can
add more of them.

The (small) change in TCPSocket.cpp is to ensure that the code correctly
propagates the error received from the OS.

Added: 


Modified: 
lldb/source/Host/common/TCPSocket.cpp
lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
lldb/unittests/Host/SocketTest.cpp
lldb/unittests/Host/SocketTestUtilities.cpp
lldb/unittests/Host/SocketTestUtilities.h

Removed: 




diff  --git a/lldb/source/Host/common/TCPSocket.cpp 
b/lldb/source/Host/common/TCPSocket.cpp
index 821574e8d822..76ae7f2bd01c 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -42,6 +42,16 @@ typedef const void *set_socket_option_arg_type;
 using namespace lldb;
 using namespace lldb_private;
 
+static Status GetLastSocketError() {
+  std::error_code EC;
+#ifdef _WIN32
+  EC = llvm::mapWindowsError(WSAGetLastError());
+#else
+  EC = std::error_code(errno, std::generic_category());
+#endif
+  return EC;
+}
+
 namespace {
 const int kType = SOCK_STREAM;
 }
@@ -192,10 +202,8 @@ Status TCPSocket::Listen(llvm::StringRef name, int 
backlog) {
   for (SocketAddress &address : addresses) {
 int fd = Socket::CreateSocket(address.GetFamily(), kType, IPPROTO_TCP,
   m_child_processes_inherit, error);
-if (error.Fail()) {
-  error.Clear();
+if (error.Fail())
   continue;
-}
 
 // enable local address reuse
 int option_value = 1;
@@ -216,6 +224,7 @@ Status TCPSocket::Listen(llvm::StringRef name, int backlog) 
{
   err = ::listen(fd, backlog);
 
 if (-1 == err) {
+  error = GetLastSocketError();
   CLOSE_SOCKET(fd);
   continue;
 }
@@ -228,9 +237,11 @@ Status TCPSocket::Listen(llvm::StringRef name, int 
backlog) {
 m_listen_sockets[fd] = address;
   }
 
-  if (m_listen_sockets.size() == 0)
-error.SetErrorString("Failed to connect port");
-  return error;
+  if (m_listen_sockets.size() == 0) {
+assert(error.Fail());
+return error;
+  }
+  return Status();
 }
 
 void TCPSocket::CloseListenSockets() {

diff  --git a/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp 
b/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
index 655febc11d14..76c54a96b22e 100644
--- a/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
+++ b/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
@@ -22,11 +22,6 @@ class ConnectionFileDescriptorTest : public testing::Test {
   void TestGetURI(std::string ip) {
 std::unique_ptr socket_a_up;
 std::unique_ptr socket_b_up;
-if (!IsAddressFamilySupported(ip)) {
-  GTEST_LOG_(WARNING) << "Skipping test due to missing IPv"
-  << (IsIPv4(ip) ? "4" : "6") << " support.";
-  return;
-}
 CreateTCPConnectedSockets(ip, &socket_a_up, &socket_b_up);
 auto socket = socket_a_up.release();
 ConnectionFileDescriptor connection_file_descriptor(socket);
@@ -42,6 +37,14 @@ class ConnectionFileDescriptorTest : public testing::Test {
   }
 };
 
-TEST_F(ConnectionFileDescriptorTest, TCPGetURIv4) { TestGetURI("127.0.0.1"); }
-
-TEST_F(ConnectionFileDescriptorTest, TCPGetURIv6) { TestGetURI("::1"); }
+TEST_F(ConnectionFileDescriptorTest, TCPGetURIv4) {
+  if (!HostSupportsIPv4())
+return;
+  TestGetURI("127.0.0.1");
+}
+
+TEST_F(ConnectionFileDescriptorTest, TCPGetURIv6) {
+  if (!HostSupportsIPv6())
+return;
+  TestGetURI("::1");
+}

diff  --git a/lldb/unittests/Host/SocketTest.cpp 
b/lldb/unittests/Host/SocketTest.cpp
index 54548d36956c..c53d2660f0c8 100644
--- a/lldb/unittests/Host/SocketTest.cpp
+++ b/lldb/unittests/Host/SocketTest.cpp
@@ -111,10 +111,8 @@ TEST_F(SocketTest, TCPListen0ConnectAcc

[Lldb-commits] [lldb] 58435f6 - [lldb] Fix windows build break from 18e96a31

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-27T19:22:44+02:00
New Revision: 58435f69cb0db54e7a76d47101bbc5e74cb5c31c

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

LOG: [lldb] Fix windows build break from 18e96a31

Added: 


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

Removed: 




diff  --git a/lldb/source/Host/common/TCPSocket.cpp 
b/lldb/source/Host/common/TCPSocket.cpp
index 76ae7f2bd01c..d6f6b2cd30a7 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -18,6 +18,7 @@
 
 #include "llvm/Config/llvm-config.h"
 #include "llvm/Support/Errno.h"
+#include "llvm/Support/WindowsError.h"
 #include "llvm/Support/raw_ostream.h"
 
 #if LLDB_ENABLE_POSIX



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

[Lldb-commits] [lldb] f07f2ce - [lldb/unittest] Adjust CheckIPSupport function to avoid double-consume of llvm::Error

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-28T13:35:07+02:00
New Revision: f07f2cee9b4e19df78a19c9b2b552e2e5ba9d478

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

LOG: [lldb/unittest] Adjust CheckIPSupport function to avoid double-consume of 
llvm::Error

The problem caught by clang-tidy and reported by Tobias Bosch.

Added: 


Modified: 
lldb/unittests/Host/SocketTestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/Host/SocketTestUtilities.cpp 
b/lldb/unittests/Host/SocketTestUtilities.cpp
index c56b5f7a7809..e2006b85115d 100644
--- a/lldb/unittests/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/Host/SocketTestUtilities.cpp
@@ -101,16 +101,19 @@ static bool CheckIPSupport(llvm::StringRef Proto, 
llvm::StringRef Addr) {
  "Creating a canary {0} TCP socket failed: {1}.",
  Proto, Err)
  .str();
-  if (Err.isA() &&
-  errorToErrorCode(std::move(Err)) ==
-  std::make_error_code(std::errc::address_not_available)) {
+  bool HasAddrNotAvail = false;
+  handleAllErrors(std::move(Err), [&](std::unique_ptr ECErr) {
+if (ECErr->convertToErrorCode() ==
+std::make_error_code(std::errc::address_not_available))
+  HasAddrNotAvail = true;
+  });
+  if (HasAddrNotAvail) {
 GTEST_LOG_(WARNING)
 << llvm::formatv(
"Assuming the host does not support {0}. Skipping test.", Proto)
.str();
 return false;
   }
-  consumeError(std::move(Err));
   GTEST_LOG_(WARNING) << "Continuing anyway. The test will probably fail.";
   return true;
 }



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

[Lldb-commits] [lldb] 5cee8dd - [lldb-vscode] A couple of small style fixes

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-04-28T13:35:07+02:00
New Revision: 5cee8ddcc7535c95e4dd00fc428d2a52630eaa31

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

LOG: [lldb-vscode] A couple of small style fixes

to make the code conform to llvm style better:
- avoid use of auto where the type is not obivous
- avoid StringRef::data where it is not needed

No functional change intended.

Added: 


Modified: 
lldb/tools/lldb-vscode/JSONUtils.cpp
lldb/tools/lldb-vscode/lldb-vscode.cpp

Removed: 




diff  --git a/lldb/tools/lldb-vscode/JSONUtils.cpp 
b/lldb/tools/lldb-vscode/JSONUtils.cpp
index 2e7a57ee397e..8fcf179b29aa 100644
--- a/lldb/tools/lldb-vscode/JSONUtils.cpp
+++ b/lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -9,9 +9,9 @@
 #include 
 
 #include "llvm/ADT/Optional.h"
-
 #include "llvm/Support/FormatAdapters.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/ScopedPrinter.h"
 
 #include "lldb/API/SBBreakpoint.h"
 #include "lldb/API/SBBreakpointLocation.h"
@@ -41,8 +41,8 @@ llvm::StringRef GetAsString(const llvm::json::Value &value) {
 
 // Gets a string from a JSON object using the key, or returns an empty string.
 llvm::StringRef GetString(const llvm::json::Object &obj, llvm::StringRef key) {
-  if (auto value = obj.getString(key))
-return GetAsString(*value);
+  if (llvm::Optional value = obj.getString(key))
+return *value;
   return llvm::StringRef();
 }
 
@@ -114,13 +114,9 @@ std::vector GetStrings(const 
llvm::json::Object *obj,
   strs.push_back(value.getAsString()->str());
   break;
 case llvm::json::Value::Number:
-case llvm::json::Value::Boolean: {
-  std::string s;
-  llvm::raw_string_ostream strm(s);
-  strm << value;
-  strs.push_back(strm.str());
+case llvm::json::Value::Boolean:
+  strs.push_back(llvm::to_string(value));
   break;
-}
 case llvm::json::Value::Null:
 case llvm::json::Value::Object:
 case llvm::json::Value::Array:

diff  --git a/lldb/tools/lldb-vscode/lldb-vscode.cpp 
b/lldb/tools/lldb-vscode/lldb-vscode.cpp
index 04a2125e3456..b267ea088b1c 100644
--- a/lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ b/lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -531,15 +531,14 @@ void request_attach(const llvm::json::Object &request) {
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
   auto attachCommands = GetStrings(arguments, "attachCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
-  const auto debuggerRoot = GetString(arguments, "debuggerRoot");
+  const llvm::StringRef debuggerRoot = GetString(arguments, "debuggerRoot");
 
   // This is a hack for loading DWARF in .o files on Mac where the .o files
   // in the debug map of the main executable have relative paths which require
   // the lldb-vscode binary to have its working directory set to that relative
   // root for the .o files in order to be able to load debug info.
-  if (!debuggerRoot.empty()) {
-llvm::sys::fs::set_current_path(debuggerRoot.data());
-  }
+  if (!debuggerRoot.empty())
+llvm::sys::fs::set_current_path(debuggerRoot);
 
   // Run any initialize LLDB commands the user specified in the launch.json
   g_vsc.RunInitCommands();
@@ -1363,15 +1362,14 @@ void request_launch(const llvm::json::Object &request) {
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
   auto launchCommands = GetStrings(arguments, "launchCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
-  const auto debuggerRoot = GetString(arguments, "debuggerRoot");
+  const llvm::StringRef debuggerRoot = GetString(arguments, "debuggerRoot");
 
   // This is a hack for loading DWARF in .o files on Mac where the .o files
   // in the debug map of the main executable have relative paths which require
   // the lldb-vscode binary to have its working directory set to that relative
   // root for the .o files in order to be able to load debug info.
-  if (!debuggerRoot.empty()) {
-llvm::sys::fs::set_current_path(debuggerRoot.data());
-  }
+  if (!debuggerRoot.empty())
+llvm::sys::fs::set_current_path(debuggerRoot);
 
   // Run any initialize LLDB commands the user specified in the launch.json.
   // This is run before target is created, so commands can't do anything with



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