[Lldb-commits] [lldb] Address mask sbprocess apis and new mask invalid const (PR #83663)

2024-03-04 Thread David Spickett via lldb-commits

DavidSpickett wrote:

>  is about how TestAddressMasks.py assumes all Fix*Address implementations 
> will handle a low and high memory address mask. The test currently assumes 
> they do

I'm not sure it makes much difference unless handling low/high produces a large 
amount of boilerplate in every plugin.

It is a bit of a foot gun to be able to tell the plugin for, for example, Arm 
32, that it has high/low mem masks. Since they won't make any sense, but it's 
pretty well hidden.

If somehow Arm/ppc/mips/intel/s390x grew a need to handle high/low mem and 
needed zero changes other than the mask, folks would be able to just set it 
without changing lldb (though I expect that wouldn't be the only change needed 
anyway).

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


[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/83861

This patch should address some register parsing issue in the legacy report 
format.

rdar://107210149

>From b3ad739752a6e07eeeda47055d17a12fc960adcb Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Sun, 3 Mar 2024 01:07:14 -0800
Subject: [PATCH] [lldb/crashlog] Fix breaking changes in textual report format

This patch should address some register parsing issue in the legacy
report format.

rdar://107210149

Signed-off-by: Med Ismail Bennani 
---
 lldb/examples/python/crashlog.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index 9e4f94264037ae..c992348b24be17 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -849,10 +849,10 @@ def parse_errors(self, json_data):
 
 class TextCrashLogParser(CrashLogParser):
 parent_process_regex = re.compile(r"^Parent Process:\s*(.*)\[(\d+)\]")
-thread_state_regex = re.compile(r"^Thread \d+ crashed with")
+thread_state_regex = re.compile(r"^Thread (\d+ crashed with|State)")
 thread_instrs_regex = re.compile(r"^Thread \d+ instruction stream")
-thread_regex = re.compile(r"^Thread (\d+).*:")
-app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*:")
+thread_regex = re.compile(r"^Thread (\d+).*")
+app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*")
 
 class VersionRegex:
 version = r"\(.+\)|(?:arm|x86_)[0-9a-z]+"
@@ -1081,7 +1081,10 @@ def parse_normal(self, line):
 if thread_state_match:
 self.app_specific_backtrace = False
 thread_state_match = self.thread_regex.search(line)
-thread_idx = int(thread_state_match.group(1))
+if thread_state_match:
+thread_idx = int(thread_state_match.group(1))
+else:
+thread_idx = self.crashlog.crashed_thread_idx
 self.parse_mode = self.CrashLogParseMode.THREGS
 self.thread = self.crashlog.threads[thread_idx]
 return

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


[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Med Ismail Bennani (medismailben)


Changes

This patch should address some register parsing issue in the legacy report 
format.

rdar://107210149

---
Full diff: https://github.com/llvm/llvm-project/pull/83861.diff


1 Files Affected:

- (modified) lldb/examples/python/crashlog.py (+7-4) 


``diff
diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index 9e4f94264037ae..c992348b24be17 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -849,10 +849,10 @@ def parse_errors(self, json_data):
 
 class TextCrashLogParser(CrashLogParser):
 parent_process_regex = re.compile(r"^Parent Process:\s*(.*)\[(\d+)\]")
-thread_state_regex = re.compile(r"^Thread \d+ crashed with")
+thread_state_regex = re.compile(r"^Thread (\d+ crashed with|State)")
 thread_instrs_regex = re.compile(r"^Thread \d+ instruction stream")
-thread_regex = re.compile(r"^Thread (\d+).*:")
-app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*:")
+thread_regex = re.compile(r"^Thread (\d+).*")
+app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*")
 
 class VersionRegex:
 version = r"\(.+\)|(?:arm|x86_)[0-9a-z]+"
@@ -1081,7 +1081,10 @@ def parse_normal(self, line):
 if thread_state_match:
 self.app_specific_backtrace = False
 thread_state_match = self.thread_regex.search(line)
-thread_idx = int(thread_state_match.group(1))
+if thread_state_match:
+thread_idx = int(thread_state_match.group(1))
+else:
+thread_idx = self.crashlog.crashed_thread_idx
 self.parse_mode = self.CrashLogParseMode.THREGS
 self.thread = self.crashlog.threads[thread_idx]
 return

``




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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread Alexander M. via lldb-commits

https://github.com/amordo created 
https://github.com/llvm/llvm-project/pull/83871

Add `liblldb` dependency and use correct extension for compiled Lua module.

Replace 'Python' with 'Lua' in install path name.

Fixes #55075.

>From 678ea6f6e6234b72c93f2c5e5323f76cdf252377 Mon Sep 17 00:00:00 2001
From: Alexander Mordovskiy 
Date: Mon, 4 Mar 2024 17:41:31 +0100
Subject: [PATCH] [lldb/lua] Fix Lua building on Windows

Add liblldb dependency and use correct extension for compiled Lua module.

Replace 'Python' with 'Lua' in install path name.
---
 lldb/bindings/lua/CMakeLists.txt | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/lldb/bindings/lua/CMakeLists.txt b/lldb/bindings/lua/CMakeLists.txt
index 1a739a9805ec8a..2d128cc1864c87 100644
--- a/lldb/bindings/lua/CMakeLists.txt
+++ b/lldb/bindings/lua/CMakeLists.txt
@@ -28,7 +28,7 @@ endfunction()
 function(finish_swig_lua swig_target lldb_lua_bindings_dir lldb_lua_target_dir)
   add_custom_target(${swig_target} ALL VERBATIM
 COMMAND ${CMAKE_COMMAND} -E make_directory ${lldb_lua_target_dir}
-DEPENDS swig_wrapper_lua
+DEPENDS swig_wrapper_lua liblldb
 COMMENT "LLDB Lua API")
   if(LLDB_BUILD_FRAMEWORK)
 set(LIBLLDB_SYMLINK_DEST 
"${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/LLDB")
@@ -36,11 +36,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
 set(LIBLLDB_SYMLINK_DEST 
"${LLVM_SHLIB_OUTPUT_INTDIR}/liblldb${CMAKE_SHARED_LIBRARY_SUFFIX}")
   endif()
   if(WIN32)
-if(CMAKE_BUILD_TYPE STREQUAL Debug)
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb_d.pyd")
-else()
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb.pyd")
-endif()
+set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.dll")
   else()
 set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.so")
   endif()
@@ -54,7 +50,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
   add_dependencies(lldb ${swig_target})
 
   if(LLDB_BUILD_FRAMEWORK)
-set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Python)
+set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Lua)
   else()
 set(LLDB_LUA_INSTALL_PATH ${LLDB_LUA_RELATIVE_PATH})
   endif()

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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Alexander M. (amordo)


Changes

Add `liblldb` dependency and use correct extension for compiled Lua module.

Replace 'Python' with 'Lua' in install path name.

Fixes #55075.

---
Full diff: https://github.com/llvm/llvm-project/pull/83871.diff


1 Files Affected:

- (modified) lldb/bindings/lua/CMakeLists.txt (+3-7) 


``diff
diff --git a/lldb/bindings/lua/CMakeLists.txt b/lldb/bindings/lua/CMakeLists.txt
index 1a739a9805ec8a..2d128cc1864c87 100644
--- a/lldb/bindings/lua/CMakeLists.txt
+++ b/lldb/bindings/lua/CMakeLists.txt
@@ -28,7 +28,7 @@ endfunction()
 function(finish_swig_lua swig_target lldb_lua_bindings_dir lldb_lua_target_dir)
   add_custom_target(${swig_target} ALL VERBATIM
 COMMAND ${CMAKE_COMMAND} -E make_directory ${lldb_lua_target_dir}
-DEPENDS swig_wrapper_lua
+DEPENDS swig_wrapper_lua liblldb
 COMMENT "LLDB Lua API")
   if(LLDB_BUILD_FRAMEWORK)
 set(LIBLLDB_SYMLINK_DEST 
"${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/LLDB")
@@ -36,11 +36,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
 set(LIBLLDB_SYMLINK_DEST 
"${LLVM_SHLIB_OUTPUT_INTDIR}/liblldb${CMAKE_SHARED_LIBRARY_SUFFIX}")
   endif()
   if(WIN32)
-if(CMAKE_BUILD_TYPE STREQUAL Debug)
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb_d.pyd")
-else()
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb.pyd")
-endif()
+set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.dll")
   else()
 set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.so")
   endif()
@@ -54,7 +50,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
   add_dependencies(lldb ${swig_target})
 
   if(LLDB_BUILD_FRAMEWORK)
-set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Python)
+set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Lua)
   else()
 set(LLDB_LUA_INSTALL_PATH ${LLDB_LUA_RELATIVE_PATH})
   endif()

``




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


