Re: [Lldb-commits] [PATCH] D114288: [NFC] Refactor symbol table parsing.

2021-12-02 Thread Omair Javaid via lldb-commits 
On Thu, 2 Dec 2021 at 01:37, Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:

> clayborg added a comment.
>
> In D114288#3163808 , @omjavaid
> wrote:
>
> > Hi @clayborg
> > This breaks LLDB Arm/Linux buildbot.
> https://lab.llvm.org/buildbot/#/builders/17/builds/14035
>
> I will check this out on linux. Any reason why I did not get a message to
> my email that this was failing?
>
I think there was some false negative before this issue so a failure email
wasnt triggered for this one.

>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D114288/new/
>
> https://reviews.llvm.org/D114288
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D114861: Don't consider frames with different PCs as a loop

2021-12-02 Thread David Spickett via Phabricator via lldb-commits 
DavidSpickett added a comment.

Looking at `GetOneMoreFrame` I agree the logic matches up but don't understand 
the logic enough overall to approve. I'll leave that to others.




Comment at: lldb/source/Target/RegisterContextUnwind.cpp:697
+  // theory we can have arbitrary number of frames with the same CFA, but more
+  // then 2 is very very unlikely).
 

specail -> special
hanlders -> handlers
compiance -> compliance
more then 2 -> more than 2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114861

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

[Lldb-commits] [PATCH] D114923: [lldb/plugins] Add arm64(e) support to ScriptedProcess

2021-12-02 Thread David Spickett via Phabricator via lldb-commits 
DavidSpickett added a reviewer: DavidSpickett.
DavidSpickett added inline comments.



Comment at: lldb/examples/python/scripted_process/scripted_process.py:357
+{'name': 'pc',   'bitsize': 64, 'offset': 256, 
'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 32, 'dwarf': 32, 
'generic': 'pc', 'alt-name': 'pc', },
+{'name': 'cpsr', 'bitsize': 32, 'offset': 264, 
'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 33, 'dwarf': 33, },
+]

You can drop the trailing comma `, },` inside the `}` on each entry.



Comment at: lldb/examples/python/scripted_process/scripted_process.py:359
+]
 return self.register_info
 

Is it worth putting an `else: raise Unknown architecture ` here? I assume 
the tests would fail later anyway and you're running this for Apple platforms 
that are x86/arm64 only.

Would this ever be run against Arm 32 bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114923

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

[Lldb-commits] [PATCH] D114967: [lldb] [Process/elf-core] Disable for FreeBSD vmcores

2021-12-02 Thread Michał Górny via Phabricator via lldb-commits 
mgorny created this revision.
mgorny added reviewers: labath, krytarowski, emaste.
Herald added a subscriber: arichardson.
mgorny requested review of this revision.

Recognize FreeBSD vmcores (kernel core dumps) through OS ABI = 0xFF
+ ELF version = 0, and do not process them via the elf-core plugin.
While these files use ELF as a container format, they contain raw memory
dump rather than proper VM segments and therefore are not usable
to the elf-core plugin.


https://reviews.llvm.org/D114967

Files:
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp


Index: lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -64,6 +64,10 @@
   DataExtractor data(data_sp, lldb::eByteOrderLittle, 4);
   lldb::offset_t data_offset = 0;
   if (elf_header.Parse(data, &data_offset)) {
+// Check whether we're dealing with a FreeBSD vmcore that needs
+// to be handled via FreeBSDKernel plugin instead.
+if (elf_header.e_ident[7] == 0xFF && elf_header.e_version == 0)
+  return process_sp;
 if (elf_header.e_type == llvm::ELF::ET_CORE)
   process_sp = std::make_shared(target_sp, listener_sp,
 *crash_file);


Index: lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -64,6 +64,10 @@
   DataExtractor data(data_sp, lldb::eByteOrderLittle, 4);
   lldb::offset_t data_offset = 0;
   if (elf_header.Parse(data, &data_offset)) {
+// Check whether we're dealing with a FreeBSD vmcore that needs
+// to be handled via FreeBSDKernel plugin instead.
+if (elf_header.e_ident[7] == 0xFF && elf_header.e_version == 0)
+  return process_sp;
 if (elf_header.e_type == llvm::ELF::ET_CORE)
   process_sp = std::make_shared(target_sp, listener_sp,
 *crash_file);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] c248601 - [lldb] Skip two lldb tests on Windows because they are flaky

2021-12-02 Thread Stella Stamenova via lldb-commits 

Author: Stella Stamenova
Date: 2021-12-02T09:53:28-08:00
New Revision: c24860118a7e4fe0611a9463498181a4a01b9459

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

LOG: [lldb] Skip two lldb tests on Windows because they are flaky

These tests work fine with VS2017, but become more flaky with VS2019 and the 
buildbot is about to get upgraded.

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

Added: 


Modified: 

lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
 
b/lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
index 95499883aa7a2..697124003048c 100644
--- 
a/lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
+++ 
b/lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
@@ -20,6 +20,7 @@ class ThreadSpecificBreakPlusConditionTestCase(TestBase):
 # hits break in another thread in testrun
 @add_test_categories(['pyapi'])
 @expectedFlakeyNetBSD
+@skipIfWindows # This test is flaky on Windows
 def test_python(self):
 """Test that we obey thread conditioned breakpoints."""
 self.build()

diff  --git a/lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py 
b/lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
index 4fdde97dba084..9467adb6cffe3 100644
--- a/lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
+++ b/lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
@@ -89,6 +89,7 @@ def test_lldb_iter_breakpoint(self):
 self.assertEqual(yours[i], mine[i],
 "ID of yours[{0}] and mine[{0}] matches".format(i))
 
+@skipIfWindows # This test is flaky on Windows
 def test_lldb_iter_frame(self):
 """Test iterator works correctly for SBProcess->SBThread->SBFrame."""
 self.build()



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

[Lldb-commits] [PATCH] D114907: [lldb] Skip two lldb tests on Windows because they are flaky

2021-12-02 Thread Stella Stamenova via Phabricator via lldb-commits 
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc24860118a7e: [lldb] Skip two lldb tests on Windows because 
they are flaky (authored by stella.stamenova).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114907

Files:
  
lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
  lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py


Index: lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
===
--- lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
+++ lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
@@ -89,6 +89,7 @@
 self.assertEqual(yours[i], mine[i],
 "ID of yours[{0}] and mine[{0}] matches".format(i))
 
+@skipIfWindows # This test is flaky on Windows
 def test_lldb_iter_frame(self):
 """Test iterator works correctly for SBProcess->SBThread->SBFrame."""
 self.build()
Index: 
lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
===
--- 
lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
+++ 
lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
@@ -20,6 +20,7 @@
 # hits break in another thread in testrun
 @add_test_categories(['pyapi'])
 @expectedFlakeyNetBSD
+@skipIfWindows # This test is flaky on Windows
 def test_python(self):
 """Test that we obey thread conditioned breakpoints."""
 self.build()


Index: lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
===
--- lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
+++ lldb/test/API/python_api/lldbutil/iter/TestLLDBIterator.py
@@ -89,6 +89,7 @@
 self.assertEqual(yours[i], mine[i],
 "ID of yours[{0}] and mine[{0}] matches".format(i))
 
+@skipIfWindows # This test is flaky on Windows
 def test_lldb_iter_frame(self):
 """Test iterator works correctly for SBProcess->SBThread->SBFrame."""
 self.build()
Index: lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
===
--- lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
+++ lldb/test/API/functionalities/thread/thread_specific_break_plus_condition/TestThreadSpecificBpPlusCondition.py
@@ -20,6 +20,7 @@
 # hits break in another thread in testrun
 @add_test_categories(['pyapi'])
 @expectedFlakeyNetBSD
+@skipIfWindows # This test is flaky on Windows
 def test_python(self):
 """Test that we obey thread conditioned breakpoints."""
 self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Lawrence D'Anna via Phabricator via lldb-commits 
lawrence_danna created this revision.
lawrence_danna added reviewers: labath, jingham, JDevlieghere.
lawrence_danna requested review of this revision.
Herald added a project: LLDB.

Some pythons are configured to set platlib somewhere outside of their
sys.prefix.   It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114973

Files:
  lldb/bindings/python/get-python-config.py


Index: lldb/bindings/python/get-python-config.py
===
--- lldb/bindings/python/get-python-config.py
+++ lldb/bindings/python/get-python-config.py
@@ -30,7 +30,17 @@
 # lldb's python lib will be put in the correct place for python to 
find it.
 # If not, you'll have to use lldb -P or lldb 
-print-script-interpreter-info
 # to figure out where it is.
-print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+try:
+print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+except ValueError:
+# Try to fall back to something reasonable if sysconfig's platlib
+# is outside of sys.prefix
+if os.name == 'posix':
+print('lib/python%d.%d/site-packages' % sys.version_info[:2])
+elif os.name == 'nt':
+print('Lib\\site-packages')
+else:
+raise
 elif args.variable_name == "LLDB_PYTHON_EXE_RELATIVE_PATH":
 tried = list()
 exe = sys.executable


Index: lldb/bindings/python/get-python-config.py
===
--- lldb/bindings/python/get-python-config.py
+++ lldb/bindings/python/get-python-config.py
@@ -30,7 +30,17 @@
 # lldb's python lib will be put in the correct place for python to find it.
 # If not, you'll have to use lldb -P or lldb -print-script-interpreter-info
 # to figure out where it is.
-print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+try:
+print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+except ValueError:
+# Try to fall back to something reasonable if sysconfig's platlib
+# is outside of sys.prefix
+if os.name == 'posix':
+print('lib/python%d.%d/site-packages' % sys.version_info[:2])
+elif os.name == 'nt':
+print('Lib\\site-packages')
+else:
+raise
 elif args.variable_name == "LLDB_PYTHON_EXE_RELATIVE_PATH":
 tried = list()
 exe = sys.executable
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D114923: [lldb/plugins] Add arm64(e) support to ScriptedProcess

2021-12-02 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib updated this revision to Diff 391389.
mib edited the summary of this revision.
mib added a comment.

Address @DavidSpickett feedbacks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114923

Files:
  lldb/examples/python/scripted_process/scripted_process.py
  lldb/source/Plugins/Process/scripted/ScriptedThread.cpp
  lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py

Index: lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
===
--- lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
+++ lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
@@ -103,7 +103,6 @@
 
 @skipUnlessDarwin
 @skipIfOutOfTreeDebugserver
-@skipIf(archs=no_match(['x86_64']))
 def test_launch_scripted_process_stack_frames(self):
 """Test that we can launch an lldb scripted process from the command
 line, check its process ID and read string from memory."""
Index: lldb/source/Plugins/Process/scripted/ScriptedThread.cpp
===
--- lldb/source/Plugins/Process/scripted/ScriptedThread.cpp
+++ lldb/source/Plugins/Process/scripted/ScriptedThread.cpp
@@ -198,13 +198,29 @@
 
   if (!m_register_info_sp) {
 StructuredData::DictionarySP reg_info = GetInterface()->GetRegisterInfo();
+
+Status error;
 if (!reg_info)
-  return nullptr;
+  return GetInterface()
+  ->ErrorWithMessage>(
+  LLVM_PRETTY_FUNCTION,
+  "Failed to get scripted thread registers info.", error,
+  LIBLLDB_LOG_THREAD);
 
 m_register_info_sp = std::make_shared(
 *reg_info, m_scripted_process.GetTarget().GetArchitecture());
-assert(m_register_info_sp->GetNumRegisters() > 0);
-assert(m_register_info_sp->GetNumRegisterSets() > 0);
+
+if (!m_register_info_sp->GetNumRegisters())
+  return GetInterface()
+  ->ErrorWithMessage>(
+  LLVM_PRETTY_FUNCTION, "Invalid number of register.", error,
+  LIBLLDB_LOG_THREAD);
+
+if (!m_register_info_sp->GetNumRegisterSets())
+  return GetInterface()
+  ->ErrorWithMessage>(
+  LLVM_PRETTY_FUNCTION, "Invalid number of register set.", error,
+  LIBLLDB_LOG_THREAD);
   }
 
   return m_register_info_sp;
Index: lldb/examples/python/scripted_process/scripted_process.py
===
--- lldb/examples/python/scripted_process/scripted_process.py
+++ lldb/examples/python/scripted_process/scripted_process.py
@@ -298,14 +298,14 @@
 self.register_info['registers'] = [
 {'name': 'rax', 'bitsize': 64, 'offset': 0, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 0, 'dwarf': 0},
 {'name': 'rbx', 'bitsize': 64, 'offset': 8, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 3, 'dwarf': 3},
-{'name': 'rcx', 'bitsize': 64, 'offset': 16, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 2, 'dwarf': 2, 'generic': 'arg4', 'alt-name': 'arg4', },
-{'name': 'rdx', 'bitsize': 64, 'offset': 24, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 1, 'dwarf': 1, 'generic': 'arg3', 'alt-name': 'arg3', },
-{'name': 'rdi', 'bitsize': 64, 'offset': 32, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 5, 'dwarf': 5, 'generic': 'arg1', 'alt-name': 'arg1', },
-{'name': 'rsi', 'bitsize': 64, 'offset': 40, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 4, 'dwarf': 4, 'generic': 'arg2', 'alt-name': 'arg2', },
-{'name': 'rbp', 'bitsize': 64, 'offset': 48, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 6, 'dwarf': 6, 'generic': 'fp', 'alt-name': 'fp', },
-{'name': 'rsp', 'bitsize': 64, 'offset': 56, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 7, 'dwarf': 7, 'generic': 'sp', 'alt-name': 'sp', },
-{'name': 'r8', 'bitsize': 64, 'offset': 64, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 8, 'dwarf': 8, 'generic': 'arg5', 'alt-name': 'arg5', },
-{'name': 'r9', 'bitsize': 64, 'offset': 72, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 9, 'dwarf': 9, 'generic': 'arg6', 'alt-name': 'arg6', },
+{'name': 'rcx', 'bitsize': 64, 'offset': 16, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 2, 'dwarf': 2, 'generic': 'arg4', 'alt-name': 'arg4'},
+{'name': 'rdx', 'bitsize': 64, 'offset': 24, 'encoding': 'uint', 'format': 'hex', 'set': 0, 'gcc': 1, 'dwarf': 1, 'generic': 'arg3', 'alt-name': 'arg3'},
+{'name': 'rdi', 'bitsize': 64, 'offset': 32, 'encoding': 'uint', 'format': 'hex', 'set': 0, '

[Lldb-commits] [PATCH] D114923: [lldb/plugins] Add arm64(e) support to ScriptedProcess

2021-12-02 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib marked 2 inline comments as done.
mib added inline comments.



Comment at: lldb/examples/python/scripted_process/scripted_process.py:359
+]
 return self.register_info
 

DavidSpickett wrote:
> Is it worth putting an `else: raise Unknown architecture ` here? I 
> assume the tests would fail later anyway and you're running this for Apple 
> platforms that are x86/arm64 only.
> 
> Would this ever be run against Arm 32 bit?
Hi David,

Thanks for looking at this.

I didn't put the else branch because the C++ ScriptedThread caller would assert 
if the returned dictionary didn't have any entry.
After some considerations, it makes more sense to raise an error on the Python 
side and log the error in lldb.

Regarding arm32, we have no plans on supporting this architecture, but I think 
it should be quite straightforward to add.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114923

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

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114973

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

[Lldb-commits] [PATCH] D113930: [LLDB][NativePDB] Fix function decl creation for class methods

2021-12-02 Thread Zequan Wu via Phabricator via lldb-commits 
zequanwu updated this revision to Diff 391454.
zequanwu added a comment.

Add test with `lldb-test symbols --dump-ast` though it printed the methods 
twice. It is considered a separate bug that could be fixed later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113930

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
  lldb/test/Shell/SymbolFile/NativePDB/find-functions.cpp

Index: lldb/test/Shell/SymbolFile/NativePDB/find-functions.cpp
===
--- lldb/test/Shell/SymbolFile/NativePDB/find-functions.cpp
+++ lldb/test/Shell/SymbolFile/NativePDB/find-functions.cpp
@@ -1,7 +1,7 @@
 // clang-format off
 // REQUIRES: lld, x86
 
-// RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -c /Fo%t.obj -- %s
+// RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -c /GR- /Fo%t.obj -- %s
 // RUN: lld-link -debug:full -nodefaultlib -entry:main %t.obj -out:%t.exe -pdb:%t.pdb
 
 // RUN: lldb-test symbols --find=function --name=main --function-flags=full %t.exe \
@@ -13,6 +13,46 @@
 // RUN: lldb-test symbols --find=function --name=varargs_fn --function-flags=full %t.exe \
 // RUN: | FileCheck %s --check-prefix=FIND-VAR
 
+// RUN: lldb-test symbols --find=function --name=Struct::simple_method --function-flags=full %t.exe \
+// RUN: | FileCheck %s --check-prefix=FIND-SIMPLE
+
+// RUN: lldb-test symbols --find=function --name=Struct::virtual_method --function-flags=full %t.exe \
+// RUN: | FileCheck %s --check-prefix=FIND-VIRTUAL
+
+// RUN: lldb-test symbols --find=function --name=Struct::static_method --function-flags=full %t.exe \
+// RUN: | FileCheck %s --check-prefix=FIND-STATIC-METHOD
+
+// RUN: lldb-test symbols --find=function --name=Struct::overloaded_method --function-flags=full %t.exe \
+// RUN: | FileCheck %s --check-prefix=FIND-OVERLOAD
+
+struct Struct {
+  int simple_method() {
+return 1;
+  }
+
+  virtual int virtual_method() {
+return 2;
+  }
+
+  static int static_method() {
+return 3;
+  }
+
+  int overloaded_method() {
+return 4 + overloaded_method('a') + overloaded_method('a', 1);
+  }
+protected:
+  virtual int overloaded_method(char c) {
+return 5;
+  }
+private:
+  static int overloaded_method(char c, int i, ...) {
+return 6;
+  }
+};
+
+Struct s;
+
 static int static_fn() {
   return 42;
 }
@@ -22,7 +62,8 @@
 }
 
 int main(int argc, char **argv) {
-  return static_fn() + varargs_fn(argc, argc);
+  return static_fn() + varargs_fn(argc, argc) + s.simple_method() +
+  Struct::static_method() + s.virtual_method() + s.overloaded_method();
 }
 
 // FIND-MAIN:  Function: id = {{.*}}, name = "main"
@@ -33,3 +74,17 @@
 
 // FIND-VAR:  Function: id = {{.*}}, name = "{{.*}}varargs_fn{{.*}}"
 // FIND-VAR-NEXT: FuncType: id = {{.*}}, compiler_type = "int (int, int, ...)"
+
+// FIND-SIMPLE:  Function: id = {{.*}}, name = "{{.*}}Struct::simple_method{{.*}}"
+// FIND-SIMPLE-NEXT: FuncType: id = {{.*}}, compiler_type = "int (void)"
+
+// FIND-VIRTUAL:  Function: id = {{.*}}, name = "{{.*}}Struct::virtual_method{{.*}}"
+// FIND-VIRTUAL-NEXT: FuncType: id = {{.*}}, compiler_type = "int (void)"
+
+// FIND-STATIC-METHOD:  Function: id = {{.*}}, name = "{{.*}}Struct::static_method{{.*}}"
+// FIND-STATIC-METHOD-NEXT: FuncType: id = {{.*}}, compiler_type = "int (void)"
+
+// FIND-OVERLOAD: Function: id = {{.*}}, name = "{{.*}}Struct::overloaded_method{{.*}}"
+// FIND-OVERLOAD: FuncType: id = {{.*}}, compiler_type = "int (void)"
+// FIND-OVERLOAD: FuncType: id = {{.*}}, compiler_type = "int (char)"
+// FIND-OVERLOAD: FuncType: id = {{.*}}, compiler_type = "int (char, int, ...)"
Index: lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
===
--- lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
+++ lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
@@ -4,7 +4,9 @@
 // RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -GR- -c /Fo%t.obj -- %s
 // RUN: lld-link -debug:full -nodefaultlib -entry:main %t.obj -out:%t.exe -pdb:%t.pdb
 // RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -s \
-// RUN: %p/Inputs/ast-methods.lldbinit 2>&1 | FileCheck %s
+// RUN: %p/Inputs/ast-methods.lldbinit 2>&1 | FileCheck %s --check-prefix=AST
+
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb-test symbols --dump-ast %t.exe | FileCheck %s --check-prefix=SYMBOL
 
 struct Struct {
   void simple_method() {}
@@ -21,17 +23,42 @@
 Struct s;
 
 int main(int argc, char **argv) {
+  s.simple_method();
+  s.static_method();
+  s.virtual_method();
+  s.overloaded_method();
+  s.overloaded_method('a');
+  s.overloaded_method('a', 1);
   return 0;
 }
 
-// CHECK: TranslationUnitDecl
-// CHECK: |-CXXRecordDecl {{.*}} struct Struct definition
-// CHECK: | |-CXXMethodDecl {{.*}} simple_method 'void (){{.*}

[Lldb-commits] [PATCH] D115001: Simplify logic to identify dyld_sim in Simulator debugging on macos

2021-12-02 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda created this revision.
jasonmolenda added a reviewer: jingham.
jasonmolenda added a project: LLDB.
Herald added a subscriber: kristof.beyls.
jasonmolenda requested review of this revision.

The DynamicLoader plugin for macOS needs to identify which binary is the 
dynamic loader (dyld, aka ld.so) so it can set a breakpoint to be notified 
about newly added binaries.  When debugging a simulator process (iOS process 
running on a mac, etc), there is both a "dyld" and a "dyld_sim" binary in the 
process, which both have the same filetype of dynamic loader, but we need to 
ignore dyld_sim.

The DynamicLoader previously was implementing this by checking if the inferior 
system is Intel, and if so, if the possibly-dyld binary was actually an 
iOS/watchOS/tvOS/etc binary.  If so, then this is dyld_sim, and we would skip 
it.

This has the obvious shortcoming on an Apple Silicon system; now we've got an 
arm64 system running a possibly-dyld with OS type iOS.  The inferior system may 
be iOS.

I took advantage of the fact that we track the simulator in the triple as the 
Environment.  If the environment is simulator, then we only register the 
possibly-dyld if its OS is macOS.

I also removed an old bit of code to handle old (before 2016) debugserver 
responses.  This code block is only relevant on macOS native systems, so we 
don't need to worry about debugging an old iOS etc device that might be older 
than this, running an old debugserver.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115001

Files:
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp


Index: lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
===
--- lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -540,35 +540,18 @@
   const size_t image_infos_size = image_infos.size();
   for (size_t i = 0; i < image_infos_size; i++) {
 if (image_infos[i].header.filetype == llvm::MachO::MH_DYLINKER) {
-  // In a "simulator" process (an x86 process that is 
-  // ios/tvos/watchos/bridgeos) we will have two dyld modules -- 
+  // In a "simulator" process we will have two dyld modules -- 
   // a "dyld" that we want to keep track of, and a "dyld_sim" which 
-  // we don't need to keep track of here. If the target is an x86 
-  // system and the OS of the dyld binary is ios/tvos/watchos/bridgeos, 
-  // then we are looking at dyld_sym.
-
-  // debugserver has only recently (late 2016) started sending up the os
-  // type for each binary it sees -- so if we don't have an os type, use a
-  // filename check as our next best guess.
-  if (image_infos[i].os_type == llvm::Triple::OSType::UnknownOS) {
-if (image_infos[i].file_spec.GetFilename() != g_dyld_sim_filename) {
-  dyld_idx = i;
-}
-  } else if (target_arch.GetTriple().getArch() == llvm::Triple::x86 ||
- target_arch.GetTriple().getArch() == llvm::Triple::x86_64) {
-if (image_infos[i].os_type != llvm::Triple::OSType::IOS &&
-image_infos[i].os_type != llvm::Triple::TvOS &&
-image_infos[i].os_type != llvm::Triple::WatchOS) {
-// NEED_BRIDGEOS_TRIPLE image_infos[i].os_type != 
llvm::Triple::BridgeOS) {
-  dyld_idx = i;
-}
+  // we don't need to keep track of here.  dyld_sim will have a non-macosx
+  // OS.
+  if (target_arch.GetTriple().getEnvironment() == llvm::Triple::Simulator 
&&
+  image_infos[i].os_type != llvm::Triple::OSType::MacOSX) {
+continue;
   }
-  else {
-// catch-all for any other environment -- trust that dyld is actually
-// dyld
-dyld_idx = i;
-  }
-} else if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
+
+  dyld_idx = i;
+} 
+if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
   exe_idx = i;
 }
   }


Index: lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
===
--- lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -540,35 +540,18 @@
   const size_t image_infos_size = image_infos.size();
   for (size_t i = 0; i < image_infos_size; i++) {
 if (image_infos[i].header.filetype == llvm::MachO::MH_DYLINKER) {
-  // In a "simulator" process (an x86 process that is 
-  // ios/tvos/watchos/bridgeos) we will have two dyld modules -- 
+  // In a "simulator" process we will have two dyld modules -- 
   // a "dyld" that we want to keep track of, and a "dyld_sim" which 
-  // we don't need to keep track of here. If the target is an x86 
-  // system and the OS of the dyld binary is ios/tvos/watchos/bridgeos, 
-

[Lldb-commits] [lldb] 266a66c - Include extra input contents on this test so we can see why lldb-arm-ubuntu buildbot is failing.

2021-12-02 Thread Greg Clayton via lldb-commits 

Author: Greg Clayton
Date: 2021-12-02T15:47:15-08:00
New Revision: 266a66c915cbbc36b1a3887963eb97f32306c7e4

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

LOG: Include extra input contents on this test so we can see why 
lldb-arm-ubuntu buildbot is failing.

Only lldb-arm-ubuntu is failing after https://reviews.llvm.org/D114288 and 
there isn't enough input context to see why this is failing. It works on x86_64 
linux just fine.

Added: 


Modified: 
lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test

Removed: 




diff  --git 
a/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test 
b/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
index 9507c5d6d17fc..a9650614674ea 100644
--- a/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
+++ b/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
@@ -59,7 +59,7 @@
 # from within the .dynsym section (multiplyByThree) and one from
 # the .symtab section embedded in the .gnu_debugdata section (multiplyByFour).
 
-# RUN: %lldb -b -o 'b multiplyByThree' -o 'b multiplyByFour' -o 'run' -o 
'continue' -o 'breakpoint list -v' %t.binary | FileCheck %s
+# RUN: %lldb -b -o 'b multiplyByThree' -o 'b multiplyByFour' -o 'run' -o 
'continue' -o 'breakpoint list -v' %t.binary | FileCheck %s 
--dump-input-context 20
 
 # CHECK: (lldb) b multiplyByThree
 # CHECK-NEXT: Breakpoint 1: where = 
minidebuginfo-set-and-hit-breakpoint.test.tmp.binary`multiplyByThree, address = 
0x{{.*}}



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

[Lldb-commits] [PATCH] D114288: [NFC] Refactor symbol table parsing.

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

In D114288#3165212 , @clayborg wrote:

> In D114288#3163808 , @omjavaid 
> wrote:
>
>> Hi @clayborg 
>> This breaks LLDB Arm/Linux buildbot. 
>> https://lab.llvm.org/buildbot/#/builders/17/builds/14035
>
> I will check this out on linux. Any reason why I did not get a message to my 
> email that this was failing?

I checked this out on normal linux and it passes correctly.

I modified the test file to dump more input context so we can see what is going 
on on the lldb-arm-ubuntu buildbots in the error output with:

commit 266a66c915cbbc36b1a3887963eb97f32306c7e4 
 (HEAD -> 
main, origin/main, origin/HEAD)
Author: Greg Clayton 
Date:   Thu Dec 2 15:47:15 2021 -0800

  Include extra input contents on this test so we can see why lldb-arm-ubuntu 
buildbot is failing.
  
  Only lldb-arm-ubuntu is failing after https://reviews.llvm.org/D114288 and 
there isn't enough input context to see why this is failing. It works on x86_64 
linux just fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114288

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

[Lldb-commits] [PATCH] D114923: [lldb/plugins] Add arm64(e) support to ScriptedProcess

2021-12-02 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere added a comment.

Can we add a small test for the error messages?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114923

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

[Lldb-commits] [PATCH] D113650: [lldb] fix -print-script-interpreter-info on windows

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

I can't build on macOS now. I checked out the source code and tried to do:

  cmake -G Ninja -DCMAKE_BUILD_TYPE:STRING=Debug 
-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE 
-DLLVM_ENABLE_PROJECTS='clang;libcxx;libcxxabi;lldb' 
-DLLDB_BUILD_FRAMEWORK:BOOL=TRUE -DLLDB_USE_SYSTEM_DEBUGSERVER=ON 
-DLLDB_EDITLINE_USE_WCHAR=0 -DLLDB_ENABLE_LIBEDIT:BOOL=TRUE 
-DLLDB_ENABLE_CURSES:BOOL=TRUE -DLLDB_ENABLE_PYTHON:BOOL=TRUE 
-DLLDB_ENABLE_LIBXML2:BOOL=TRUE -DLLDB_ENABLE_LUA:BOOL=FALSE 
../llvm-project/llvm

The error is:

  Traceback (most recent call last):
File 
"/Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/bindings/python/get-python-config.py",
 line 60, in 
  main()
File 
"/Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/bindings/python/get-python-config.py",
 line 33, in main
  print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
File 
"/Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/bindings/python/get-python-config.py",
 line 14, in relpath_nodots
  raise ValueError(f"{path} is not under {base}")
  ValueError: /Library/Python/3.8/site-packages is not under 
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8
  CMake Error at 
/Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt:2
 (message):
LLDB_PYTHON_RELATIVE_PATH is not set.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113650

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

[Lldb-commits] [PATCH] D113650: [lldb] fix -print-script-interpreter-info on windows

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

if I try to manually set the python3 executable with:

  -DPYTHON_EXECUTABLE=/Applications/Xcode.app/Contents/Developer/usr/bin/python3

I get the following error:

  [cmake] CMake Error at 
/Users/gclayton/Documents/src/lldb/clean/llvm-project/lldb/CMakeLists.txt:53 
(message):
  [cmake]   Crosscompiling LLDB with Python requires manually setting
  [cmake]   LLDB_PYTHON_RELATIVE_PATH.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113650

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

[Lldb-commits] [PATCH] D113650: [lldb] fix -print-script-interpreter-info on windows

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

I am not cross compiling in this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113650

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

[Lldb-commits] [PATCH] D115001: Simplify logic to identify dyld_sim in Simulator debugging on macos

2021-12-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

We will have gotten the full triple from debugserver by the time we get here, 
so we'll know the Simulator bit, and we get the os_type for dyld_sim from the 
mach-o header, which has to be right for other (swift) reasons.  So this seems 
like a solid way to determine which dyld we should use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115001

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

[Lldb-commits] [PATCH] D114008: Draft PR for the deque, stack, queue lldb data formatters

2021-12-02 Thread walter erquinigo via Phabricator via lldb-commits 
wallace updated this revision to Diff 391513.
wallace added a comment.

Fix the few issues in Danil's implementation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114008

Files:
  lldb/examples/synthetic/gnu_libstdcpp.py
  lldb/examples/synthetic/libcxx.py
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/TestDataFormatterGenericDeque.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/main.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/main.cpp
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/main.cpp
+++ /dev/null
@@ -1,8 +0,0 @@
-#include 
-
-int main() {
-  std::deque empty;
-  std::deque deque_1 = {1};
-  std::deque deque_3 = {3, 1, 2};
-  return empty.size() + deque_1.front() + deque_3.front(); // break here
-}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/deque/TestDataFormatterLibcxxDeque.py
+++ /dev/null
@@ -1,25 +0,0 @@
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbtest import *
-from lldbsuite.test import lldbutil
-
-
-class LibcxxDequeDataFormatterTestCase(TestBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-@add_test_categories(["libc++"])
-def test(self):
-self.build()
-lldbutil.run_to_source_breakpoint(self, "break here",
-  lldb.SBFileSpec("main.cpp"))
-
-self.expect_expr("empty", result_children=[])
-self.expect_expr("deque_1", result_children=[
-ValueCheck(name="[0]", value="1"),
-])
-self.expect_expr("deque_3", result_children=[
-ValueCheck(name="[0]", value="3"),
-ValueCheck(name="[1]", value="1"),
-ValueCheck(name="[2]", value="2")
-])
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/main.cpp
@@ -0,0 +1,41 @@
+#include 
+#include 
+
+struct Foo_small {
+  int a;
+  int b;
+  int c;
+
+  Foo_small(int a, int b, int c) : a(a), b(b), c(c) {}
+};
+
+struct Foo_large {
+  int a;
+  int b;
+  int c;
+  char d[1000] = {0};
+
+  Foo_large(int a, int b, int c) : a(a), b(b), c(c) {}
+};
+
+template  T fill(T deque) {
+  for (int i = 0; i < 100; i++) {
+deque.push_back({i, i + 1, i + 2});
+deque.push_front({-i, -(i + 1), -(i + 2)});
+  }
+  return deque;
+}
+
+int main() {
+  std::deque empty;
+  std::deque deque_1 = {1};
+  std::deque deque_3 = {3, 1, 2};
+
+  std::deque deque_200_small;
+  deque_200_small = fill>(deque_200_small);
+
+  std::deque deque_200_large;
+  deque_200_large = fill>(deque_200_large);
+
+  return empty.size() + deque_1.front() + deque_3.front(); // break here
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/TestDataFormatterGenericDeque.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/deque/TestDataFormatterGenericDeque.py
@@ -0,0 +1,76 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class GenericDequeDataFormatterTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def findVariable(self, name):
+var = self.frame().FindVariable(name)
+self.assertTrue(var.IsValid())
+return var
+
+def getVariableType(self, name):
+var = self.findVariable(name)
+return var.GetType().GetDisplayTypeName()
+
+def check_size(self, var_name, size):
+var = self.findVariable(var_name)
+self.assertEqual(var.GetNumChildren(), size)
+
+
+def do_test(self, stdlib_type):
+self.build(dictionary={stdlib_type: '1'})
+lldbutil.run_to_source_breakpoint(self, "break here",
+  lldb.SBFileSpec("main.cpp"))
+
+self.expect_expr("emp

[Lldb-commits] [PATCH] D115017: Fix error reporting for "process load" and add a test for it.

2021-12-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham created this revision.
jingham added a reviewer: JDevlieghere.
Herald added a subscriber: emaste.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

We weren't reporting errors (like file not found) from "process load", because 
when you just passed one string and no paths, the utility function didn't 
actually gather the error.  Fix that and add a test.

The only weak part of the patch is that the error string comes from the 
platform plugin so I don't actually know what it is going to look like.  So I 
tested that we don't produce the "unknown error" string instead.  That's not 
really API, it's just what the only current implementation produces when it 
couldn't get the error.  If we get a second implementation, we'll either just 
ensure it produces the same string or extract that somewhere and set it as the 
generic error.  But that seemed overkill for this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115017

Files:
  lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  lldb/test/API/functionalities/load_unload/TestLoadUnload.py
  lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py


Index: lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
===
--- lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
+++ lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
@@ -65,7 +65,12 @@
 # First try with no correct directories on the path, and make sure 
that doesn't blow up:
 token = process.LoadImageUsingPaths(lib_spec, paths, out_spec, error)
 self.assertEqual(token, lldb.LLDB_INVALID_IMAGE_TOKEN, "Only looked on 
the provided path.")
-
+# Make sure we got some error back in this case.  Since we don't 
actually know what
+# the error will look like, let's look for the absence of "unknown 
reasons".
+error_str = error.description
+self.assertNotEqual(len(error_str), 0, "Got an empty error string")
+self.assertNotIn("unknown reasons", error_str, "Error string had 
unknown reasons")
+
 # Now add the correct dir to the paths list and try again:
 paths.AppendString(self.hidden_dir)
 token = process.LoadImageUsingPaths(lib_spec, paths, out_spec, error)
@@ -121,8 +126,6 @@
 
 process.UnloadImage(token)
 
-
-
 # Finally, passing in an absolute path should work like the basename:
 # This should NOT work because we've taken hidden_dir off the paths:
 abs_spec = lldb.SBFileSpec(os.path.join(self.hidden_dir, 
self.lib_name))
@@ -137,5 +140,3 @@
 
 self.assertNotEqual(token, lldb.LLDB_INVALID_IMAGE_TOKEN, "Got a valid 
token")
 self.assertEqual(out_spec, lldb.SBFileSpec(self.hidden_lib), "Found 
the expected library")
-
-
Index: lldb/test/API/functionalities/load_unload/TestLoadUnload.py
===
--- lldb/test/API/functionalities/load_unload/TestLoadUnload.py
+++ lldb/test/API/functionalities/load_unload/TestLoadUnload.py
@@ -240,6 +240,15 @@
 else:
 remoteDylibPath = localDylibPath
 
+# First make sure that we get some kind of error if process load fails.
+# We print some error even if the load fails, which isn't formalized.
+# The only plugin at present (Posix) that supports this says "unknown 
reasons".
+# If another plugin shows up, let's require it uses "unknown error" as 
well.
+non_existant_shlib = "/NoSuchDir/NoSuchSubdir/ReallyNo/NotAFile"
+self.expect("process load %s"%(non_existant_shlib), error=True, 
matching=False,
+patterns=["unknown reasons"])
+
+
 # Make sure that a_function does not exist at this point.
 self.expect(
 "image lookup -n a_function",
Index: lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
===
--- lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
+++ lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
@@ -589,6 +589,8 @@
   result_ptr->image_ptr = dlopen(name, RTLD_LAZY);
   if (result_ptr->image_ptr)
 result_ptr->error_str = nullptr;
+  else
+result_ptr->error_str = dlerror();
   return nullptr;
 }
 


Index: lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
===
--- lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
+++ lldb/test/API/functionalities/load_using_paths/TestLoadUsingPaths.py
@@ -65,7 +65,12 @@
 # First try with no correct directories on the path, and make sure that doesn't blow up:
 token = process.LoadImageUsingPaths(lib_spec, paths, out_spec, error)
 self.assertEqual(token, lldb.LLDB_INVALID_IMA

[Lldb-commits] [PATCH] D115001: Simplify logic to identify dyld_sim in Simulator debugging on macos

2021-12-02 Thread Jason Molenda via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfddafa110d86: Simplify logic to identify dyld_sim in 
Simulator debugging on macos (authored by jasonmolenda).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115001

Files:
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp


Index: lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
===
--- lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -540,35 +540,18 @@
   const size_t image_infos_size = image_infos.size();
   for (size_t i = 0; i < image_infos_size; i++) {
 if (image_infos[i].header.filetype == llvm::MachO::MH_DYLINKER) {
-  // In a "simulator" process (an x86 process that is 
-  // ios/tvos/watchos/bridgeos) we will have two dyld modules -- 
+  // In a "simulator" process we will have two dyld modules -- 
   // a "dyld" that we want to keep track of, and a "dyld_sim" which 
-  // we don't need to keep track of here. If the target is an x86 
-  // system and the OS of the dyld binary is ios/tvos/watchos/bridgeos, 
-  // then we are looking at dyld_sym.
-
-  // debugserver has only recently (late 2016) started sending up the os
-  // type for each binary it sees -- so if we don't have an os type, use a
-  // filename check as our next best guess.
-  if (image_infos[i].os_type == llvm::Triple::OSType::UnknownOS) {
-if (image_infos[i].file_spec.GetFilename() != g_dyld_sim_filename) {
-  dyld_idx = i;
-}
-  } else if (target_arch.GetTriple().getArch() == llvm::Triple::x86 ||
- target_arch.GetTriple().getArch() == llvm::Triple::x86_64) {
-if (image_infos[i].os_type != llvm::Triple::OSType::IOS &&
-image_infos[i].os_type != llvm::Triple::TvOS &&
-image_infos[i].os_type != llvm::Triple::WatchOS) {
-// NEED_BRIDGEOS_TRIPLE image_infos[i].os_type != 
llvm::Triple::BridgeOS) {
-  dyld_idx = i;
-}
+  // we don't need to keep track of here.  dyld_sim will have a non-macosx
+  // OS.
+  if (target_arch.GetTriple().getEnvironment() == llvm::Triple::Simulator 
&&
+  image_infos[i].os_type != llvm::Triple::OSType::MacOSX) {
+continue;
   }
-  else {
-// catch-all for any other environment -- trust that dyld is actually
-// dyld
-dyld_idx = i;
-  }
-} else if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
+
+  dyld_idx = i;
+} 
+if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
   exe_idx = i;
 }
   }


Index: lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
===
--- lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -540,35 +540,18 @@
   const size_t image_infos_size = image_infos.size();
   for (size_t i = 0; i < image_infos_size; i++) {
 if (image_infos[i].header.filetype == llvm::MachO::MH_DYLINKER) {
-  // In a "simulator" process (an x86 process that is 
-  // ios/tvos/watchos/bridgeos) we will have two dyld modules -- 
+  // In a "simulator" process we will have two dyld modules -- 
   // a "dyld" that we want to keep track of, and a "dyld_sim" which 
-  // we don't need to keep track of here. If the target is an x86 
-  // system and the OS of the dyld binary is ios/tvos/watchos/bridgeos, 
-  // then we are looking at dyld_sym.
-
-  // debugserver has only recently (late 2016) started sending up the os
-  // type for each binary it sees -- so if we don't have an os type, use a
-  // filename check as our next best guess.
-  if (image_infos[i].os_type == llvm::Triple::OSType::UnknownOS) {
-if (image_infos[i].file_spec.GetFilename() != g_dyld_sim_filename) {
-  dyld_idx = i;
-}
-  } else if (target_arch.GetTriple().getArch() == llvm::Triple::x86 ||
- target_arch.GetTriple().getArch() == llvm::Triple::x86_64) {
-if (image_infos[i].os_type != llvm::Triple::OSType::IOS &&
-image_infos[i].os_type != llvm::Triple::TvOS &&
-image_infos[i].os_type != llvm::Triple::WatchOS) {
-// NEED_BRIDGEOS_TRIPLE image_infos[i].os_type != llvm::Triple::BridgeOS) {
-  dyld_idx = i;
-}
+  // we don't need to keep track of here.  dyld_sim will have a non-macosx
+  // OS.
+  if (target_arch.GetTriple().getEnvironment() == llvm::Triple::Simulator &&
+  image_infos[i].os_type != llvm::Triple::OSType::MacOSX) {
+continue;
   }
-  else {
-

[Lldb-commits] [lldb] fddafa1 - Simplify logic to identify dyld_sim in Simulator debugging on macos

2021-12-02 Thread Jason Molenda via lldb-commits 

Author: Jason Molenda
Date: 2021-12-02T18:14:13-08:00
New Revision: fddafa110d8628851a48939fe956864b318e8e53

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

LOG: Simplify logic to identify dyld_sim in Simulator debugging on macos

When debugging a Simulator process on macOS (e.g. the iPhone simulator),
the process will have both a dyld, and a dyld_sim present.  The dyld_sim
is an iOS Simulator binary.  The dyld is a macOS binary.  Both are
MH_DYLINKER filetypes.  lldb needs to identify & set a breakpoint in
dyld, so it has to distinguish between these two.

Previously lldb was checking if the inferior target was x86 (indicating
macOS) and the OS of the MH_DYLINKER binary was iOS/watchOS/etc -- if
so, then this is dyld_sim and we should ignore it.  Now with arm64
macOS systems, this check was invalid, and we would set our breakpoint
for new binaries being loaded in dyld_sim, causing binary loading to
be missed by lldb.

This patch uses the Target's ArchSpec triple environment, to see if
this process is a simulator process.  If this is a Simulator process,
then we only recognize a MH_DYLINKER binary with OS type macOS as
being dyld.

This patch also removes some code that handled pre-2016 era debugservers
which didn't give us the OS type for each binary.  This was only being
used on macOS, where we don't need to handle the presence of very old
debugservers.

Differential Revision: https://reviews.llvm.org/D115001
rdar://85907839

Added: 


Modified: 
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
index 95bd3988aaf75..319d0eaa7aa8b 100644
--- a/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
+++ b/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
@@ -540,35 +540,18 @@ void 
DynamicLoaderDarwin::UpdateSpecialBinariesFromNewImageInfos(
   const size_t image_infos_size = image_infos.size();
   for (size_t i = 0; i < image_infos_size; i++) {
 if (image_infos[i].header.filetype == llvm::MachO::MH_DYLINKER) {
-  // In a "simulator" process (an x86 process that is 
-  // ios/tvos/watchos/bridgeos) we will have two dyld modules -- 
+  // In a "simulator" process we will have two dyld modules -- 
   // a "dyld" that we want to keep track of, and a "dyld_sim" which 
-  // we don't need to keep track of here. If the target is an x86 
-  // system and the OS of the dyld binary is ios/tvos/watchos/bridgeos, 
-  // then we are looking at dyld_sym.
-
-  // debugserver has only recently (late 2016) started sending up the os
-  // type for each binary it sees -- so if we don't have an os type, use a
-  // filename check as our next best guess.
-  if (image_infos[i].os_type == llvm::Triple::OSType::UnknownOS) {
-if (image_infos[i].file_spec.GetFilename() != g_dyld_sim_filename) {
-  dyld_idx = i;
-}
-  } else if (target_arch.GetTriple().getArch() == llvm::Triple::x86 ||
- target_arch.GetTriple().getArch() == llvm::Triple::x86_64) {
-if (image_infos[i].os_type != llvm::Triple::OSType::IOS &&
-image_infos[i].os_type != llvm::Triple::TvOS &&
-image_infos[i].os_type != llvm::Triple::WatchOS) {
-// NEED_BRIDGEOS_TRIPLE image_infos[i].os_type != 
llvm::Triple::BridgeOS) {
-  dyld_idx = i;
-}
+  // we don't need to keep track of here.  dyld_sim will have a non-macosx
+  // OS.
+  if (target_arch.GetTriple().getEnvironment() == llvm::Triple::Simulator 
&&
+  image_infos[i].os_type != llvm::Triple::OSType::MacOSX) {
+continue;
   }
-  else {
-// catch-all for any other environment -- trust that dyld is actually
-// dyld
-dyld_idx = i;
-  }
-} else if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
+
+  dyld_idx = i;
+} 
+if (image_infos[i].header.filetype == llvm::MachO::MH_EXECUTE) {
   exe_idx = i;
 }
   }



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

[Lldb-commits] [PATCH] D113650: [lldb] fix -print-script-interpreter-info on windows

2021-12-02 Thread Lawrence D'Anna via Phabricator via lldb-commits 
lawrence_danna added a comment.

@clayborg

Does this fix it for you?

https://reviews.llvm.org/D114973


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113650

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

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg accepted this revision.
clayborg added a comment.

Yep, fixes it for me! Thanks!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114973

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

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added inline comments.



Comment at: lldb/bindings/python/get-python-config.py:71
 main()
\ No newline at end of file


Add newline


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114973

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

[Lldb-commits] [PATCH] D113650: [lldb] fix -print-script-interpreter-info on windows

2021-12-02 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

In D113650#3168812 , @lawrence_danna 
wrote:

> @clayborg
>
> Does this fix it for you?
>
> https://reviews.llvm.org/D114973

Yes it does! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113650

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

[Lldb-commits] [lldb] 27ca945 - [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Lawrence D'Anna via lldb-commits 

Author: Lawrence D'Anna
Date: 2021-12-02T21:13:35-08:00
New Revision: 27ca9458012caf8b556ce31fc7aaac571af878d2

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

LOG: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

Some pythons are configured to set platlib somewhere outside of their
sys.prefix.   It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.

Reviewed By: JDevlieghere, clayborg

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

Added: 


Modified: 
lldb/bindings/python/get-python-config.py

Removed: 




diff  --git a/lldb/bindings/python/get-python-config.py 
b/lldb/bindings/python/get-python-config.py
index 5b670d77451a3..32d82a54c160f 100755
--- a/lldb/bindings/python/get-python-config.py
+++ b/lldb/bindings/python/get-python-config.py
@@ -30,7 +30,17 @@ def main():
 # lldb's python lib will be put in the correct place for python to 
find it.
 # If not, you'll have to use lldb -P or lldb 
-print-script-interpreter-info
 # to figure out where it is.
-print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+try:
+print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+except ValueError:
+# Try to fall back to something reasonable if sysconfig's platlib
+# is outside of sys.prefix
+if os.name == 'posix':
+print('lib/python%d.%d/site-packages' % sys.version_info[:2])
+elif os.name == 'nt':
+print('Lib\\site-packages')
+else:
+raise
 elif args.variable_name == "LLDB_PYTHON_EXE_RELATIVE_PATH":
 tried = list()
 exe = sys.executable
@@ -57,4 +67,4 @@ def main():
 parser.error(f"unknown variable {args.variable_name}")
 
 if __name__ == '__main__':
-main()
\ No newline at end of file
+main()



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

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Lawrence D'Anna via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG27ca9458012c: [lldb] add fallback for 
LLDB_PYTHON_RELATIVE_PATH (authored by lawrence_danna).

Changed prior to commit:
  https://reviews.llvm.org/D114973?vs=391384&id=391541#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114973

Files:
  lldb/bindings/python/get-python-config.py


Index: lldb/bindings/python/get-python-config.py
===
--- lldb/bindings/python/get-python-config.py
+++ lldb/bindings/python/get-python-config.py
@@ -30,7 +30,17 @@
 # lldb's python lib will be put in the correct place for python to 
find it.
 # If not, you'll have to use lldb -P or lldb 
-print-script-interpreter-info
 # to figure out where it is.
-print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+try:
+print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+except ValueError:
+# Try to fall back to something reasonable if sysconfig's platlib
+# is outside of sys.prefix
+if os.name == 'posix':
+print('lib/python%d.%d/site-packages' % sys.version_info[:2])
+elif os.name == 'nt':
+print('Lib\\site-packages')
+else:
+raise
 elif args.variable_name == "LLDB_PYTHON_EXE_RELATIVE_PATH":
 tried = list()
 exe = sys.executable
@@ -57,4 +67,4 @@
 parser.error(f"unknown variable {args.variable_name}")
 
 if __name__ == '__main__':
-main()
\ No newline at end of file
+main()


Index: lldb/bindings/python/get-python-config.py
===
--- lldb/bindings/python/get-python-config.py
+++ lldb/bindings/python/get-python-config.py
@@ -30,7 +30,17 @@
 # lldb's python lib will be put in the correct place for python to find it.
 # If not, you'll have to use lldb -P or lldb -print-script-interpreter-info
 # to figure out where it is.
-print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+try:
+print(relpath_nodots(sysconfig.get_path("platlib"), sys.prefix))
+except ValueError:
+# Try to fall back to something reasonable if sysconfig's platlib
+# is outside of sys.prefix
+if os.name == 'posix':
+print('lib/python%d.%d/site-packages' % sys.version_info[:2])
+elif os.name == 'nt':
+print('Lib\\site-packages')
+else:
+raise
 elif args.variable_name == "LLDB_PYTHON_EXE_RELATIVE_PATH":
 tried = list()
 exe = sys.executable
@@ -57,4 +67,4 @@
 parser.error(f"unknown variable {args.variable_name}")
 
 if __name__ == '__main__':
-main()
\ No newline at end of file
+main()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D114973: [lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

2021-12-02 Thread Lawrence D'Anna via Phabricator via lldb-commits 
lawrence_danna marked an inline comment as done.
lawrence_danna added a comment.

fixed whitespace and commited


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114973

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