[Lldb-commits] [lldb] [llvm] [mlir] Split the llvm::ThreadPool into an abstract base class and an implementation (PR #82094)

2024-03-04 Thread Chris Lattner via lldb-commits

lattner wrote:

Nice work Mehdi!

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


[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

Can you add/modify a test? 

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


[Lldb-commits] [lldb] [lldb][test] Add test for chained PCH debugging (PR #83582)

2024-03-04 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl approved this pull request.


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


[Lldb-commits] [lldb] [lldb][test] Add test for chained PCH debugging (PR #83582)

2024-03-04 Thread Adrian Prantl via lldb-commits

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


[Lldb-commits] [lldb] [lldb][test] Add test for chained PCH debugging (PR #83582)

2024-03-04 Thread Adrian Prantl via lldb-commits


@@ -0,0 +1,10 @@
+include Makefile.rules
+
+OBJECTS += main.o
+
+$(EXE): $(BUILDDIR)/main.o
+
+$(BUILDDIR)/main.o: main.cpp
+   $(CC) -cc1 -emit-pch -x c++-header -fmodule-format=obj -fmodules -O0 
-dwarf-ext-refs -debug-info-kind=standalone $(SRCDIR)/base-pch.h -o 
base-pch.h.gch
+   $(CC) -cc1 -emit-pch -x c++-header -fmodule-format=obj -fmodules -O0 
-dwarf-ext-refs -debug-info-kind=standalone -include-pch base-pch.h.gch 
$(SRCDIR)/pch.h -o pch.h.gch
+   $(CC) -cc1 -emit-obj -x c++ -fmodules -O0 -dwarf-ext-refs 
-debug-info-kind=standalone -include-pch pch.h.gch $(SRCDIR)/main.cpp -o 
$(BUILDDIR)/main.o

adrian-prantl wrote:

I think this is not too bad as it is.

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


[Lldb-commits] [lldb] 252f3c9 - [lldb][test] Add test for chained PCH debugging (#83582)

2024-03-04 Thread via lldb-commits

Author: Michael Buch
Date: 2024-03-04T17:17:13Z
New Revision: 252f3c98db1383ee0e1f25020d488ffb7b4ac392

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

LOG: [lldb][test] Add test for chained PCH debugging (#83582)

Adds a test-case for debugging a program with a
pch chain, that is, the main executable depends
on a pch that itself included another pch.

Currently clang doesn't emit the sekeleton CUs
required for LLDB to track all types on the pch chain. Thus this test is
XFAILed for now.

Added: 
lldb/test/API/lang/cpp/gmodules/pch-chain/Makefile
lldb/test/API/lang/cpp/gmodules/pch-chain/TestPchChain.py
lldb/test/API/lang/cpp/gmodules/pch-chain/base-pch.h
lldb/test/API/lang/cpp/gmodules/pch-chain/main.cpp
lldb/test/API/lang/cpp/gmodules/pch-chain/pch.h

Modified: 


Removed: 




diff  --git a/lldb/test/API/lang/cpp/gmodules/pch-chain/Makefile 
b/lldb/test/API/lang/cpp/gmodules/pch-chain/Makefile
new file mode 100644
index 00..6477c25dedf7e1
--- /dev/null
+++ b/lldb/test/API/lang/cpp/gmodules/pch-chain/Makefile
@@ -0,0 +1,10 @@
+include Makefile.rules
+
+OBJECTS += main.o
+
+$(EXE): $(BUILDDIR)/main.o
+
+$(BUILDDIR)/main.o: main.cpp
+   $(CC) -cc1 -emit-pch -x c++-header -fmodule-format=obj -fmodules -O0 
-dwarf-ext-refs -debug-info-kind=standalone $(SRCDIR)/base-pch.h -o 
base-pch.h.gch
+   $(CC) -cc1 -emit-pch -x c++-header -fmodule-format=obj -fmodules -O0 
-dwarf-ext-refs -debug-info-kind=standalone -include-pch base-pch.h.gch 
$(SRCDIR)/pch.h -o pch.h.gch
+   $(CC) -cc1 -emit-obj -x c++ -fmodules -O0 -dwarf-ext-refs 
-debug-info-kind=standalone -include-pch pch.h.gch $(SRCDIR)/main.cpp -o 
$(BUILDDIR)/main.o

diff  --git a/lldb/test/API/lang/cpp/gmodules/pch-chain/TestPchChain.py 
b/lldb/test/API/lang/cpp/gmodules/pch-chain/TestPchChain.py
new file mode 100644
index 00..b08c6caa713be0
--- /dev/null
+++ b/lldb/test/API/lang/cpp/gmodules/pch-chain/TestPchChain.py
@@ -0,0 +1,73 @@
+"""
+Tests that we correctly track AST layout info
+(specifically alignment) when moving AST nodes
+between several ClangASTImporter instances
+(in this case, from a pch chain to executable
+to expression AST).
+"""
+
+import lldb
+import os
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestPchChain(TestBase):
+@add_test_categories(["gmodules"])
+@expectedFailureAll("Chained pch debugging currently not fully supported")
+def test_expr(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+self.target = self.dbg.CreateTarget(exe)
+self.assertTrue(self.target, VALID_TARGET)
+lldbutil.run_break_set_by_file_and_line(
+self, "main.cpp", 9, num_expected_locations=1
+)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+self.expect(
+"frame variable data",
+substrs=["row = 1", "col = 2", "row = 3", "col = 4", "stride = 5"],
+)
+
+@add_test_categories(["gmodules"])
+@expectedFailureAll("Chained pch debugging currently not fully supported")
+def test_frame_var(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+self.target = self.dbg.CreateTarget(exe)
+self.assertTrue(self.target, VALID_TARGET)
+lldbutil.run_break_set_by_file_and_line(
+self, "main.cpp", 9, num_expected_locations=1
+)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+self.expect_expr(
+"data",
+result_type="MatrixData",
+result_children=[
+ValueCheck(
+name="section",
+children=[
+ValueCheck(
+name="origin",
+children=[
+ValueCheck(name="row", value="1"),
+ValueCheck(name="col", value="2"),
+],
+),
+ValueCheck(
+name="size",
+children=[
+ValueCheck(name="row", value="3"),
+ValueCheck(name="col", value="4"),
+],
+),
+],
+),
+ValueCheck(name="stride", value="5"),
+],
+)

diff  --git a/lldb/test/API/lang/cpp/gmodules/pch-chain/base-pch.h 
b/lldb/test/API/lang/cpp/gmodules/pch-chain/base-pch.h
new file mode 100644
index 00..53dacd796f2c91
--- /dev/null
+++ b/lldb/test/API/lang/cpp/gmodules/pch-chain/base-pch.h
@@ -0,0 +1,9 @@
+#ifndef BASE_PCH_H_IN
+#define BAS

[Lldb-commits] [lldb] [lldb][test] Add test for chained PCH debugging (PR #83582)

2024-03-04 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] [lldb][test][NFC] Add option to exclude third_party packages (PR #83191)

2024-03-04 Thread Jordan Rupprecht via lldb-commits

rupprecht wrote:

> FYI @labath as the x86 bot owner.

I checked w/ them that 
[lldb-x86_64-debian](https://lab.llvm.org/buildbot/#/builders/68) has 
python3-pexpect (specifically 4.8) installed.

> > It should perhaps unset the variable first, I'll see if I can implement 
> > that.
> 
> [ec95379](https://github.com/llvm/llvm-project/commit/ec95379df363253ffcbbda21297417e703d5ccca)

Thanks! Cmake is still pretty foreign to me. It didn't occur to me that the 
result of finding a python library would be cached :) but I guess it makes 
sense from a build system perspective to not want to reconfigure everything all 
the time.

Since it sounds like all the bots should have `pexpect` now, I think I can flip 
the default later today and be ready to revert if there's unexpected breakage.

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


[Lldb-commits] [lldb] [lldb] Add support for sorting by size to `target module dump symtab` (PR #83527)

2024-03-04 Thread Jason Molenda via lldb-commits


@@ -138,6 +134,21 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder 
sort_order,
   }
 } break;
 
+case eSortOrderBySize: {
+  s->PutCString(" (sorted by size):\n");
+  DumpSymbolHeader(s);
+
+  std::multimap> size_map;
+  for (const Symbol &symbol : m_symbols)
+size_map.emplace(symbol.GetByteSize(), &symbol);
+
+  for (const auto &size_to_symbol : size_map) {
+const Symbol *symbol = size_to_symbol.second;
+s->Indent();
+symbol->Dump(s, target, symbol - &m_symbols[0], name_preference);

jasonmolenda wrote:

I don't have a strong opinion here but when it's sorted by address, the index 
is still sorted-ordering.  This is showing the original symtab index numbers. I 
think it should show the sorted index ordering, if someone wants to correspond 
a symbol to the original symtab, they can search for the symbol name.

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


[Lldb-commits] [lldb] Address mask sbprocess apis and new mask invalid const (PR #83663)

2024-03-04 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

> > is about how TestAddressMasks.py assumes all Fix*Address implementations 
> > will handle a low and high memory address mask. The test currently assumes 
> > they do
> 
> I'm not sure it makes much difference unless handling low/high produces a 
> large amount of boilerplate in every plugin.
> 
> It is a bit of a foot gun to be able to tell the plugin for, for example, Arm 
> 32, that it has high/low mem masks. Since they won't make any sense, but it's 
> pretty well hidden.

I agree, the more I think about this the less I'm delighted by making every 
plugin support high/low address masks when it may not make any sense there.  I 
like keeping the support in the SysV AArch64 ABI even though it's not used on 
Linux in case this ABI were used for generic AArch64 firmware debug scenario 
where someone might try to use that ABI plugin.  

In the API test, I can have a dedicated test for the highmem checks an only run 
it on aarch64/arm64 targets.  I can add a test for the non-aarch64/arm64 
targets which tests that setting the highmem mask has no effect (and remove the 
highmem support from the base ABI method impl).  


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


[Lldb-commits] [lldb] [lldb] Use sort-ordering for indexes when sorting by size (PR #83889)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere created 
https://github.com/llvm/llvm-project/pull/83889

Use sort-ordering for indexes when sorting by size. This addresses Jason's post 
commit review feedback.

>From 13b644f483a349bb853d917e0771e811a1bf9be2 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere 
Date: Mon, 4 Mar 2024 10:38:08 -0800
Subject: [PATCH] [lldb] Use sort-ordering for indexes when sorting by size

Use sort-ordering for indexes when sorting by size. This addresses
Jason's post commit review feedback.
---
 lldb/source/Symbol/Symtab.cpp   | 3 ++-
 .../Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test| 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index b7837892d7e26d..c63bbe94fece0e 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -142,10 +142,11 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder 
sort_order,
   for (const Symbol &symbol : m_symbols)
 size_map.emplace(symbol.GetByteSize(), &symbol);
 
+  size_t idx = 0;
   for (const auto &size_to_symbol : size_map) {
 const Symbol *symbol = size_to_symbol.second;
 s->Indent();
-symbol->Dump(s, target, symbol - &m_symbols[0], name_preference);
+symbol->Dump(s, target, idx++, name_preference);
   }
 } break;
 
diff --git a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test 
b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
index a9b6c0b1ef09b0..83b80236705e8e 100644
--- a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
+++ b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
@@ -4,8 +4,8 @@
 
 # CHECK: num_symbols = 4 (sorted by size):
 # CHECK: [0]  0  SX Code0x0040 
   0x00b0 0x ___lldb_unnamed_symbol0
-# CHECK: [3]  0   X Code0x004000d0 
   0x0022 0x _start
-# CHECK: [1]  0   X Code0x004000b0 
   0x0010 0x f1
-# CHECK: [2]  0   X Code0x004000c0 
   0x0010 0x f2
+# CHECK: [1]  0   X Code0x004000d0 
   0x0022 0x _start
+# CHECK: [2]  0   X Code0x004000b0 
   0x0010 0x f1
+# CHECK: [3]  0   X Code0x004000c0 
   0x0010 0x f2
 
 image dump symtab -s size symtab.out

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


[Lldb-commits] [lldb] [lldb] Add support for sorting by size to `target module dump symtab` (PR #83527)

2024-03-04 Thread Jonas Devlieghere via lldb-commits


@@ -138,6 +134,21 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder 
sort_order,
   }
 } break;
 
+case eSortOrderBySize: {
+  s->PutCString(" (sorted by size):\n");
+  DumpSymbolHeader(s);
+
+  std::multimap> size_map;
+  for (const Symbol &symbol : m_symbols)
+size_map.emplace(symbol.GetByteSize(), &symbol);
+
+  for (const auto &size_to_symbol : size_map) {
+const Symbol *symbol = size_to_symbol.second;
+s->Indent();
+symbol->Dump(s, target, symbol - &m_symbols[0], name_preference);

JDevlieghere wrote:

https://github.com/llvm/llvm-project/pull/83889

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


[Lldb-commits] [lldb] [lldb] Use sort-ordering for indexes when sorting by size (PR #83889)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)


Changes

Use sort-ordering for indexes when sorting by size. This addresses Jason's post 
commit review feedback.

---
Full diff: https://github.com/llvm/llvm-project/pull/83889.diff


2 Files Affected:

- (modified) lldb/source/Symbol/Symtab.cpp (+2-1) 
- (modified) lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test 
(+3-3) 


``diff
diff --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index b7837892d7e26d..c63bbe94fece0e 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -142,10 +142,11 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder 
sort_order,
   for (const Symbol &symbol : m_symbols)
 size_map.emplace(symbol.GetByteSize(), &symbol);
 
+  size_t idx = 0;
   for (const auto &size_to_symbol : size_map) {
 const Symbol *symbol = size_to_symbol.second;
 s->Indent();
-symbol->Dump(s, target, symbol - &m_symbols[0], name_preference);
+symbol->Dump(s, target, idx++, name_preference);
   }
 } break;
 
diff --git a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test 
b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
index a9b6c0b1ef09b0..83b80236705e8e 100644
--- a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
+++ b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
@@ -4,8 +4,8 @@
 
 # CHECK: num_symbols = 4 (sorted by size):
 # CHECK: [0]  0  SX Code0x0040 
   0x00b0 0x ___lldb_unnamed_symbol0
-# CHECK: [3]  0   X Code0x004000d0 
   0x0022 0x _start
-# CHECK: [1]  0   X Code0x004000b0 
   0x0010 0x f1
-# CHECK: [2]  0   X Code0x004000c0 
   0x0010 0x f2
+# CHECK: [1]  0   X Code0x004000d0 
   0x0022 0x _start
+# CHECK: [2]  0   X Code0x004000b0 
   0x0010 0x f1
+# CHECK: [3]  0   X Code0x004000c0 
   0x0010 0x f2
 
 image dump symtab -s size symtab.out

``




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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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

LGTM!

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


[Lldb-commits] [lldb] [lldb] Use sort-ordering for indexes when sorting by size (PR #83889)

2024-03-04 Thread Jason Molenda via lldb-commits

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


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


[Lldb-commits] [lldb] 1da5db9 - [lldb] Use sort-ordering for indexes when sorting by size (#83889)

2024-03-04 Thread via lldb-commits

Author: Jonas Devlieghere
Date: 2024-03-04T10:44:17-08:00
New Revision: 1da5db97cbf3451da05788b1d35b8a107a7f6a69

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

LOG: [lldb] Use sort-ordering for indexes when sorting by size (#83889)

Use sort-ordering for indexes when sorting by size. This addresses
Jason's post commit review feedback.

Added: 


Modified: 
lldb/source/Symbol/Symtab.cpp
lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test

Removed: 




diff  --git a/lldb/source/Symbol/Symtab.cpp b/lldb/source/Symbol/Symtab.cpp
index b7837892d7e26d..c63bbe94fece0e 100644
--- a/lldb/source/Symbol/Symtab.cpp
+++ b/lldb/source/Symbol/Symtab.cpp
@@ -142,10 +142,11 @@ void Symtab::Dump(Stream *s, Target *target, SortOrder 
sort_order,
   for (const Symbol &symbol : m_symbols)
 size_map.emplace(symbol.GetByteSize(), &symbol);
 
+  size_t idx = 0;
   for (const auto &size_to_symbol : size_map) {
 const Symbol *symbol = size_to_symbol.second;
 s->Indent();
-symbol->Dump(s, target, symbol - &m_symbols[0], name_preference);
+symbol->Dump(s, target, idx++, name_preference);
   }
 } break;
 

diff  --git a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test 
b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
index a9b6c0b1ef09b0..83b80236705e8e 100644
--- a/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
+++ b/lldb/test/Shell/SymbolFile/Breakpad/symtab-sorted-by-size.test
@@ -4,8 +4,8 @@
 
 # CHECK: num_symbols = 4 (sorted by size):
 # CHECK: [0]  0  SX Code0x0040 
   0x00b0 0x ___lldb_unnamed_symbol0
-# CHECK: [3]  0   X Code0x004000d0 
   0x0022 0x _start
-# CHECK: [1]  0   X Code0x004000b0 
   0x0010 0x f1
-# CHECK: [2]  0   X Code0x004000c0 
   0x0010 0x f2
+# CHECK: [1]  0   X Code0x004000d0 
   0x0022 0x _start
+# CHECK: [2]  0   X Code0x004000b0 
   0x0010 0x f1
+# CHECK: [3]  0   X Code0x004000c0 
   0x0010 0x f2
 
 image dump symtab -s size symtab.out



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


[Lldb-commits] [lldb] [lldb] Use sort-ordering for indexes when sorting by size (PR #83889)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Support DW_OP_WASM_location in DWARFExpression (PR #78977)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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

Apologies for the delay. LGTM!

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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

JDevlieghere wrote:

@amordo I don't know if you have commit access. Let me you need someone to 
press the merge button for you.

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


[Lldb-commits] [lldb] 503075e - [lldb][test][NFC] Narrow scope of `import pexpect`

2024-03-04 Thread Jordan Rupprecht via lldb-commits

Author: Jordan Rupprecht
Date: 2024-03-04T11:21:47-08:00
New Revision: 503075e4d4a9c1b3754b21ee9ec41f176e54fd83

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

LOG: [lldb][test][NFC] Narrow scope of `import pexpect`

We do not run `pexpect` based tests on Windows, but there are still cases where 
those tests run `import pexpect` outside of the scope where the test is 
skipped. By moving the import statement to a different scope, those tests can 
run even when `pexpect` truly isn't installed.

Tangentially related: TestSTTYBeforeAndAfter.py is using a manual 
`@expectedFailureAll` for windows instead of the common `@skipIfWindows`. If 
`pexepect` is generally expected to not be available, we should not bother 
running the test at all.

Added: 


Modified: 
lldb/test/API/driver/quit_speed/TestQuitWithProcess.py

lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
lldb/test/API/terminal/TestSTTYBeforeAndAfter.py

Removed: 




diff  --git a/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py 
b/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
index 957586d41f6b40..42527c88b99213 100644
--- a/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
+++ b/lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
@@ -2,12 +2,10 @@
 Test that killing the target while quitting doesn't stall
 """
 
-
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-import pexpect
 from lldbsuite.test.lldbpexpect import PExpectTest
 
 
@@ -16,6 +14,8 @@ class DriverQuitSpeedTest(PExpectTest):
 
 def test_run_quit(self):
 """Test that the lldb driver's batch mode works correctly."""
+import pexpect
+
 self.build()
 
 exe = self.getBuildArtifact("a.out")

diff  --git 
a/lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
 
b/lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
index ee35dbd23b3dbe..3cf7b9d2100891 100644
--- 
a/lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
+++ 
b/lldb/test/API/functionalities/progress_reporting/TestTrimmedProgressReporting.py
@@ -3,7 +3,6 @@
 """
 
 import os
-import pexpect
 import tempfile
 import re
 

diff  --git a/lldb/test/API/terminal/TestSTTYBeforeAndAfter.py 
b/lldb/test/API/terminal/TestSTTYBeforeAndAfter.py
index 31b960859fa2e5..e5663c50c736e6 100644
--- a/lldb/test/API/terminal/TestSTTYBeforeAndAfter.py
+++ b/lldb/test/API/terminal/TestSTTYBeforeAndAfter.py
@@ -19,10 +19,7 @@ def classCleanup(cls):
 cls.RemoveTempFile("child_send2.txt")
 cls.RemoveTempFile("child_read2.txt")
 
-@expectedFailureAll(
-hostoslist=["windows"],
-bugnumber="llvm.org/pr22274: need a pexpect replacement for windows",
-)
+@skipIfWindows  # llvm.org/pr22274: need a pexpect replacement for windows
 @no_debug_info_test
 def test_stty_dash_a_before_and_afetr_invoking_lldb_command(self):
 """Test that 'stty -a' displays the same output before and after 
running the lldb command."""



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


[Lldb-commits] [lldb] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (PR #83895)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben created 
https://github.com/llvm/llvm-project/pull/83895

This patch addresses an oversight in `ProcessEventDataTest::SetUp` unittest to 
ensure the Debugger is initialized properly.

>From 1ed521f9de503fd48834a250fb2f071c2d86b1c9 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 4 Mar 2024 11:00:15 -0800
Subject: [PATCH] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp
 (NFC)

This patch addresses an oversight in `ProcessEventDataTest::SetUp`
unittest to ensure the Debugger is initialized properly.

Signed-off-by: Med Ismail Bennani 
---
 lldb/unittests/Process/ProcessEventDataTest.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lldb/unittests/Process/ProcessEventDataTest.cpp 
b/lldb/unittests/Process/ProcessEventDataTest.cpp
index dd159496cd881d..9905e036a138e8 100644
--- a/lldb/unittests/Process/ProcessEventDataTest.cpp
+++ b/lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -16,6 +16,7 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "lldb/Utility/Event.h"
+#include "TestingSupport/TestUtilities.h"
 #include "gtest/gtest.h"
 
 using namespace lldb_private;
@@ -29,6 +30,8 @@ class ProcessEventDataTest : public ::testing::Test {
 FileSystem::Initialize();
 HostInfo::Initialize();
 PlatformMacOSX::Initialize();
+std::call_once(TestUtilities::g_debugger_initialize_flag,
+[]() { Debugger::Initialize(nullptr); });
   }
   void TearDown() override {
 PlatformMacOSX::Terminate();

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


[Lldb-commits] [lldb] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (PR #83895)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben updated 
https://github.com/llvm/llvm-project/pull/83895

>From 0b71b6aafe6a11875ebdb77ecafd63d1ad4556f4 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 4 Mar 2024 11:25:07 -0800
Subject: [PATCH] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp
 (NFC)

This patch addresses an oversight in `ProcessEventDataTest::SetUp`
unittest to ensure the Debugger is initialized properly.

Signed-off-by: Med Ismail Bennani 
---
 lldb/unittests/Process/ProcessEventDataTest.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lldb/unittests/Process/ProcessEventDataTest.cpp 
b/lldb/unittests/Process/ProcessEventDataTest.cpp
index dd159496cd881d..e793c6eae20a29 100644
--- a/lldb/unittests/Process/ProcessEventDataTest.cpp
+++ b/lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -8,6 +8,7 @@
 
 #include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "TestingSupport/TestUtilities.h"
 #include "lldb/Core/Debugger.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
@@ -29,6 +30,8 @@ class ProcessEventDataTest : public ::testing::Test {
 FileSystem::Initialize();
 HostInfo::Initialize();
 PlatformMacOSX::Initialize();
+std::call_once(TestUtilities::g_debugger_initialize_flag,
+   []() { Debugger::Initialize(nullptr); });
   }
   void TearDown() override {
 PlatformMacOSX::Terminate();

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


[Lldb-commits] [lldb] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (PR #83895)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread Alexander M. via lldb-commits

amordo wrote:

@JDevlieghere I have no write access, looking for help:)

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


[Lldb-commits] [lldb] f32c6b2 - [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (#83895)

2024-03-04 Thread via lldb-commits

Author: Med Ismail Bennani
Date: 2024-03-04T11:42:04-08:00
New Revision: f32c6b28b84130dc77e0e69d6d3b692aec933280

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

LOG: [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (#83895)

This patch addresses an oversight in `ProcessEventDataTest::SetUp`
unittest to ensure the Debugger is initialized properly.

Signed-off-by: Med Ismail Bennani 

Added: 


Modified: 
lldb/unittests/Process/ProcessEventDataTest.cpp

Removed: 




diff  --git a/lldb/unittests/Process/ProcessEventDataTest.cpp 
b/lldb/unittests/Process/ProcessEventDataTest.cpp
index dd159496cd881d..e793c6eae20a29 100644
--- a/lldb/unittests/Process/ProcessEventDataTest.cpp
+++ b/lldb/unittests/Process/ProcessEventDataTest.cpp
@@ -8,6 +8,7 @@
 
 #include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
 #include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "TestingSupport/TestUtilities.h"
 #include "lldb/Core/Debugger.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
@@ -29,6 +30,8 @@ class ProcessEventDataTest : public ::testing::Test {
 FileSystem::Initialize();
 HostInfo::Initialize();
 PlatformMacOSX::Initialize();
+std::call_once(TestUtilities::g_debugger_initialize_flag,
+   []() { Debugger::Initialize(nullptr); });
   }
   void TearDown() override {
 PlatformMacOSX::Terminate();



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


[Lldb-commits] [lldb] [lldb/Test] Fix oversight in ProcessEventDataTest::SetUp (NFC) (PR #83895)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

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


[Lldb-commits] [lldb] 79e8f29 - [lldb/lua] Fix Lua building on Windows (#83871)

2024-03-04 Thread via lldb-commits

Author: Alexander M
Date: 2024-03-04T11:54:24-08:00
New Revision: 79e8f29ab06560d159389d940c35c563e0c8640e

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

LOG: [lldb/lua] Fix Lua building on Windows (#83871)

Add `liblldb` dependency and use correct extension for compiled Lua
module.

Replace 'Python' with 'Lua' in install path name.

Fixes #55075.

Added: 


Modified: 
lldb/bindings/lua/CMakeLists.txt

Removed: 




diff  --git a/lldb/bindings/lua/CMakeLists.txt 
b/lldb/bindings/lua/CMakeLists.txt
index 1a739a9805ec8a..2d128cc1864c87 100644
--- a/lldb/bindings/lua/CMakeLists.txt
+++ b/lldb/bindings/lua/CMakeLists.txt
@@ -28,7 +28,7 @@ endfunction()
 function(finish_swig_lua swig_target lldb_lua_bindings_dir lldb_lua_target_dir)
   add_custom_target(${swig_target} ALL VERBATIM
 COMMAND ${CMAKE_COMMAND} -E make_directory ${lldb_lua_target_dir}
-DEPENDS swig_wrapper_lua
+DEPENDS swig_wrapper_lua liblldb
 COMMENT "LLDB Lua API")
   if(LLDB_BUILD_FRAMEWORK)
 set(LIBLLDB_SYMLINK_DEST 
"${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}/LLDB.framework/LLDB")
@@ -36,11 +36,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
 set(LIBLLDB_SYMLINK_DEST 
"${LLVM_SHLIB_OUTPUT_INTDIR}/liblldb${CMAKE_SHARED_LIBRARY_SUFFIX}")
   endif()
   if(WIN32)
-if(CMAKE_BUILD_TYPE STREQUAL Debug)
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb_d.pyd")
-else()
-  set(LIBLLDB_SYMLINK_OUTPUT_FILE "_lldb.pyd")
-endif()
+set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.dll")
   else()
 set(LIBLLDB_SYMLINK_OUTPUT_FILE "lldb.so")
   endif()
@@ -54,7 +50,7 @@ function(finish_swig_lua swig_target lldb_lua_bindings_dir 
lldb_lua_target_dir)
   add_dependencies(lldb ${swig_target})
 
   if(LLDB_BUILD_FRAMEWORK)
-set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Python)
+set(LLDB_LUA_INSTALL_PATH 
${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Resources/Lua)
   else()
 set(LLDB_LUA_INSTALL_PATH ${LLDB_LUA_RELATIVE_PATH})
   endif()



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


[Lldb-commits] [lldb] [lldb/lua] Fix Lua building on Windows (PR #83871)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Allow languages to filter breakpoints set by line (PR #83908)

2024-03-04 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan created 
https://github.com/llvm/llvm-project/pull/83908

Some languages may create artificial functions that have no real user code, 
even though there is line table information for them. One such case is with 
coroutine code that receives the CoroSplitter transformation in LLVM IR. That 
code transformation creates many different Functions, cloning one Instruction 
into many Instructions in many different Functions and copying the associated 
debug locations.

It would be difficult to make that pass delete debug locations of cloned 
instructions in a language agnostic way (is it even possible?), but LLDB can 
ignore certain locations by querying its Language APIs and having it decide 
based on, for example, mangling information.

>From 32ed57079eec7d33a87883e192cd928caa2f5f6d Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Mon, 4 Mar 2024 09:56:18 -0800
Subject: [PATCH] [lldb] Allow languages to filter breakpoints set by line

Some languages may create artificial functions that have no real user code, even
though there is line table information for them. One such case is with coroutine
code that receives the CoroSplitter transformation in LLVM IR. That code
transformation creates many different Functions, cloning one Instruction into
many Instructions in many different Functions and copying the associated debug
locations.

It would be difficult to make that pass delete debug locations of cloned
instructions in a language agnostic way (is it even possible?), but LLDB can
ignore certain locations by querying its Language APIs and having it decide
based on, for example, mangling information.
---
 lldb/include/lldb/Target/Language.h   |  4 
 lldb/source/Breakpoint/BreakpointResolver.cpp | 12 
 2 files changed, 16 insertions(+)

diff --git a/lldb/include/lldb/Target/Language.h 
b/lldb/include/lldb/Target/Language.h
index 0cbd8a32dccd54..957c40eb7c0772 100644
--- a/lldb/include/lldb/Target/Language.h
+++ b/lldb/include/lldb/Target/Language.h
@@ -339,6 +339,10 @@ class Language : public PluginInterface {
 
   virtual llvm::StringRef GetInstanceVariableName() { return {}; }
 
+  virtual bool IsInterestingCtxForLineBreakpoint(const SymbolContext &) const {
+return true;
+  }
+
 protected:
   // Classes that inherit from Language can see and modify these
 
diff --git a/lldb/source/Breakpoint/BreakpointResolver.cpp 
b/lldb/source/Breakpoint/BreakpointResolver.cpp
index bc6348716ef418..876b30c6d76d55 100644
--- a/lldb/source/Breakpoint/BreakpointResolver.cpp
+++ b/lldb/source/Breakpoint/BreakpointResolver.cpp
@@ -23,6 +23,7 @@
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Language.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
@@ -199,6 +200,15 @@ bool operator<(const SourceLoc lhs, const SourceLoc rhs) {
 }
 } // namespace
 
+static void
+ApplyLanguageFilters(llvm::SmallVectorImpl &sc_list) {
+  llvm::erase_if(sc_list, [](SymbolContext &sc) {
+if (Language *lang = Language::FindPlugin(sc.GetLanguage()))
+  return !lang->IsInterestingCtxForLineBreakpoint(sc);
+return false;
+  });
+}
+
 void BreakpointResolver::SetSCMatchesByLine(
 SearchFilter &filter, SymbolContextList &sc_list, bool skip_prologue,
 llvm::StringRef log_ident, uint32_t line, std::optional column) {
@@ -206,6 +216,8 @@ void BreakpointResolver::SetSCMatchesByLine(
   for (uint32_t i = 0; i < sc_list.GetSize(); ++i)
 all_scs.push_back(sc_list[i]);
 
+  ApplyLanguageFilters(all_scs);
+
   while (all_scs.size()) {
 uint32_t closest_line = UINT32_MAX;
 

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


[Lldb-commits] [lldb] [lldb] Allow languages to filter breakpoints set by line (PR #83908)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Felipe de Azevedo Piovezan (felipepiovezan)


Changes

Some languages may create artificial functions that have no real user code, 
even though there is line table information for them. One such case is with 
coroutine code that receives the CoroSplitter transformation in LLVM IR. That 
code transformation creates many different Functions, cloning one Instruction 
into many Instructions in many different Functions and copying the associated 
debug locations.

It would be difficult to make that pass delete debug locations of cloned 
instructions in a language agnostic way (is it even possible?), but LLDB can 
ignore certain locations by querying its Language APIs and having it decide 
based on, for example, mangling information.

---
Full diff: https://github.com/llvm/llvm-project/pull/83908.diff


2 Files Affected:

- (modified) lldb/include/lldb/Target/Language.h (+4) 
- (modified) lldb/source/Breakpoint/BreakpointResolver.cpp (+12) 


``diff
diff --git a/lldb/include/lldb/Target/Language.h 
b/lldb/include/lldb/Target/Language.h
index 0cbd8a32dccd54..957c40eb7c0772 100644
--- a/lldb/include/lldb/Target/Language.h
+++ b/lldb/include/lldb/Target/Language.h
@@ -339,6 +339,10 @@ class Language : public PluginInterface {
 
   virtual llvm::StringRef GetInstanceVariableName() { return {}; }
 
+  virtual bool IsInterestingCtxForLineBreakpoint(const SymbolContext &) const {
+return true;
+  }
+
 protected:
   // Classes that inherit from Language can see and modify these
 
diff --git a/lldb/source/Breakpoint/BreakpointResolver.cpp 
b/lldb/source/Breakpoint/BreakpointResolver.cpp
index bc6348716ef418..876b30c6d76d55 100644
--- a/lldb/source/Breakpoint/BreakpointResolver.cpp
+++ b/lldb/source/Breakpoint/BreakpointResolver.cpp
@@ -23,6 +23,7 @@
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Language.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
@@ -199,6 +200,15 @@ bool operator<(const SourceLoc lhs, const SourceLoc rhs) {
 }
 } // namespace
 
+static void
+ApplyLanguageFilters(llvm::SmallVectorImpl &sc_list) {
+  llvm::erase_if(sc_list, [](SymbolContext &sc) {
+if (Language *lang = Language::FindPlugin(sc.GetLanguage()))
+  return !lang->IsInterestingCtxForLineBreakpoint(sc);
+return false;
+  });
+}
+
 void BreakpointResolver::SetSCMatchesByLine(
 SearchFilter &filter, SymbolContextList &sc_list, bool skip_prologue,
 llvm::StringRef log_ident, uint32_t line, std::optional column) {
@@ -206,6 +216,8 @@ void BreakpointResolver::SetSCMatchesByLine(
   for (uint32_t i = 0; i < sc_list.GetSize(); ++i)
 all_scs.push_back(sc_list[i]);
 
+  ApplyLanguageFilters(all_scs);
+
   while (all_scs.size()) {
 uint32_t closest_line = UINT32_MAX;
 

``




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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread David Blaikie via lldb-commits

dwblaikie wrote:

I don't have really firm feelings/justification for this, but I'd have guessed 
that doing this as two separate (separated by a few days, maybe a week) 
renamings would be better for downstream consumers - they'd get a clear break 
without any ambiguity/name reuse.

No strong feels if other folks reckon doing it in one go is better/OK, though.

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

I would almost vote to change everything to `uint64_t` except for the public 
API since we can't change the API without breaking. Though I winder if we can 
actually change this one:
```
uint64_t SBValue::GetNumChildren();
```
Since the return value isn't mangled into the function name?

The reason I mention the uint64_t is `lldb::SBValue` and 
`lldb_private::ValueObject*` can represent _any_ object that can be expanded. 
We could have a `lldb::SBValue` that represents all of memory in a process 
where each object can represent an area in memory as a specific format and 
size. So a 64 bit process _could_ have a `SBValue` with `UINT64_MAX` children 
available if we wanted to have a `SBValue` that represented memory as `uint8_t` 
objects. 

So if we are going to change stuff around, I would vote to use `uint64_t` 
instead of `uint32_t`

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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread Mehdi Amini via lldb-commits

joker-eph wrote:

@dwblaikie : how would you split it? I didn't quite get the two renamings you 
have in mind?

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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread David Blaikie via lldb-commits

dwblaikie wrote:

> @dwblaikie : how would you split it? I didn't quite get the two renamings you 
> have in mind?

One patch `ThreadPool->DefaultThreadPool` (people get a build error about 
`ThreadPool` not being the name of anything, find this patch as the root cause, 
and rename all their ThreadPool->DefaultThreadPool)
Follow-up patch, `ThreadPoolInterface->ThreadPool` (similarly clear/separate 
errors)

Changing both in one patch risks folks getting confusing error messages because 
their existing ThreadPool usage will now instantly start being interpreted as 
the interface type - resulting in different/confusing errors about inability to 
instantiate abstract types, etc, presumably. Rather than just that the name is 
no longer present at all.

Ultimately they can root cause and figure out both renamings - probably not a 
huge deal either way, but my understanding was that separating them might be 
marginally better for downstrteamers.

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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread Paul T Robinson via lldb-commits

pogo59 wrote:

> separating them might be marginally better for downstrteamers.

Hear, hear.

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

clayborg wrote:

I would vote for `uint64_t` over `size_t` as `size_t` is 32 bits on 32 bit 
operating systems and we might be cross debugging to 64 bit systems that need 
`uint64_t`

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


[Lldb-commits] [lldb] [lldb] Print a message when background tasks take a while to complete (PR #82799)

2024-03-04 Thread Greg Clayton via lldb-commits

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


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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Alex Langford via lldb-commits

bulbazord wrote:

> I would almost vote to change everything to `uint64_t` except for the public 
> API since we can't change the API without breaking. Though I winder if we can 
> actually change this one:
> 
> ```
> uint64_t SBValue::GetNumChildren();
> ```
> 
> Since the return value isn't mangled into the function name?
> 
> The reason I mention the uint64_t is `lldb::SBValue` and 
> `lldb_private::ValueObject*` can represent _any_ object that can be expanded. 
> We could have a `lldb::SBValue` that represents all of memory in a process 
> where each object can represent an area in memory as a specific format and 
> size. So a 64 bit process _could_ have a `SBValue` with `UINT64_MAX` children 
> available if we wanted to have a `SBValue` that represented memory as 
> `uint8_t` objects.
> 
> So if we are going to change stuff around, I would vote to use `uint64_t` 
> instead of `uint32_t`

Changing the type of a return value if it changes the size/layout is ABI 
breaking. The mangled name wouldn't change but it may silently break something 
later without us realizing.


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


[Lldb-commits] [lldb] [lldb] Allow languages to filter breakpoints set by line (PR #83908)

2024-03-04 Thread via lldb-commits

jimingham wrote:

LGTM except you should have a little bit of doc describing what "interesting" 
means.  On the face of it, this seems a little silly.  Why would the compiler 
emit "uninteresting" line table entries?  Your example motivation the PR makes 
that clear, that or something like in the docs would help motivate this.


Also, are these 100% uninteresting line table entries?  At present, there's no 
way to get lldb to not filter them out, so they either really need to be 
totally uninteresting, or we need a setting to turn them back on again.

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

My main point was to unify it, but I have no problem with going for `uint64_t` 
instead. I'll update the patch.

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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread Mehdi Amini via lldb-commits

joker-eph wrote:

> One patch ThreadPool->DefaultThreadPool (people get a build error about 
> ThreadPool not being the name of anything, find this patch as the root cause, 
> and rename all their ThreadPool->DefaultThreadPool)

Gotcha, thanks for elaborating, somehow my brain was slow on a Monday.
Will look into this!

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


[Lldb-commits] [lld] [lldb] [llvm] [mlir] Rename ThreadPool->DefaultThreadPool and ThreadPoolInterface->ThreadPool (NFC) (PR #83702)

2024-03-04 Thread Fangrui Song via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb] Enable a test that was never enabled (PR #83925)

2024-03-04 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan created 
https://github.com/llvm/llvm-project/pull/83925

According to the git log (d9442afba1bd6), this test has never been 
enabled/disabled, it was checked in without being called anywhere. But it 
passes and it is useful, so this commit enables it.

>From 009fafe5034fcc569951d0fbcca83adb354b97c5 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Mon, 4 Mar 2024 15:17:00 -0800
Subject: [PATCH] [lldb] Enable a test that was never enabled

According to the git log (d9442afba1bd6), this test has never been
enabled/disabled, it was checked in without being called anywhere. But it passes
and it is useful, so this commit enables it.
---
 .../breakpoint/breakpoint_options/TestBreakpointOptions.py   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
index b2c9551eda6acb..129290909029a1 100644
--- 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
+++ 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
@@ -13,6 +13,7 @@ def test(self):
 """Test breakpoint command for different options."""
 self.build()
 self.breakpoint_options_test()
+self.breakpoint_options_language_test()
 
 def setUp(self):
 # Call super's setUp().

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


[Lldb-commits] [lldb] [lldb] Enable a test that was never enabled (PR #83925)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Felipe de Azevedo Piovezan (felipepiovezan)


Changes

According to the git log (d9442afba1bd6), this test has never been 
enabled/disabled, it was checked in without being called anywhere. But it 
passes and it is useful, so this commit enables it.

---
Full diff: https://github.com/llvm/llvm-project/pull/83925.diff


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
 (+1) 


``diff
diff --git 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
index b2c9551eda6acb..129290909029a1 100644
--- 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
+++ 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
@@ -13,6 +13,7 @@ def test(self):
 """Test breakpoint command for different options."""
 self.build()
 self.breakpoint_options_test()
+self.breakpoint_options_language_test()
 
 def setUp(self):
 # Call super's setUp().

``




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


[Lldb-commits] [lldb] [lldb] Enable a test that was never enabled (PR #83925)

2024-03-04 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

@JDevlieghere  I believe you were the last one to touch this test, so I'll let 
you approve this :D 

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


[Lldb-commits] [lldb] [lldb] Enable a test that was never enabled (PR #83925)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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


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


[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben updated 
https://github.com/llvm/llvm-project/pull/83861

>From 5cc9da6d222ff39f2939cdb725477e94f8fb24f8 Mon Sep 17 00:00:00 2001
From: Med Ismail Bennani 
Date: Mon, 4 Mar 2024 15:41:45 -0800
Subject: [PATCH] [lldb/crashlog] Fix breaking changes in textual report format

This patch should address some register parsing issue in the legacy
report format.

rdar://107210149
rdar://119998761

Signed-off-by: Med Ismail Bennani 
---
 lldb/examples/python/crashlog.py  | 11 ++--
 .../Crashlog/Inputs/altered_threadState.crash | 50 +++
 .../Python/Crashlog/altered_threadState.test  | 13 +
 3 files changed, 70 insertions(+), 4 deletions(-)
 create mode 100644 
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
 create mode 100644 
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.test

diff --git a/lldb/examples/python/crashlog.py b/lldb/examples/python/crashlog.py
index 9e4f94264037ae..c992348b24be17 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -849,10 +849,10 @@ def parse_errors(self, json_data):
 
 class TextCrashLogParser(CrashLogParser):
 parent_process_regex = re.compile(r"^Parent Process:\s*(.*)\[(\d+)\]")
-thread_state_regex = re.compile(r"^Thread \d+ crashed with")
+thread_state_regex = re.compile(r"^Thread (\d+ crashed with|State)")
 thread_instrs_regex = re.compile(r"^Thread \d+ instruction stream")
-thread_regex = re.compile(r"^Thread (\d+).*:")
-app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*:")
+thread_regex = re.compile(r"^Thread (\d+).*")
+app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*")
 
 class VersionRegex:
 version = r"\(.+\)|(?:arm|x86_)[0-9a-z]+"
@@ -1081,7 +1081,10 @@ def parse_normal(self, line):
 if thread_state_match:
 self.app_specific_backtrace = False
 thread_state_match = self.thread_regex.search(line)
-thread_idx = int(thread_state_match.group(1))
+if thread_state_match:
+thread_idx = int(thread_state_match.group(1))
+else:
+thread_idx = self.crashlog.crashed_thread_idx
 self.parse_mode = self.CrashLogParseMode.THREGS
 self.thread = self.crashlog.threads[thread_idx]
 return
diff --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
new file mode 100644
index 00..8fcbdd24b3cf38
--- /dev/null
+++ 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
@@ -0,0 +1,50 @@
+Process:   a.out [21606]
+Path:  /private/tmp/a.out
+Identifier:a.out
+Version:   0
+Code Type: X86-64 (Native)
+Parent Process:fish [3]
+User ID:   501
+
+Date/Time: 2020-11-11 14:47:34.600 -0800
+OS Version:macOS 11.0.1
+Report Version:12
+Bridge OS Version: redacted
+Anonymous UUID:DCEF35CB-68D5-F524-FF13-060901F52EA8
+
+
+Time Awake Since Boot: 40 seconds
+
+System Integrity Protection: enabled
+
+Crashed Thread:0  Dispatch queue: com.apple.main-thread
+
+Exception Type:EXC_BAD_ACCESS (SIGSEGV)
+Exception Codes:   KERN_INVALID_ADDRESS at 0x
+Exception Note:EXC_CORPSE_NOTIFY
+
+Termination Signal:Segmentation fault: 11
+Termination Reason:Namespace SIGNAL, Code 0xb
+Terminating Process:   exc handler [21606]
+
+Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
+0   a.out  @foo@ foo + 16 (test.c:3)
+1   a.out  @bar@
+2   a.out  @main@ main + 20 (test.c:8)
+3   libdyld.dylib  0x100 start + 1
+
+Thread State
+  rax: 0x  rbx: 0x  rcx: 0x7ffee42d81d0  
rdx: 0x7ffee42d8080
+  rdi: 0x0001  rsi: 0x7ffee42d8070  rbp: 0x7ffee42d8020  
rsp: 0x7ffee42d8020
+   r8: 0x   r9: 0x  r10: 0x  
r11: 0x
+  r12: 0x  r13: 0x  r14: 0x  
r15: 0x
+  rip: 0x00010b92af70  rfl: 0x00010202  cr2: 0x
+
+Logical CPU: 2
+Error Code:  0x0006 (no mapping for user data write)
+Trap Number: 14
+
+
+Binary Images:
+   0x1 -0x2 +a.out (0) <@UUID@> @EXEC@
+   0x0 - 0x ??? (*) 
<----> ???
diff --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.test 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.tes

[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread Jonas Devlieghere via lldb-commits

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

LGTM!

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


[Lldb-commits] [lldb] [lldb/crashlog] Fix breaking changes in textual report format (PR #83861)

2024-03-04 Thread Med Ismail Bennani via lldb-commits

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


[Lldb-commits] [lldb] 5000e4c - [lldb/crashlog] Fix breaking changes in textual report format (#83861)

2024-03-04 Thread via lldb-commits

Author: Med Ismail Bennani
Date: 2024-03-04T15:44:44-08:00
New Revision: 5000e4c2527ae53bf7c1a609f739a97cdc522bbe

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

LOG: [lldb/crashlog] Fix breaking changes in textual report format (#83861)

This patch should address some register parsing issue in the legacy
report format.

rdar://107210149

Signed-off-by: Med Ismail Bennani 

Added: 

lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.test

Modified: 
lldb/examples/python/crashlog.py

Removed: 




diff  --git a/lldb/examples/python/crashlog.py 
b/lldb/examples/python/crashlog.py
index 9e4f94264037ae..c992348b24be17 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -849,10 +849,10 @@ def parse_errors(self, json_data):
 
 class TextCrashLogParser(CrashLogParser):
 parent_process_regex = re.compile(r"^Parent Process:\s*(.*)\[(\d+)\]")
-thread_state_regex = re.compile(r"^Thread \d+ crashed with")
+thread_state_regex = re.compile(r"^Thread (\d+ crashed with|State)")
 thread_instrs_regex = re.compile(r"^Thread \d+ instruction stream")
-thread_regex = re.compile(r"^Thread (\d+).*:")
-app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*:")
+thread_regex = re.compile(r"^Thread (\d+).*")
+app_backtrace_regex = re.compile(r"^Application Specific Backtrace 
(\d+).*")
 
 class VersionRegex:
 version = r"\(.+\)|(?:arm|x86_)[0-9a-z]+"
@@ -1081,7 +1081,10 @@ def parse_normal(self, line):
 if thread_state_match:
 self.app_specific_backtrace = False
 thread_state_match = self.thread_regex.search(line)
-thread_idx = int(thread_state_match.group(1))
+if thread_state_match:
+thread_idx = int(thread_state_match.group(1))
+else:
+thread_idx = self.crashlog.crashed_thread_idx
 self.parse_mode = self.CrashLogParseMode.THREGS
 self.thread = self.crashlog.threads[thread_idx]
 return

diff  --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
new file mode 100644
index 00..8fcbdd24b3cf38
--- /dev/null
+++ 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/altered_threadState.crash
@@ -0,0 +1,50 @@
+Process:   a.out [21606]
+Path:  /private/tmp/a.out
+Identifier:a.out
+Version:   0
+Code Type: X86-64 (Native)
+Parent Process:fish [3]
+User ID:   501
+
+Date/Time: 2020-11-11 14:47:34.600 -0800
+OS Version:macOS 11.0.1
+Report Version:12
+Bridge OS Version: redacted
+Anonymous UUID:DCEF35CB-68D5-F524-FF13-060901F52EA8
+
+
+Time Awake Since Boot: 40 seconds
+
+System Integrity Protection: enabled
+
+Crashed Thread:0  Dispatch queue: com.apple.main-thread
+
+Exception Type:EXC_BAD_ACCESS (SIGSEGV)
+Exception Codes:   KERN_INVALID_ADDRESS at 0x
+Exception Note:EXC_CORPSE_NOTIFY
+
+Termination Signal:Segmentation fault: 11
+Termination Reason:Namespace SIGNAL, Code 0xb
+Terminating Process:   exc handler [21606]
+
+Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
+0   a.out  @foo@ foo + 16 (test.c:3)
+1   a.out  @bar@
+2   a.out  @main@ main + 20 (test.c:8)
+3   libdyld.dylib  0x100 start + 1
+
+Thread State
+  rax: 0x  rbx: 0x  rcx: 0x7ffee42d81d0  
rdx: 0x7ffee42d8080
+  rdi: 0x0001  rsi: 0x7ffee42d8070  rbp: 0x7ffee42d8020  
rsp: 0x7ffee42d8020
+   r8: 0x   r9: 0x  r10: 0x  
r11: 0x
+  r12: 0x  r13: 0x  r14: 0x  
r15: 0x
+  rip: 0x00010b92af70  rfl: 0x00010202  cr2: 0x
+
+Logical CPU: 2
+Error Code:  0x0006 (no mapping for user data write)
+Trap Number: 14
+
+
+Binary Images:
+   0x1 -0x2 +a.out (0) <@UUID@> @EXEC@
+   0x0 - 0x ??? (*) 
<----> ???

diff  --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.test 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/altered_threadState.test
new file mode 100644
index 00..5a946a38b

[Lldb-commits] [lldb] [lldb] Allow languages to filter breakpoints set by line (PR #83908)

2024-03-04 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

> Also, are these 100% uninteresting line table entries? At present, there's no 
> way to get lldb to not filter them out, so they either really need to be 
> totally uninteresting, or we need a setting to turn them back on again.

They should be 100% uninteresting, but I agree that it would be nice to have a 
mechanism allowing these to be re-enabled.
Do you think it is better to have a setting for this, or could we perhaps add 
the breakpoint but keep it disabled by default (is there precedent for this?) ?

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


[Lldb-commits] [lldb] 488ac3d - [lldb] Enable a test that was never enabled (#83925)

2024-03-04 Thread via lldb-commits

Author: Felipe de Azevedo Piovezan
Date: 2024-03-04T15:45:43-08:00
New Revision: 488ac3d5ef31237e38de6da627a619459e0ca19a

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

LOG: [lldb] Enable a test that was never enabled (#83925)

According to the git log (d9442afba1bd6), this test has never been
enabled/disabled, it was checked in without being called anywhere. But
it passes and it is useful, so this commit enables it.

Added: 


Modified: 

lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
index b2c9551eda6acb..129290909029a1 100644
--- 
a/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
+++ 
b/lldb/test/API/functionalities/breakpoint/breakpoint_options/TestBreakpointOptions.py
@@ -13,6 +13,7 @@ def test(self):
 """Test breakpoint command for 
diff erent options."""
 self.build()
 self.breakpoint_options_test()
+self.breakpoint_options_language_test()
 
 def setUp(self):
 # Call super's setUp().



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


[Lldb-commits] [lldb] [lldb] Enable a test that was never enabled (PR #83925)

2024-03-04 Thread Felipe de Azevedo Piovezan via lldb-commits

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


[Lldb-commits] [lldb] [lldb] Allow languages to filter breakpoints set by line (PR #83908)

2024-03-04 Thread via lldb-commits

jimingham wrote:

We don't do the latter anywhere.  This is really equivalent to the: 
target.breakpoints-use-platform-avoid-list setting, which is also about "stop 
at places most normal human beings don't want to stop".  In the extant setting 
it's about whole libraries, the new setting would be about adding breakpoints 
on artificial line table entries or something like that.

Jim
 

> On Mar 4, 2024, at 3:45 PM, Felipe de Azevedo Piovezan ***@***.***> wrote:
> 
> 
> Also, are these 100% uninteresting line table entries? At present, there's no 
> way to get lldb to not filter them out, so they either really need to be 
> totally uninteresting, or we need a setting to turn them back on again.
> 
> They should be 100% uninteresting, but I agree that it would be nice to have 
> a mechanism allowing these to be re-enabled.
> Do you think it is better to have a setting for this, or could we perhaps add 
> the breakpoint but keep it disabled by default (is there precedent for this?) 
> ?
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because your review was requested.
> 



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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/83501

>From 4aeccd664633af57f12bfb7d0edada78c09a951e Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Mon, 4 Mar 2024 16:07:44 -0800
Subject: [PATCH 1/2] Change the return type of
 ValueObject::CalculateNumChildren to uint64_t.

This is to enforce consistency across all APIs inside LLDB.
---
 lldb/include/lldb/Core/ValueObject.h| 2 +-
 lldb/include/lldb/Core/ValueObjectCast.h| 2 +-
 lldb/include/lldb/Core/ValueObjectChild.h   | 2 +-
 lldb/include/lldb/Core/ValueObjectConstResult.h | 2 +-
 lldb/include/lldb/Core/ValueObjectDynamicValue.h| 2 +-
 lldb/include/lldb/Core/ValueObjectMemory.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectRegister.h| 4 ++--
 lldb/include/lldb/Core/ValueObjectSyntheticFilter.h | 2 +-
 lldb/include/lldb/Core/ValueObjectVTable.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectVariable.h| 2 +-
 lldb/include/lldb/Target/StackFrameRecognizer.h | 2 +-
 lldb/source/Core/ValueObjectCast.cpp| 2 +-
 lldb/source/Core/ValueObjectChild.cpp   | 2 +-
 lldb/source/Core/ValueObjectConstResult.cpp | 2 +-
 lldb/source/Core/ValueObjectDynamicValue.cpp| 2 +-
 lldb/source/Core/ValueObjectMemory.cpp  | 2 +-
 lldb/source/Core/ValueObjectRegister.cpp| 4 ++--
 lldb/source/Core/ValueObjectSyntheticFilter.cpp | 2 +-
 lldb/source/Core/ValueObjectVTable.cpp  | 4 ++--
 lldb/source/Core/ValueObjectVariable.cpp| 2 +-
 20 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index 4c0b0b2dae6cd4..5f0b0265d87e8d 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -958,7 +958,7 @@ class ValueObject {
   int32_t synthetic_index);
 
   /// Should only be called by ValueObject::GetNumChildren().
-  virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+  virtual uint64_t CalculateNumChildren(uint64_t max = UINT32_MAX) = 0;
 
   void SetNumChildren(size_t num_children);
 
diff --git a/lldb/include/lldb/Core/ValueObjectCast.h 
b/lldb/include/lldb/Core/ValueObjectCast.h
index fe053c12d9c343..a758c31cfd5ae8 100644
--- a/lldb/include/lldb/Core/ValueObjectCast.h
+++ b/lldb/include/lldb/Core/ValueObjectCast.h
@@ -33,7 +33,7 @@ class ValueObjectCast : public ValueObject {
 
   std::optional GetByteSize() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectChild.h 
b/lldb/include/lldb/Core/ValueObjectChild.h
index 46b14e6840f0dc..5c8ebc524a4725 100644
--- a/lldb/include/lldb/Core/ValueObjectChild.h
+++ b/lldb/include/lldb/Core/ValueObjectChild.h
@@ -39,7 +39,7 @@ class ValueObjectChild : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectConstResult.h 
b/lldb/include/lldb/Core/ValueObjectConstResult.h
index d61df859bebce4..70785a0e149065 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResult.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResult.h
@@ -67,7 +67,7 @@ class ValueObjectConstResult : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectDynamicValue.h 
b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
index 2758b4e5bb564d..04726d4847c741 100644
--- a/lldb/include/lldb/Core/ValueObjectDynamicValue.h
+++ b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
@@ -43,7 +43,7 @@ class ValueObjectDynamicValue : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectMemory.h 
b/lldb/include/lldb/Core/ValueObjectMemory.h
index 3c01df388d2e6d..37df403257e91e 100644
--- a/lldb/include/lldb/Core/ValueObjectMemory.h
+++ b/lldb/include/lldb/Core/ValueObjectMemory.h
@@ -47,7 +47,7 @@ class ValueObjectMemory : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectRegister.h 
b/lldb/include/lldb/Core/ValueObjectRegister.h
index 2e47eee3d7f7

[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

https://github.com/clayborg commented:

Looking good. One question: do we want to switch to using a 
`std::optional` instead of using a `uint64_t` with a default value of 
UINT32_MAX? We should either use the optional or switch everything except for 
the public API over to use `UINT64_MAX`

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits


@@ -958,7 +958,7 @@ class ValueObject {
   int32_t synthetic_index);
 
   /// Should only be called by ValueObject::GetNumChildren().
-  virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+  virtual uint64_t CalculateNumChildren(uint64_t max = UINT32_MAX) = 0;

clayborg wrote:

As long as we are changing things, do we want to pass in a 
`std::optional max`? If not, then switch this to `UINT64_MAX`.

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/83501

>From 4aeccd664633af57f12bfb7d0edada78c09a951e Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Mon, 4 Mar 2024 16:07:44 -0800
Subject: [PATCH 1/3] Change the return type of
 ValueObject::CalculateNumChildren to uint64_t.

This is to enforce consistency across all APIs inside LLDB.
---
 lldb/include/lldb/Core/ValueObject.h| 2 +-
 lldb/include/lldb/Core/ValueObjectCast.h| 2 +-
 lldb/include/lldb/Core/ValueObjectChild.h   | 2 +-
 lldb/include/lldb/Core/ValueObjectConstResult.h | 2 +-
 lldb/include/lldb/Core/ValueObjectDynamicValue.h| 2 +-
 lldb/include/lldb/Core/ValueObjectMemory.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectRegister.h| 4 ++--
 lldb/include/lldb/Core/ValueObjectSyntheticFilter.h | 2 +-
 lldb/include/lldb/Core/ValueObjectVTable.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectVariable.h| 2 +-
 lldb/include/lldb/Target/StackFrameRecognizer.h | 2 +-
 lldb/source/Core/ValueObjectCast.cpp| 2 +-
 lldb/source/Core/ValueObjectChild.cpp   | 2 +-
 lldb/source/Core/ValueObjectConstResult.cpp | 2 +-
 lldb/source/Core/ValueObjectDynamicValue.cpp| 2 +-
 lldb/source/Core/ValueObjectMemory.cpp  | 2 +-
 lldb/source/Core/ValueObjectRegister.cpp| 4 ++--
 lldb/source/Core/ValueObjectSyntheticFilter.cpp | 2 +-
 lldb/source/Core/ValueObjectVTable.cpp  | 4 ++--
 lldb/source/Core/ValueObjectVariable.cpp| 2 +-
 20 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index 4c0b0b2dae6cd4..5f0b0265d87e8d 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -958,7 +958,7 @@ class ValueObject {
   int32_t synthetic_index);
 
   /// Should only be called by ValueObject::GetNumChildren().
-  virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+  virtual uint64_t CalculateNumChildren(uint64_t max = UINT32_MAX) = 0;
 
   void SetNumChildren(size_t num_children);
 
diff --git a/lldb/include/lldb/Core/ValueObjectCast.h 
b/lldb/include/lldb/Core/ValueObjectCast.h
index fe053c12d9c343..a758c31cfd5ae8 100644
--- a/lldb/include/lldb/Core/ValueObjectCast.h
+++ b/lldb/include/lldb/Core/ValueObjectCast.h
@@ -33,7 +33,7 @@ class ValueObjectCast : public ValueObject {
 
   std::optional GetByteSize() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectChild.h 
b/lldb/include/lldb/Core/ValueObjectChild.h
index 46b14e6840f0dc..5c8ebc524a4725 100644
--- a/lldb/include/lldb/Core/ValueObjectChild.h
+++ b/lldb/include/lldb/Core/ValueObjectChild.h
@@ -39,7 +39,7 @@ class ValueObjectChild : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectConstResult.h 
b/lldb/include/lldb/Core/ValueObjectConstResult.h
index d61df859bebce4..70785a0e149065 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResult.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResult.h
@@ -67,7 +67,7 @@ class ValueObjectConstResult : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectDynamicValue.h 
b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
index 2758b4e5bb564d..04726d4847c741 100644
--- a/lldb/include/lldb/Core/ValueObjectDynamicValue.h
+++ b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
@@ -43,7 +43,7 @@ class ValueObjectDynamicValue : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectMemory.h 
b/lldb/include/lldb/Core/ValueObjectMemory.h
index 3c01df388d2e6d..37df403257e91e 100644
--- a/lldb/include/lldb/Core/ValueObjectMemory.h
+++ b/lldb/include/lldb/Core/ValueObjectMemory.h
@@ -47,7 +47,7 @@ class ValueObjectMemory : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint64_t CalculateNumChildren(uint64_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectRegister.h 
b/lldb/include/lldb/Core/ValueObjectRegister.h
index 2e47eee3d7f7

[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

> Looking good. One question: do we want to switch to using a 
> `std::optional` instead of using a `uint64_t` with a default value 
> of UINT32_MAX? We should either use the optional or switch everything except 
> for the public API over to use `UINT64_MAX`

The entire point of this patch series is to prepare for a final patch that will 
change the return value to `llvm::Expected` :-)

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits


@@ -958,7 +958,7 @@ class ValueObject {
   int32_t synthetic_index);
 
   /// Should only be called by ValueObject::GetNumChildren().
-  virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+  virtual uint64_t CalculateNumChildren(uint64_t max = UINT32_MAX) = 0;

adrian-prantl wrote:

Oh that's separately a good change to make apart from the return value I 
mentioned below.

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


[Lldb-commits] [lldb] Don't require a UUID in a .dwp file. (PR #83935)

2024-03-04 Thread Greg Clayton via lldb-commits

https://github.com/clayborg created 
https://github.com/llvm/llvm-project/pull/83935

DWP files don't usually have a GNU build ID built into them. When searching for 
a .dwp file, don't require a UUID to be in the .dwp file. The debug info search 
information was checking for a UUID in the .dwp file when debug info search 
paths were being used. This is now fixed by not specifying the UUID in the 
ModuleSpec being used for the .dwp file search.

>From 5c3359ce45e065d52dbe57831fee0e07e50c37b8 Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Mon, 4 Mar 2024 17:23:35 -0800
Subject: [PATCH] Don't require a UUID in a .dwp file.

DWP files don't usually have a GNU build ID built into them. When searching for 
a .dwp file, don't require a UUID to be in the .dwp file. The debug info search 
information was checking for a UUID in the .dwp file when debug info search 
paths were being used. This is now fixed by not specifying the UUID in the 
ModuleSpec being used for the .dwp file search.
---
 .../Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp   |  1 -
 .../DWARF/x86/dwp-separate-debug-file.cpp  | 14 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 84ff4c2565a050..5f67658f86ea96 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -4377,7 +4377,6 @@ const std::shared_ptr 
&SymbolFileDWARF::GetDwpSymbolFile() {
 FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
 ModuleSpec module_spec;
 module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
-module_spec.GetUUID() = m_objfile_sp->GetUUID();
 for (const auto &symfile : symfiles.files()) {
   module_spec.GetSymbolFileSpec() =
   FileSpec(symfile.GetPath() + ".dwp", symfile.GetPathStyle());
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp 
b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
index 9a8149065b6e58..1d636ede41b56d 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
@@ -139,6 +139,20 @@
 // RUN:   -o "target variable a" \
 // RUN:   -b %t | FileCheck %s
 
+// Now move the .debug and .dwp file into another directory so that we can use
+// the target.debug-file-search-paths setting to search for the files.
+// RUN: mkdir -p %t-debug-info-dir
+// RUN: mv %t.dwp %t-debug-info-dir
+// RUN: mv %t.debug %t-debug-info-dir
+// RUN: %lldb \
+// RUN:   -O "log enable dwarf split" \
+// RUN:   -O "setting set target.debug-file-search-paths '%t-debug-info-dir'" \
+// RUN:   -o "target variable a" \
+// RUN:   -b %t | FileCheck %s
+// RUN:
+
+// Now move the .debug and .dwp file into another directory so that we can use
+// the target.debug-file-search-paths setting to search for the files.
 // CHECK: Searching for DWP using:
 // CHECK: Found DWP file:
 // CHECK: (A) a = (x = 47)

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


[Lldb-commits] [lldb] Don't require a UUID in a .dwp file. (PR #83935)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Greg Clayton (clayborg)


Changes

DWP files don't usually have a GNU build ID built into them. When searching for 
a .dwp file, don't require a UUID to be in the .dwp file. The debug info search 
information was checking for a UUID in the .dwp file when debug info search 
paths were being used. This is now fixed by not specifying the UUID in the 
ModuleSpec being used for the .dwp file search.

---
Full diff: https://github.com/llvm/llvm-project/pull/83935.diff


2 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (-1) 
- (modified) lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp 
(+14) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 84ff4c2565a050..5f67658f86ea96 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -4377,7 +4377,6 @@ const std::shared_ptr 
&SymbolFileDWARF::GetDwpSymbolFile() {
 FileSpecList search_paths = Target::GetDefaultDebugFileSearchPaths();
 ModuleSpec module_spec;
 module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
-module_spec.GetUUID() = m_objfile_sp->GetUUID();
 for (const auto &symfile : symfiles.files()) {
   module_spec.GetSymbolFileSpec() =
   FileSpec(symfile.GetPath() + ".dwp", symfile.GetPathStyle());
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp 
b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
index 9a8149065b6e58..1d636ede41b56d 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/dwp-separate-debug-file.cpp
@@ -139,6 +139,20 @@
 // RUN:   -o "target variable a" \
 // RUN:   -b %t | FileCheck %s
 
+// Now move the .debug and .dwp file into another directory so that we can use
+// the target.debug-file-search-paths setting to search for the files.
+// RUN: mkdir -p %t-debug-info-dir
+// RUN: mv %t.dwp %t-debug-info-dir
+// RUN: mv %t.debug %t-debug-info-dir
+// RUN: %lldb \
+// RUN:   -O "log enable dwarf split" \
+// RUN:   -O "setting set target.debug-file-search-paths '%t-debug-info-dir'" \
+// RUN:   -o "target variable a" \
+// RUN:   -b %t | FileCheck %s
+// RUN:
+
+// Now move the .debug and .dwp file into another directory so that we can use
+// the target.debug-file-search-paths setting to search for the files.
 // CHECK: Searching for DWP using:
 // CHECK: Found DWP file:
 // CHECK: (A) a = (x = 47)

``




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


[Lldb-commits] [lldb] [lldb] Log to system log instead of stderr from Host::SystemLog (PR #83366)

2024-03-04 Thread Jordan Rupprecht via lldb-commits

rupprecht wrote:

> @rupprecht @oontvoo How do you feel about the current approach? The other 
> alternative is to make this function a NOOP on all platforms but Darwin 
> (where I want to actively use it). It's not currently load bearing (except 
> the log, which is opt-in).

This approach LGTM. Potentially we will want calls to `syslog` to be different 
or configurable somehow, but we can cross that bridge when we get to it.

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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

clayborg wrote:

> > Looking good. One question: do we want to switch to using a 
> > `std::optional` instead of using a `uint64_t` with a default 
> > value of UINT32_MAX? We should either use the optional or switch everything 
> > except for the public API over to use `UINT64_MAX`
> 
> The entire point of this patch series is to prepare for a final patch that 
> will change the return value to `llvm::Expected` :-)

I was suggesting this for the input parameters only. But we can do this later. 


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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Greg Clayton via lldb-commits

https://github.com/clayborg requested changes to this pull request.

So the only thing left to here is to stop using `UINT32_MAX` and switch to 
using `UINT64_MAX` on internal APIs.

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


[Lldb-commits] [lldb] [lldb] Log to system log instead of stderr from Host::SystemLog (PR #83366)

2024-03-04 Thread Jordan Rupprecht via lldb-commits

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


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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

Folks I'm talking this all back. Changing the return type from a uint32_t to a 
uint64_t is an all-or-nothing affair, because the UINT32_MAX sentinel value is 
permeating a bunch of other APIs that I have not intention of changing right 
now. For example, `GetIndexOfChildWithName()`.
I'd like to propose to just unify to `int32_t` here, which is no regression (as 
evidenced by the SBAPI) and then as I start threading through error handling, 
we can separately talk about replacing the sentinel values with something else. 
Then switching to 64 bits is again relatively simple.

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


[Lldb-commits] [lldb] [lldb] Add ability to detect darwin host linker version to xfail tests (PR #83941)

2024-03-04 Thread Alex Langford via lldb-commits

https://github.com/bulbazord created 
https://github.com/llvm/llvm-project/pull/83941

When Apple released its new linker, it had a subtle bug that caused LLDB's TLS 
tests to fail. Unfortunately this means that TLS tests are not going to work on 
machines that have affected versions of the linker, so we should annotate the 
tests so that they only work when we are confident the linker has the required 
fix.

I'm not completely satisfied with this implementation. That being said, I 
believe that adding suport for linker versions in general is a non-trivial 
change that would require far more thought. There are a few challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but there's no 
way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many platforms 
have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We do this 
for Windows tests (where we use LLD no matter what).

Given that this is affecting the tests on our CI, I think this is an acceptable 
solution in the interim.

>From 480252e4b0eba8f631568b6da4e48f657c516576 Mon Sep 17 00:00:00 2001
From: Alex Langford 
Date: Mon, 4 Mar 2024 14:17:20 -0800
Subject: [PATCH] [lldb] Add ability to detect darwin host linker version to
 xfail tests

When Apple released its new linker, it had a subtle bug that caused
LLDB's TLS tests to fail. Unfortunately this means that TLS tests
are not going to work on machines that have affected versions of the
linker, so we should annotate the tests so that they only work when we
are confident the linker has the required fix.

I'm not completely satisfied with this implementation. That being said,
I believe that adding suport for linker versions in general is a
non-trivial change that would require far more thought. There are a few
challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but
  there's no way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many
  platforms have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We
  do this for Windows tests (where we use LLD no matter what).

Given that this is affecting the tests on our CI, I think this is an
acceptable solution in the interim.
---
 .../Python/lldbsuite/test/lldbplatformutil.py | 40 +++
 .../API/lang/c/tls_globals/TestTlsGlobals.py  |  1 +
 2 files changed, 41 insertions(+)

diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py 
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index c4d063d3cc77ef..acb1a801e7f638 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -3,6 +3,7 @@
 
 # System modules
 import itertools
+import json
 import re
 import subprocess
 import sys
@@ -16,6 +17,7 @@
 from . import lldbtest_config
 import lldbsuite.test.lldbplatform as lldbplatform
 from lldbsuite.test.builders import get_builder
+from lldbsuite.test.lldbutil import is_exe
 
 
 def check_first_register_readable(test_case):
@@ -333,3 +335,41 @@ def expectedCompiler(compilers):
 return True
 
 return False
+
+
+# This is a helper function to determine if a specific version of Xcode's 
linker
+# contains a TLS bug. We want to skip TLS tests if they contain this bug, but
+# adding a linker/linker_version conditions to a decorator is challenging due 
to
+# the number of ways linkers can enter the build process.
+def darwinLinkerHasTLSBug():
+"""Returns true iff a test is running on a darwin platform and the host 
linker is between versions 1000 and 1109."""
+darwin_platforms = lldbplatform.translate(lldbplatform.darwin_all)
+if getPlatform() not in darwin_platforms:
+return False
+
+linker_path = (
+subprocess.check_output(["xcrun", "--find", 
"ld"]).rstrip().decode("utf-8")
+)
+if not is_exe(linker_path):
+return False
+
+raw_linker_info = (
+subprocess.check_output([linker_path, "-version_details"])
+.rstrip()
+.decode("utf-8")
+)
+parsed_linker_info = json.loads(raw_linker_info)
+if "version" not in parsed_linker_info:
+return False
+
+raw_version = parsed_linker_info["version"]
+version = None
+try:
+version = int(raw_version)
+except:
+return False
+
+if version is None:
+return False
+
+return 1000 <= version and version <= 1109
diff --git a/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py 
b/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
index dfe29b451df0a6..526e49b68162f3 100644
--- a/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
+++ b/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
@@ -40,6 +4

[Lldb-commits] [lldb] [lldb] Add ability to detect darwin host linker version to xfail tests (PR #83941)

2024-03-04 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Alex Langford (bulbazord)


Changes

When Apple released its new linker, it had a subtle bug that caused LLDB's TLS 
tests to fail. Unfortunately this means that TLS tests are not going to work on 
machines that have affected versions of the linker, so we should annotate the 
tests so that they only work when we are confident the linker has the required 
fix.

I'm not completely satisfied with this implementation. That being said, I 
believe that adding suport for linker versions in general is a non-trivial 
change that would require far more thought. There are a few challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but there's no 
way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many platforms 
have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We do this 
for Windows tests (where we use LLD no matter what).

Given that this is affecting the tests on our CI, I think this is an acceptable 
solution in the interim.

---
Full diff: https://github.com/llvm/llvm-project/pull/83941.diff


2 Files Affected:

- (modified) lldb/packages/Python/lldbsuite/test/lldbplatformutil.py (+40) 
- (modified) lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py (+1) 


``diff
diff --git a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py 
b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
index c4d063d3cc77ef..acb1a801e7f638 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -3,6 +3,7 @@
 
 # System modules
 import itertools
+import json
 import re
 import subprocess
 import sys
@@ -16,6 +17,7 @@
 from . import lldbtest_config
 import lldbsuite.test.lldbplatform as lldbplatform
 from lldbsuite.test.builders import get_builder
+from lldbsuite.test.lldbutil import is_exe
 
 
 def check_first_register_readable(test_case):
@@ -333,3 +335,41 @@ def expectedCompiler(compilers):
 return True
 
 return False
+
+
+# This is a helper function to determine if a specific version of Xcode's 
linker
+# contains a TLS bug. We want to skip TLS tests if they contain this bug, but
+# adding a linker/linker_version conditions to a decorator is challenging due 
to
+# the number of ways linkers can enter the build process.
+def darwinLinkerHasTLSBug():
+"""Returns true iff a test is running on a darwin platform and the host 
linker is between versions 1000 and 1109."""
+darwin_platforms = lldbplatform.translate(lldbplatform.darwin_all)
+if getPlatform() not in darwin_platforms:
+return False
+
+linker_path = (
+subprocess.check_output(["xcrun", "--find", 
"ld"]).rstrip().decode("utf-8")
+)
+if not is_exe(linker_path):
+return False
+
+raw_linker_info = (
+subprocess.check_output([linker_path, "-version_details"])
+.rstrip()
+.decode("utf-8")
+)
+parsed_linker_info = json.loads(raw_linker_info)
+if "version" not in parsed_linker_info:
+return False
+
+raw_version = parsed_linker_info["version"]
+version = None
+try:
+version = int(raw_version)
+except:
+return False
+
+if version is None:
+return False
+
+return 1000 <= version and version <= 1109
diff --git a/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py 
b/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
index dfe29b451df0a6..526e49b68162f3 100644
--- a/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
+++ b/lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py
@@ -40,6 +40,7 @@ def setUp(self):
 @skipIfWindows
 @skipIf(oslist=["linux"], archs=["arm", "aarch64"])
 @skipIf(oslist=no_match([lldbplatformutil.getDarwinOSTriples(), "linux"]))
+@expectedFailureIf(lldbplatformutil.darwinLinkerHasTLSBug())
 def test(self):
 """Test thread-local storage."""
 self.build()

``




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


[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl updated 
https://github.com/llvm/llvm-project/pull/83501

>From 44e21455e042a674f12f872be24ca9b7bb7d6dec Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Thu, 29 Feb 2024 15:06:28 -0800
Subject: [PATCH 1/3] Change the return type of
 ValueObject::CalculateNumChildren to uint32_t.

In the end this value comes from TypeSystem::GetNumChildren which
returns a uint32_t, so ValueObject should be consistent with that.
---
 lldb/include/lldb/Core/ValueObject.h| 2 +-
 lldb/include/lldb/Core/ValueObjectCast.h| 2 +-
 lldb/include/lldb/Core/ValueObjectChild.h   | 2 +-
 lldb/include/lldb/Core/ValueObjectConstResult.h | 2 +-
 lldb/include/lldb/Core/ValueObjectDynamicValue.h| 2 +-
 lldb/include/lldb/Core/ValueObjectMemory.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectRegister.h| 4 ++--
 lldb/include/lldb/Core/ValueObjectSyntheticFilter.h | 2 +-
 lldb/include/lldb/Core/ValueObjectVTable.h  | 2 +-
 lldb/include/lldb/Core/ValueObjectVariable.h| 2 +-
 lldb/include/lldb/Target/StackFrameRecognizer.h | 2 +-
 lldb/source/Core/ValueObjectCast.cpp| 2 +-
 lldb/source/Core/ValueObjectChild.cpp   | 2 +-
 lldb/source/Core/ValueObjectConstResult.cpp | 2 +-
 lldb/source/Core/ValueObjectDynamicValue.cpp| 2 +-
 lldb/source/Core/ValueObjectMemory.cpp  | 2 +-
 lldb/source/Core/ValueObjectRegister.cpp| 4 ++--
 lldb/source/Core/ValueObjectSyntheticFilter.cpp | 2 +-
 lldb/source/Core/ValueObjectVTable.cpp  | 4 ++--
 lldb/source/Core/ValueObjectVariable.cpp| 2 +-
 20 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index 4c0b0b2dae6cd4..05dd64f5634fda 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -958,7 +958,7 @@ class ValueObject {
   int32_t synthetic_index);
 
   /// Should only be called by ValueObject::GetNumChildren().
-  virtual size_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
+  virtual uint32_t CalculateNumChildren(uint32_t max = UINT32_MAX) = 0;
 
   void SetNumChildren(size_t num_children);
 
diff --git a/lldb/include/lldb/Core/ValueObjectCast.h 
b/lldb/include/lldb/Core/ValueObjectCast.h
index fe053c12d9c343..51c647680d5227 100644
--- a/lldb/include/lldb/Core/ValueObjectCast.h
+++ b/lldb/include/lldb/Core/ValueObjectCast.h
@@ -33,7 +33,7 @@ class ValueObjectCast : public ValueObject {
 
   std::optional GetByteSize() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint32_t CalculateNumChildren(uint32_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectChild.h 
b/lldb/include/lldb/Core/ValueObjectChild.h
index 46b14e6840f0dc..47a13be08bb83b 100644
--- a/lldb/include/lldb/Core/ValueObjectChild.h
+++ b/lldb/include/lldb/Core/ValueObjectChild.h
@@ -39,7 +39,7 @@ class ValueObjectChild : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint32_t CalculateNumChildren(uint32_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectConstResult.h 
b/lldb/include/lldb/Core/ValueObjectConstResult.h
index d61df859bebce4..9f1246cf2a7874 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResult.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResult.h
@@ -67,7 +67,7 @@ class ValueObjectConstResult : public ValueObject {
 
   lldb::ValueType GetValueType() const override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint32_t CalculateNumChildren(uint32_t max) override;
 
   ConstString GetTypeName() override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectDynamicValue.h 
b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
index 2758b4e5bb564d..21a9b409fd5bd7 100644
--- a/lldb/include/lldb/Core/ValueObjectDynamicValue.h
+++ b/lldb/include/lldb/Core/ValueObjectDynamicValue.h
@@ -43,7 +43,7 @@ class ValueObjectDynamicValue : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint32_t CalculateNumChildren(uint32_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectMemory.h 
b/lldb/include/lldb/Core/ValueObjectMemory.h
index 3c01df388d2e6d..a74b325546b03c 100644
--- a/lldb/include/lldb/Core/ValueObjectMemory.h
+++ b/lldb/include/lldb/Core/ValueObjectMemory.h
@@ -47,7 +47,7 @@ class ValueObjectMemory : public ValueObject {
 
   ConstString GetDisplayTypeName() override;
 
-  size_t CalculateNumChildren(uint32_t max) override;
+  uint32_t CalculateNumChildren(uint32_t max) override;
 
   lldb::ValueType GetValueType() const override;
 
diff --git a/lldb/include/lldb/Core/ValueObjectReg

[Lldb-commits] [lldb] Change the return type of CalculateNumChildren to uint32_t. (PR #83501)

2024-03-04 Thread Adrian Prantl via lldb-commits

adrian-prantl wrote:

So I reverted back to the state where I convert everything to int32_t. This way 
I don't have to touch the UINT32_MAX sentinels in this patch, which should be 
done separately and very carefully.

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


[Lldb-commits] [lldb] Address mask sbprocess apis and new mask invalid const (PR #83663)

2024-03-04 Thread Jason Molenda via lldb-commits

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/83663

>From c993c7cc7c1669ca7d06e52f1a1ff8dbefe9ebc9 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Thu, 29 Feb 2024 17:02:42 -0800
Subject: [PATCH 1/3] [lldb] Add SBProcess methods for get/set/use address
 masks (#83095)

I'm reviving a patch from phabracator, https://reviews.llvm.org/D155905
which was approved but I wasn't thrilled with all the API I was adding
to SBProcess for all of the address mask types / memory regions. In this
update, I added enums to control type address mask type (code, data,
any) and address space specifiers (low, high, all) with defaulted
arguments for the most common case.

This patch is also fixing a bug in the "addressable bits to address
mask" calculation I added in AddressableBits::SetProcessMasks. If lldb
were told that 64 bits are valid for addressing, this method would
overflow the calculation and set an invalid mask. Added tests to check
this specific bug while I was adding these APIs.

rdar://123530562
---
 lldb/include/lldb/API/SBProcess.h | 114 ++
 lldb/include/lldb/Utility/AddressableBits.h   |   3 +
 lldb/include/lldb/lldb-defines.h  |   5 +
 lldb/include/lldb/lldb-enumerations.h |  16 +++
 lldb/source/API/SBProcess.cpp |  92 ++
 lldb/source/Target/Process.cpp|  10 +-
 lldb/source/Utility/AddressableBits.cpp   |  12 +-
 .../python_api/process/address-masks/Makefile |   3 +
 .../process/address-masks/TestAddressMasks.py |  74 
 .../python_api/process/address-masks/main.c   |   5 +
 10 files changed, 328 insertions(+), 6 deletions(-)
 create mode 100644 lldb/test/API/python_api/process/address-masks/Makefile
 create mode 100644 
lldb/test/API/python_api/process/address-masks/TestAddressMasks.py
 create mode 100644 lldb/test/API/python_api/process/address-masks/main.c

diff --git a/lldb/include/lldb/API/SBProcess.h 
b/lldb/include/lldb/API/SBProcess.h
index 4f92a41f3028a2..7da3335a7234b7 100644
--- a/lldb/include/lldb/API/SBProcess.h
+++ b/lldb/include/lldb/API/SBProcess.h
@@ -407,6 +407,120 @@ class LLDB_API SBProcess {
   /// the process isn't loaded from a core file.
   lldb::SBFileSpec GetCoreFile();
 
+  /// \{
+  /// \group Mask Address Methods
+  ///
+  /// \a type
+  /// All of the methods in this group take \a type argument
+  /// which is an AddressMaskType enum value.
+  /// There can be different address masks for code addresses and
+  /// data addresses, this argument can select which to get/set,
+  /// or to use when clearing non-addressable bits from an address.
+  /// This choice of mask can be important for example on AArch32
+  /// systems. Where instructions where instructions start on even addresses,
+  /// the 0th bit may be used to indicate that a function is thumb code.  On
+  /// such a target, the eAddressMaskTypeCode may clear the 0th bit from an
+  /// address to get the actual address Whereas eAddressMaskTypeData would not.
+  ///
+  /// \a addr_range
+  /// Many of the methods in this group take an \a addr_range argument
+  /// which is an AddressMaskRange enum value.
+  /// Needing to specify the address range is highly unusual, and the
+  /// default argument can be used in nearly all circumstances.
+  /// On some architectures (e.g., AArch64), it is possible to have
+  /// different page table setups for low and high memory, so different
+  /// numbers of bits relevant to addressing. It is possible to have
+  /// a program running in one half of memory and accessing the other
+  /// as heap, so we need to maintain two different sets of address masks
+  /// to debug this correctly.
+
+  /// Get the current address mask that will be applied to addresses
+  /// before reading from memory.
+  ///
+  /// \param[in] type
+  /// See \ref Mask Address Methods description of this argument.
+  /// eAddressMaskTypeAny is often a suitable value when code and
+  /// data masks are the same on a given target.
+  ///
+  /// \param[in] addr_range
+  /// See \ref Mask Address Methods description of this argument.
+  /// This will default to eAddressMaskRangeLow which is the
+  /// only set of masks used normally.
+  ///
+  /// \return
+  /// The address mask currently in use.  Bits which are not used
+  /// for addressing will be set to 1 in the mask.
+  lldb::addr_t GetAddressMask(
+  lldb::AddressMaskType type,
+  lldb::AddressMaskRange addr_range = lldb::eAddressMaskRangeLow);
+
+  /// Set the current address mask that can be applied to addresses
+  /// before reading from memory.
+  ///
+  /// \param[in] type
+  /// See \ref Mask Address Methods description of this argument.
+  /// eAddressMaskTypeAll is often a suitable value when the
+  /// same mask is being set for both code and data.
+  ///
+  /// \param[in] mask
+  /// The address mask to set.  Bits which are not used for addressing
+  ///