[Lldb-commits] [PATCH] D109384: [lldb] Delete IRExecutionUnit::SearchSpec

2021-09-07 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/D109384/new/

https://reviews.llvm.org/D109384

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


[Lldb-commits] [PATCH] D109101: [lldb] Add an option to specify a VFS overlay

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

LGTM




Comment at: lldb/source/API/SBDebugger.cpp:878
   // call the target triple version.
-  error = m_opaque_sp->GetTargetList().CreateTarget(*m_opaque_sp, 
filename, 
-  arch_cstr, eLoadDependentsYes, nullptr, target_sp);
+  error = m_opaque_sp->GetTargetList().CreateTarget(
+  *m_opaque_sp, filename, arch_cstr, eLoadDependentsYes, nullptr,

These two are just reformatting, right?  I can't see any actual difference.


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

https://reviews.llvm.org/D109101

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


[Lldb-commits] [PATCH] D108944: [LLDB][GUI] Add source file searcher

2021-09-07 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

Sorry for the delay, yes this looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108944

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


[Lldb-commits] [PATCH] D109384: [lldb] Delete IRExecutionUnit::SearchSpec

2021-09-07 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Looks fine to me. I will let others that specialize more in the expression 
evaluator accept this., though it would be good to verify this code looks the 
same in the Swift branches


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109384

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


[Lldb-commits] [PATCH] D109384: [lldb] Delete IRExecutionUnit::SearchSpec

2021-09-07 Thread Alex Langford via Phabricator via lldb-commits
bulbazord created this revision.
bulbazord added reviewers: clayborg, jingham, teemperor, JDevlieghere.
bulbazord requested review of this revision.
Herald added a project: LLDB.

IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with a ConstString and a FunctionNameType mask.
Because the mask is unused (effectively always set to
eFunctionNameTypeFull), we can remove the mask and replace all uses with
eFunctionNameTypeFull.  After doing that, SearchSpec is effectively a
wrapper around a ConstString.

As an aside, SearchSpec is similar in purpose to Module::LookupInfo. I
briefly considered replacing uses of SearchSpec with LookupInfo, but
the current code only cares about symbol names (treating them as
eFunctionNameTypeFull). This code does care about language type, so
LookupInfo may be appropriate for IRExecutionUnit in the future.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109384

Files:
  lldb/include/lldb/Expression/IRExecutionUnit.h
  lldb/source/Expression/IRExecutionUnit.cpp

Index: lldb/source/Expression/IRExecutionUnit.cpp
===
--- lldb/source/Expression/IRExecutionUnit.cpp
+++ lldb/source/Expression/IRExecutionUnit.cpp
@@ -698,29 +698,17 @@
 return ConstString();
 }
 
-struct IRExecutionUnit::SearchSpec {
-  ConstString name;
-  lldb::FunctionNameType mask;
-
-  SearchSpec(ConstString n,
- lldb::FunctionNameType m = lldb::eFunctionNameTypeFull)
-  : name(n), mask(m) {}
-};
-
-void IRExecutionUnit::CollectCandidateCNames(
-std::vector _specs,
-ConstString name) {
+void IRExecutionUnit::CollectCandidateCNames(std::vector _names,
+ ConstString name) {
   if (m_strip_underscore && name.AsCString()[0] == '_')
-C_specs.insert(C_specs.begin(), ConstString(()[1]));
-  C_specs.push_back(SearchSpec(name));
+C_names.insert(C_names.begin(), ConstString(()[1]));
+  C_names.push_back(name);
 }
 
 void IRExecutionUnit::CollectCandidateCPlusPlusNames(
-std::vector _specs,
-const std::vector _specs, const SymbolContext ) {
-  for (const SearchSpec _spec : C_specs) {
-ConstString name = C_spec.name;
-
+std::vector _names,
+const std::vector _names, const SymbolContext ) {
+  for (const ConstString  : C_names) {
 if (CPlusPlusLanguage::IsCPPMangledName(name.GetCString())) {
   Mangled mangled(name);
   ConstString demangled = mangled.GetDemangledName();
@@ -730,26 +718,24 @@
 FindBestAlternateMangledName(demangled, sc);
 
 if (best_alternate_mangled_name) {
-  CPP_specs.push_back(best_alternate_mangled_name);
+  CPP_names.push_back(best_alternate_mangled_name);
 }
   }
 }
 
 std::set alternates;
 CPlusPlusLanguage::FindAlternateFunctionManglings(name, alternates);
-CPP_specs.insert(CPP_specs.end(), alternates.begin(), alternates.end());
+CPP_names.insert(CPP_names.end(), alternates.begin(), alternates.end());
   }
 }
 
 void IRExecutionUnit::CollectFallbackNames(
-std::vector _specs,
-const std::vector _specs) {
+std::vector _names,
+const std::vector _names) {
   // As a last-ditch fallback, try the base name for C++ names.  It's terrible,
   // but the DWARF doesn't always encode "extern C" correctly.
 
-  for (const SearchSpec _spec : C_specs) {
-ConstString name = C_spec.name;
-
+  for (const ConstString  : C_names) {
 if (!CPlusPlusLanguage::IsCPPMangledName(name.GetCString()))
   continue;
 
@@ -763,9 +749,8 @@
 if (!lparen_loc)
   continue;
 
-llvm::StringRef base_name(demangled_cstr,
-  lparen_loc - demangled_cstr);
-fallback_specs.push_back(ConstString(base_name));
+llvm::StringRef base_name(demangled_cstr, lparen_loc - demangled_cstr);
+fallback_names.push_back(ConstString(base_name));
   }
 }
 
@@ -843,9 +828,10 @@
   lldb::addr_t m_best_internal_load_address = LLDB_INVALID_ADDRESS;
 };
 
-lldb::addr_t IRExecutionUnit::FindInSymbols(
-const std::vector ,
-const lldb_private::SymbolContext , bool _was_missing_weak) {
+lldb::addr_t
+IRExecutionUnit::FindInSymbols(const std::vector ,
+   const lldb_private::SymbolContext ,
+   bool _was_missing_weak) {
   symbol_was_missing_weak = false;
 
   Target *target = sc.target_sp.get();
@@ -860,18 +846,19 @@
   function_options.include_symbols = true;
   function_options.include_inlines = false;
 
-  for (const SearchSpec  : specs) {
+  for (const ConstString  : names) {
 if (sc.module_sp) {
   SymbolContextList sc_list;
-  sc.module_sp->FindFunctions(spec.name, CompilerDeclContext(), spec.mask,
-  function_options, sc_list);
+  sc.module_sp->FindFunctions(name, CompilerDeclContext(),
+   

[Lldb-commits] [PATCH] D109185: [gn build] Add build files for LLDB

2021-09-07 Thread Nico Weber via Phabricator via lldb-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcfe02847496b: [gn build] Add build files for LLDB (authored 
by thakis).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Changed prior to commit:
  https://reviews.llvm.org/D109185?vs=371131=371149#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109185

Files:
  lldb/source/Symbol/CMakeLists.txt
  llvm/utils/gn/build/BUILD.gn
  llvm/utils/gn/build/toolchain/BUILD.gn
  llvm/utils/gn/secondary/BUILD.gn
  llvm/utils/gn/secondary/lldb/include/lldb/Host/BUILD.gn
  llvm/utils/gn/secondary/lldb/include/lldb/Host/libedit.gni
  llvm/utils/gn/secondary/lldb/source/API/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Breakpoint/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Commands/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Core/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/DataFormatters/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Expression/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Host/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Host/macosx/objcxx/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Initialization/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Interpreter/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ABI/X86/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Architecture/PPC64/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Disassembler/LLVMC/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/DynamicLoader/Static/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ExpressionParser/Clang/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Instruction/ARM/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/JITLoader/GDB/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Language/CPlusPlus/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Language/ClangCommon/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Language/ObjC/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Language/ObjCPlusPlus/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/LanguageRuntime/CPlusPlus/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/LanguageRuntime/ObjC/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/ObjectContainer/BSD-Archive/BUILD.gn
  
llvm/utils/gn/secondary/lldb/source/Plugins/ObjectContainer/Universal-Mach-O/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/Breakpad/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/ELF/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/JIT/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/Mach-O/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/PDB/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/PECOFF/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ObjectFile/wasm/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Platform/MacOSX/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Platform/MacOSX/objcxx/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Platform/POSIX/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Platform/Windows/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Process/Utility/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Process/elf-core/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Process/gdb-remote/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Process/mach-core/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/Process/minidump/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/ScriptInterpreter/None/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolFile/Breakpad/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolFile/DWARF/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolFile/NativePDB/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolFile/PDB/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolFile/Symtab/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolVendor/ELF/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolVendor/MacOSX/BUILD.gn
  llvm/utils/gn/secondary/lldb/source/Plugins/SymbolVendor/wasm/BUILD.gn
  

[Lldb-commits] [PATCH] D108148: [lldb] [gdb-remote] Use standardized GDB errno values

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

In D108148#2987460 , @labath wrote:

> Nah, tablegen is overkill. I was thinking of something similar to (but 
> simpler than) `include/llvm/BinaryFormat/Dwarf.def`.

Yeah, that looks easier. You got me scared there for a sec!


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

https://reviews.llvm.org/D108148

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


[Lldb-commits] [PATCH] D106226: [lldb] Improve error message when "lldb attach" fails

2021-09-07 Thread Jim Ingham via Phabricator via lldb-commits
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

This seems like a good idea, but the functionality belongs in the Linux 
Platform, not in the Target.cpp.  We try really hard to keep platform specific 
details out of the generic files.




Comment at: lldb/source/Target/Target.cpp:3121
 
+const char *fetchPtracePolicyIfApplicable(lldb::PlatformSP platform_sp) {
+  FileSpec filespec =

DavidSpickett wrote:
> Make this function static since it's only used in this file.
This function does not belong in Target.cpp.  This is Platform specific 
functionality and so belongs in the Linux Platform..  You need to add a 
"GetLaunchErrorDetails" or some better name for the general API, and implement 
that for the Unix systems that support proc, or only Linux if this 
functionality is only on Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106226

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


[Lldb-commits] [PATCH] D109272: [lldb] [gdb-remote] Try using for remote arch unconditionally

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 371136.
mgorny added a comment.

Require respective targets for tests, and tests for the generic AArch64 aliases 
that already work.


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

https://reviews.llvm.org/D109272

Files:
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
  lldb/test/API/functionalities/gdb_remote_client/basic_eh_frame-i386.yaml

Index: lldb/test/API/functionalities/gdb_remote_client/basic_eh_frame-i386.yaml
===
--- /dev/null
+++ lldb/test/API/functionalities/gdb_remote_client/basic_eh_frame-i386.yaml
@@ -0,0 +1,47 @@
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS32
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+  Entry:   0x00401000
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x00401000
+AddressAlign:0x0001
+Content: C3
+  - Name:.eh_frame
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC ]
+Address: 0x00402000
+AddressAlign:0x0008
+Content: 1800017A5200017810011B0C070890010E80010010002000DCEF0100
+Symbols:
+  - Name:.text
+Type:STT_SECTION
+Section: .text
+Value:   0x00401000
+  - Name:.eh_frame
+Type:STT_SECTION
+Section: .eh_frame
+Value:   0x00402000
+  - Name:_start
+Binding: STB_GLOBAL
+  - Name:__bss_start
+Section: .eh_frame
+Binding: STB_GLOBAL
+Value:   0x00404000
+  - Name:foo
+Section: .text
+Binding: STB_GLOBAL
+Value:   0x00401000
+  - Name:_edata
+Section: .eh_frame
+Binding: STB_GLOBAL
+Value:   0x00404000
+  - Name:_end
+Section: .eh_frame
+Binding: STB_GLOBAL
+Value:   0x00404000
Index: lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
@@ -275,3 +275,270 @@
["ymm0 = {0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 "
 "0xda 0xdb 0xdc 0xdd 0xde 0xdf 0xe0 0xe1 0xe2 0xe3 0xe4 "
 "0xe5 0xe6 0xe7 0xe8 0xe9 0xea 0xeb 0xec 0xed 0xee 0xef}"])
+
+@skipIfXmlSupportMissing
+@skipIfRemote
+@skipIfLLVMTargetMissing("X86")
+def test_i386_regs(self):
+"""Test grabbing various i386 registers from gdbserver."""
+reg_data = [
+"01020304",  # eax
+"11121314",  # ecx
+"21222324",  # edx
+"31323334",  # ebx
+"41424344",  # esp
+"51525354",  # ebp
+"61626364",  # esi
+"71727374",  # edi
+"81828384",  # eip
+"91929394",  # eflags
+"0102030405060708090a",  # st0
+"1112131415161718191a",  # st1
+] + 6 * [
+"2122232425262728292a"  # st2..st7
+] + [
+"8182838485868788898a8b8c8d8e8f90",  # xmm0
+"9192939495969798999a9b9c9d9e9fa0",  # xmm1
+] + 6 * [
+"a1a2a3a4a5a6a7a8a9aaabacadaeafb0",  # xmm2..xmm7
+] + [
+"",  # mxcsr
+] + [
+"b1b2b3b4b5b6b7b8b9babbbcbdbebfc0",  # ymm0h
+"c1c2c3c4c5c6c7c8c9cacbcccdcecfd0",  # ymm1h
+] + 6 * [
+"d1d2d3d4d5d6d7d8d9dadbdcdddedfe0",  # ymm2h..ymm7h
+]
+
+class MyResponder(MockGDBServerResponder):
+def qXferRead(self, obj, annex, offset, length):
+if annex == "target.xml":
+return """
+
+
+  i386
+  GNU/Linux
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+

[Lldb-commits] [PATCH] D108018: [lldb] [gdb-remote] Support QEnvironment fallback to hex-encoded

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/test/API/tools/lldb-server/main.cpp:332
+  const char *value = getenv(arg.c_str());
+  printf("%s\n", value ? value : "__unset__");
 } else {

mgorny wrote:
> labath wrote:
> > Printing a quoted this in the case of a null pointer is exactly the 
> > opposite of what one would normally expect. It's not a big deal, since we 
> > control the inputs, but it may still be better to print `` or 
> > something like that instead...
> i.e. `s/__unset__//`? I have strong Python background, and double 
> underscores are common for special stuff in Python world.
Actually, never mind. I saw more quotes than there were. This is fine too...


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

https://reviews.llvm.org/D108018

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


[Lldb-commits] [PATCH] D108554: [lldb] Support querying registers via generic names without alt_names

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 371134.
mgorny added a comment.

The test requires building with X86 target.


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

https://reviews.llvm.org/D108554

Files:
  lldb/source/Host/common/NativeRegisterContext.cpp
  lldb/source/Target/RegisterContext.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBServerTargetXML.py
@@ -9,6 +9,7 @@
 
 @skipIfXmlSupportMissing
 @skipIfRemote
+@skipIfLLVMTargetMissing("X86")
 def test_x86_64_vec_regs(self):
 """Test rendering of x86_64 vector registers from gdbserver."""
 class MyResponder(MockGDBServerResponder):
@@ -20,8 +21,16 @@
   i386:x86-64
   GNU/Linux
   
+
+
+
+
+
 
+
+
 
+
 
 
 
@@ -59,8 +68,16 @@
 
 def readRegisters(self):
 return (
-"0102030405060708"  # rsp
-"1112131415161718"  # rip
+"0102030405060708"  # rcx
+"1112131415161718"  # rdx
+"2122232425262728"  # rsi
+"3132333435363738"  # rdi
+"4142434445464748"  # rbp
+"5152535455565758"  # rsp
+"6162636465666768"  # r8
+"7172737475767778"  # r9
+"8182838485868788"  # rip
+"91929394"  # eflags
 "0102030405060708090a"  # st0
 "1112131415161718191a" +  # st1
 "2122232425262728292a" * 6 +  # st2..st7
@@ -82,9 +99,31 @@
 
 # rsp and rip should be displayed as uints
 self.match("register read rsp",
-   ["rsp = 0x0807060504030201"])
+   ["rsp = 0x5857565554535251"])
 self.match("register read rip",
-   ["rip = 0x1817161514131211"])
+   ["rip = 0x8887868584838281"])
+
+# test generic aliases
+self.match("register read arg4",
+   ["rcx = 0x0807060504030201"])
+self.match("register read arg3",
+   ["rdx = 0x1817161514131211"])
+self.match("register read arg2",
+   ["rsi = 0x2827262524232221"])
+self.match("register read arg1",
+   ["rdi = 0x3837363534333231"])
+self.match("register read fp",
+   ["rbp = 0x4847464544434241"])
+self.match("register read sp",
+   ["rsp = 0x5857565554535251"])
+self.match("register read arg5",
+   ["r8 = 0x6867666564636261"])
+self.match("register read arg6",
+   ["r9 = 0x7877767574737271"])
+self.match("register read pc",
+   ["rip = 0x8887868584838281"])
+self.match("register read flags",
+   ["eflags = 0x94939291"])
 
 # both stX and xmmX should be displayed as vectors
 self.match("register read st0",
Index: lldb/source/Target/RegisterContext.cpp
===
--- lldb/source/Target/RegisterContext.cpp
+++ lldb/source/Target/RegisterContext.cpp
@@ -54,6 +54,17 @@
   if (reg_name.empty())
 return nullptr;
 
+  // Try matching generic register names first.  This is consistent with
+  // how aliases work, esp. wrt "sp" generic alias taking precedence over
+  // "sp" pseudo-register on x86_64.
+  uint32_t generic_reg = Args::StringToGenericRegister(reg_name);
+  if (generic_reg != LLDB_INVALID_REGNUM) {
+const RegisterInfo *reg_info =
+GetRegisterInfo(eRegisterKindGeneric, generic_reg);
+if (reg_info)
+  return reg_info;
+  }
+
   const uint32_t num_registers = GetRegisterCount();
   for (uint32_t reg = start_idx; reg < num_registers; ++reg) {
 const RegisterInfo *reg_info = GetRegisterInfoAtIndex(reg);
@@ -62,6 +73,7 @@
 reg_name.equals_insensitive(reg_info->alt_name))
   return reg_info;
   }
+
   return nullptr;
 }
 
Index: lldb/source/Host/common/NativeRegisterContext.cpp
===
--- lldb/source/Host/common/NativeRegisterContext.cpp
+++ lldb/source/Host/common/NativeRegisterContext.cpp
@@ -56,6 +56,17 @@
   if (reg_name.empty())
 

[Lldb-commits] [PATCH] D108148: [lldb] [gdb-remote] Use standardized GDB errno values

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Nah, tablegen is overkill. I was thinking of something similar to (but simpler 
than) `include/llvm/BinaryFormat/Dwarf.def`.


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

https://reviews.llvm.org/D108148

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


[Lldb-commits] [PATCH] D109367: [lldb] Alphabetize some CMake files a bit better

2021-09-07 Thread Nico Weber via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGea04bf302cf8: [lldb] Alphabetize some CMake files a bit 
better (authored by thakis).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109367

Files:
  lldb/source/Plugins/ObjectFile/CMakeLists.txt
  lldb/source/Plugins/SymbolFile/CMakeLists.txt
  lldb/source/Plugins/SymbolVendor/CMakeLists.txt


Index: lldb/source/Plugins/SymbolVendor/CMakeLists.txt
===
--- lldb/source/Plugins/SymbolVendor/CMakeLists.txt
+++ lldb/source/Plugins/SymbolVendor/CMakeLists.txt
@@ -1,6 +1,7 @@
+add_subdirectory(ELF)
+
 if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
   add_subdirectory(MacOSX)
 endif()
 
-add_subdirectory(ELF)
 add_subdirectory(wasm)
Index: lldb/source/Plugins/SymbolFile/CMakeLists.txt
===
--- lldb/source/Plugins/SymbolFile/CMakeLists.txt
+++ lldb/source/Plugins/SymbolFile/CMakeLists.txt
@@ -1,5 +1,5 @@
 add_subdirectory(Breakpad)
 add_subdirectory(DWARF)
-add_subdirectory(Symtab)
 add_subdirectory(NativePDB)
 add_subdirectory(PDB)
+add_subdirectory(Symtab)
Index: lldb/source/Plugins/ObjectFile/CMakeLists.txt
===
--- lldb/source/Plugins/ObjectFile/CMakeLists.txt
+++ lldb/source/Plugins/ObjectFile/CMakeLists.txt
@@ -1,8 +1,8 @@
 add_subdirectory(Breakpad)
 add_subdirectory(ELF)
+add_subdirectory(JIT)
 add_subdirectory(Mach-O)
 add_subdirectory(Minidump)
 add_subdirectory(PDB)
 add_subdirectory(PECOFF)
-add_subdirectory(JIT)
 add_subdirectory(wasm)


Index: lldb/source/Plugins/SymbolVendor/CMakeLists.txt
===
--- lldb/source/Plugins/SymbolVendor/CMakeLists.txt
+++ lldb/source/Plugins/SymbolVendor/CMakeLists.txt
@@ -1,6 +1,7 @@
+add_subdirectory(ELF)
+
 if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
   add_subdirectory(MacOSX)
 endif()
 
-add_subdirectory(ELF)
 add_subdirectory(wasm)
Index: lldb/source/Plugins/SymbolFile/CMakeLists.txt
===
--- lldb/source/Plugins/SymbolFile/CMakeLists.txt
+++ lldb/source/Plugins/SymbolFile/CMakeLists.txt
@@ -1,5 +1,5 @@
 add_subdirectory(Breakpad)
 add_subdirectory(DWARF)
-add_subdirectory(Symtab)
 add_subdirectory(NativePDB)
 add_subdirectory(PDB)
+add_subdirectory(Symtab)
Index: lldb/source/Plugins/ObjectFile/CMakeLists.txt
===
--- lldb/source/Plugins/ObjectFile/CMakeLists.txt
+++ lldb/source/Plugins/ObjectFile/CMakeLists.txt
@@ -1,8 +1,8 @@
 add_subdirectory(Breakpad)
 add_subdirectory(ELF)
+add_subdirectory(JIT)
 add_subdirectory(Mach-O)
 add_subdirectory(Minidump)
 add_subdirectory(PDB)
 add_subdirectory(PECOFF)
-add_subdirectory(JIT)
 add_subdirectory(wasm)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] ea04bf3 - [lldb] Alphabetize some CMake files a bit better

2021-09-07 Thread Nico Weber via lldb-commits

Author: Nico Weber
Date: 2021-09-07T13:19:00-04:00
New Revision: ea04bf302cf8f32bef62208e123d9d0cb99fa55c

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

LOG: [lldb] Alphabetize some CMake files a bit better

No observable behavior change, but makes the generated Plugins.def a bit easier
to read.

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

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/CMakeLists.txt
lldb/source/Plugins/SymbolFile/CMakeLists.txt
lldb/source/Plugins/SymbolVendor/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/CMakeLists.txt 
b/lldb/source/Plugins/ObjectFile/CMakeLists.txt
index 34ad087173f01..042ea826aa3b1 100644
--- a/lldb/source/Plugins/ObjectFile/CMakeLists.txt
+++ b/lldb/source/Plugins/ObjectFile/CMakeLists.txt
@@ -1,8 +1,8 @@
 add_subdirectory(Breakpad)
 add_subdirectory(ELF)
+add_subdirectory(JIT)
 add_subdirectory(Mach-O)
 add_subdirectory(Minidump)
 add_subdirectory(PDB)
 add_subdirectory(PECOFF)
-add_subdirectory(JIT)
 add_subdirectory(wasm)

diff  --git a/lldb/source/Plugins/SymbolFile/CMakeLists.txt 
b/lldb/source/Plugins/SymbolFile/CMakeLists.txt
index ad1c92bd84698..5e18fb154823a 100644
--- a/lldb/source/Plugins/SymbolFile/CMakeLists.txt
+++ b/lldb/source/Plugins/SymbolFile/CMakeLists.txt
@@ -1,5 +1,5 @@
 add_subdirectory(Breakpad)
 add_subdirectory(DWARF)
-add_subdirectory(Symtab)
 add_subdirectory(NativePDB)
 add_subdirectory(PDB)
+add_subdirectory(Symtab)

diff  --git a/lldb/source/Plugins/SymbolVendor/CMakeLists.txt 
b/lldb/source/Plugins/SymbolVendor/CMakeLists.txt
index 695b9a019ae72..3e1b24b498353 100644
--- a/lldb/source/Plugins/SymbolVendor/CMakeLists.txt
+++ b/lldb/source/Plugins/SymbolVendor/CMakeLists.txt
@@ -1,6 +1,7 @@
+add_subdirectory(ELF)
+
 if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
   add_subdirectory(MacOSX)
 endif()
 
-add_subdirectory(ELF)
 add_subdirectory(wasm)



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


[Lldb-commits] [PATCH] D108148: [lldb] [gdb-remote] Use standardized GDB errno values

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

In D108148#2986602 , @labath wrote:

> I think this would be a good use case for a llvm-style `.def` file. It would 
> provide a central place listing all the known constants, and one could use it 
> to generate the enum definition and both of the conversion functions (by 
> defining a suitable macro).

So basically a new thingie for lldb's TableGen? or is there some generic 
thingie I could reuse for this?


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

https://reviews.llvm.org/D108148

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


[Lldb-commits] [PATCH] D108018: [lldb] [gdb-remote] Support QEnvironment fallback to hex-encoded

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added inline comments.



Comment at: lldb/test/API/tools/lldb-server/main.cpp:332
+  const char *value = getenv(arg.c_str());
+  printf("%s\n", value ? value : "__unset__");
 } else {

labath wrote:
> Printing a quoted this in the case of a null pointer is exactly the opposite 
> of what one would normally expect. It's not a big deal, since we control the 
> inputs, but it may still be better to print `` or something like that 
> instead...
i.e. `s/__unset__//`? I have strong Python background, and double 
underscores are common for special stuff in Python world.


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

https://reviews.llvm.org/D108018

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


[Lldb-commits] [PATCH] D107809: [lldb] Add new commands and tests for getting file perms & exists

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added inline comments.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:661-664
+if (mode != llvm::sys::fs::perms_not_known)
+  response.Printf("F%x", mode);
+else
+  response.Printf("F-1,%x", (int)Status(ec).GetError());

labath wrote:
> Unless I'm mistaken, the test does not actually run this code (as it tests 
> the client bits).
Yes, this is the case. Adding tests for the server is a bit out of scope for 
what I'm working on.


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

https://reviews.llvm.org/D107809

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


[Lldb-commits] [PATCH] D107811: [lldb] [gdb-remote] Add fallbacks for vFile:mode and vFile:exists

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

In D107811#2986430 , @labath wrote:

> It seems useful to note that these are only approximations, as they will fail 
> for unreadable files, even though normally these operations should succeed. 
> However, I think it is the best we can do given the limited set of supported 
> operations (i.e., lack of stat(2) syscall and/or O_PATH argument to open(2)).

Note as in mention in commit message, add a comment, add to documentation 
somewhere?


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

https://reviews.llvm.org/D107811

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


[Lldb-commits] [PATCH] D109004: [lldb] Catch all exceptions when checking if simulator exists

2021-09-07 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment.

What do you think about putting the ` json.loads(sim_devices_str)['devices']` 
into the decorator, so we know that xcodebuild has an SDK *and* the simulator 
has devices available?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109004

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


Re: [Lldb-commits] [lldb] 5f6f33d - [lldb/Plugins] Move member template specialization out of class

2021-09-07 Thread Shafik Yaghmour via lldb-commits
This may actually be a gcc bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 


Not much we can do now but worth knowing in case it is fixed.

> On Sep 3, 2021, at 3:19 PM, Med Ismail Bennani via lldb-commits 
>  wrote:
> 
> 
> Author: Med Ismail Bennani
> Date: 2021-09-03T22:18:55Z
> New Revision: 5f6f33da9ee6cbaef5f10b4a7be34a91d5185b2b
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/5f6f33da9ee6cbaef5f10b4a7be34a91d5185b2b
> DIFF: 
> https://github.com/llvm/llvm-project/commit/5f6f33da9ee6cbaef5f10b4a7be34a91d5185b2b.diff
> 
> LOG: [lldb/Plugins] Move member template specialization out of class
> 
> This patch should fix the build failure that surfaced when build llvm
> with GCC: https://lab.llvm.org/staging/#/builders/16/builds/10450
> 
> GCC complained that I explicitely specialized
> `ScriptedPythonInterface::ExtractValueFromPythonObject` in a
> in non-namespace scope, which is tolerated by Clang.
> 
> To solve this issue, the specialization were declared out of the class
> and implemented in the source file.
> 
> Signed-off-by: Med Ismail Bennani 
> 
> Added: 
> 
> 
> Modified: 
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.cpp
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h
> 
> Removed: 
> 
> 
> 
> 
> diff  --git 
> a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.cpp 
> b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.cpp
> index 097cbbdb6fc7e..a38cb104c0c63 100644
> --- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.cpp
> +++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.cpp
> @@ -35,4 +35,31 @@ 
> ScriptedPythonInterface::GetStatusFromMethod(llvm::StringRef method_name) {
>   return error;
> }
> 
> +template <>
> +Status ScriptedPythonInterface::ExtractValueFromPythonObject(
> +python::PythonObject , Status ) {
> +  if (lldb::SBError *sb_error = reinterpret_cast(
> +  LLDBSWIGPython_CastPyObjectToSBError(p.get(
> +error = m_interpreter.GetStatusFromSBError(*sb_error);
> +  else
> +error.SetErrorString("Couldn't cast lldb::SBError to lldb::Status.");
> +
> +  return error;
> +}
> +
> +template <>
> +lldb::DataExtractorSP
> +ScriptedPythonInterface::ExtractValueFromPythonObject(
> +python::PythonObject , Status ) {
> +  lldb::SBData *sb_data = reinterpret_cast(
> +  LLDBSWIGPython_CastPyObjectToSBData(p.get()));
> +
> +  if (!sb_data) {
> +error.SetErrorString("Couldn't cast lldb::SBError to lldb::Status.");
> +return nullptr;
> +  }
> +
> +  return m_interpreter.GetDataExtractorFromSBData(*sb_data);
> +}
> +
> #endif
> 
> diff  --git 
> a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h 
> b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h
> index 85ec167e1463f..bac4efbe76d8d 100644
> --- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h
> +++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedPythonInterface.h
> @@ -33,33 +33,6 @@ class ScriptedPythonInterface : virtual public 
> ScriptedInterface {
> return p.CreateStructuredObject();
>   }
> 
> -  template <>
> -  Status ExtractValueFromPythonObject(python::PythonObject ,
> -  Status ) {
> -if (lldb::SBError *sb_error = reinterpret_cast(
> -LLDBSWIGPython_CastPyObjectToSBError(p.get(
> -  error = m_interpreter.GetStatusFromSBError(*sb_error);
> -else
> -  error.SetErrorString("Couldn't cast lldb::SBError to lldb::Status.");
> -
> -return error;
> -  }
> -
> -  template <>
> -  lldb::DataExtractorSP
> -  ExtractValueFromPythonObject(python::PythonObject 
> ,
> -  Status ) {
> -lldb::SBData *sb_data = reinterpret_cast(
> -LLDBSWIGPython_CastPyObjectToSBData(p.get()));
> -
> -if (!sb_data) {
> -  error.SetErrorString("Couldn't cast lldb::SBError to lldb::Status.");
> -  return nullptr;
> -}
> -
> -return m_interpreter.GetDataExtractorFromSBData(*sb_data);
> -  }
> -
>   template 
>   T Dispatch(llvm::StringRef method_name, Status , Args... args) {
> using namespace python;
> @@ -149,6 +122,16 @@ class ScriptedPythonInterface : virtual public 
> ScriptedInterface {
>   // The lifetime is managed by the ScriptInterpreter
>   ScriptInterpreterPythonImpl _interpreter;
> };
> +
> +template <>
> +Status ScriptedPythonInterface::ExtractValueFromPythonObject(
> +python::PythonObject , Status );
> +
> +template <>
> +lldb::DataExtractorSP
> +ScriptedPythonInterface::ExtractValueFromPythonObject(
> +python::PythonObject , Status );
> +
> } // namespace lldb_private
> 
> #endif // LLDB_ENABLE_PYTHON
> 
> 
> 
> ___
> lldb-commits 

[Lldb-commits] [lldb] a97efde - [lldb] Add missing newline to stderr output on failed attach

2021-09-07 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2021-09-07T15:49:07Z
New Revision: a97efde54e6ccbd1b56ec1ae1b7899988ac240a0

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

LOG: [lldb] Add missing newline to stderr output on failed attach

Added: 


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

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index d40e5eb631e92..3b8ed86d9f372 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -335,7 +335,7 @@ Status 
GDBRemoteCommunicationServerLLGS::AttachToProcess(lldb::pid_t pid) {
   auto process_or = m_process_factory.Attach(pid, *this, m_mainloop);
   if (!process_or) {
 Status status(process_or.takeError());
-llvm::errs() << llvm::formatv("failed to attach to process {0}: {1}", pid,
+llvm::errs() << llvm::formatv("failed to attach to process {0}: {1}\n", 
pid,
   status);
 return status;
   }



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


[Lldb-commits] [PATCH] D104413: Fixed use of -o and -k in LLDB under Windows when statically compiled with vcruntime.

2021-09-07 Thread Levon Ter-Grigoryan via Phabricator via lldb-commits
PatriosTheGreat marked 2 inline comments as done.
PatriosTheGreat added a comment.

Sorry for delay from my side also


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

https://reviews.llvm.org/D104413

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


[Lldb-commits] [PATCH] D109263: [lldb] Update crashlog.py to accept multiple results from mdfind

2021-09-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4da5a446f818: [lldb] Update crashlog.py to accept multiple 
results from mdfind (authored by JDevlieghere).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109263

Files:
  lldb/examples/python/crashlog.py


Index: lldb/examples/python/crashlog.py
===
--- lldb/examples/python/crashlog.py
+++ lldb/examples/python/crashlog.py
@@ -293,18 +293,24 @@
 return False
 if not self.resolved_path and not os.path.exists(self.path):
 try:
-dsym = subprocess.check_output(
+mdfind_results = subprocess.check_output(
 ["/usr/bin/mdfind",
- "com_apple_xcode_dsym_uuids == 
%s"%uuid_str]).decode("utf-8")[:-1]
-if dsym and os.path.exists(dsym):
-print(('falling back to binary inside "%s"'%dsym))
-self.symfile = dsym
+ "com_apple_xcode_dsym_uuids == %s" % 
uuid_str]).decode("utf-8").splitlines()
+found_matching_slice = False
+for dsym in mdfind_results:
 dwarf_dir = os.path.join(dsym, 
'Contents/Resources/DWARF')
+if not os.path.exists(dwarf_dir):
+# Not a dSYM bundle, probably an Xcode archive.
+continue
+print('falling back to binary inside "%s"' % dsym)
+self.symfile = dsym
 for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if not self.find_matching_slice():
-return False
-break
+   self.path = os.path.join(dwarf_dir, filename)
+   if self.find_matching_slice():
+  found_matching_slice = True
+  break
+if found_matching_slice:
+   break
 except:
 pass
 if (self.resolved_path and os.path.exists(self.resolved_path)) or (


Index: lldb/examples/python/crashlog.py
===
--- lldb/examples/python/crashlog.py
+++ lldb/examples/python/crashlog.py
@@ -293,18 +293,24 @@
 return False
 if not self.resolved_path and not os.path.exists(self.path):
 try:
-dsym = subprocess.check_output(
+mdfind_results = subprocess.check_output(
 ["/usr/bin/mdfind",
- "com_apple_xcode_dsym_uuids == %s"%uuid_str]).decode("utf-8")[:-1]
-if dsym and os.path.exists(dsym):
-print(('falling back to binary inside "%s"'%dsym))
-self.symfile = dsym
+ "com_apple_xcode_dsym_uuids == %s" % uuid_str]).decode("utf-8").splitlines()
+found_matching_slice = False
+for dsym in mdfind_results:
 dwarf_dir = os.path.join(dsym, 'Contents/Resources/DWARF')
+if not os.path.exists(dwarf_dir):
+# Not a dSYM bundle, probably an Xcode archive.
+continue
+print('falling back to binary inside "%s"' % dsym)
+self.symfile = dsym
 for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if not self.find_matching_slice():
-return False
-break
+   self.path = os.path.join(dwarf_dir, filename)
+   if self.find_matching_slice():
+  found_matching_slice = True
+  break
+if found_matching_slice:
+   break
 except:
 pass
 if (self.resolved_path and os.path.exists(self.resolved_path)) or (
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 4da5a44 - [lldb] Update crashlog.py to accept multiple results from mdfind

2021-09-07 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2021-09-07T08:36:58-07:00
New Revision: 4da5a446f818cd979868d830eced9770a886a5b6

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

LOG: [lldb] Update crashlog.py to accept multiple results from mdfind

mdfind can return multiple results, some of which are not even dSYM
bundles, but Xcode archives (.xcrachive).

Currently, we end up concatenating the paths, which is obviously bogus.
This patch not only fixes that, but now also skips paths that don't have
a Contents/Resources/DWARF subdirectory.

rdar://81270312

Differential revision: https://reviews.llvm.org/D109263

Added: 


Modified: 
lldb/examples/python/crashlog.py

Removed: 




diff  --git a/lldb/examples/python/crashlog.py 
b/lldb/examples/python/crashlog.py
index 79b290ceba8a2..e6d88a033a232 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -293,18 +293,24 @@ def locate_module_and_debug_symbols(self):
 return False
 if not self.resolved_path and not os.path.exists(self.path):
 try:
-dsym = subprocess.check_output(
+mdfind_results = subprocess.check_output(
 ["/usr/bin/mdfind",
- "com_apple_xcode_dsym_uuids == 
%s"%uuid_str]).decode("utf-8")[:-1]
-if dsym and os.path.exists(dsym):
-print(('falling back to binary inside "%s"'%dsym))
-self.symfile = dsym
+ "com_apple_xcode_dsym_uuids == %s" % 
uuid_str]).decode("utf-8").splitlines()
+found_matching_slice = False
+for dsym in mdfind_results:
 dwarf_dir = os.path.join(dsym, 
'Contents/Resources/DWARF')
+if not os.path.exists(dwarf_dir):
+# Not a dSYM bundle, probably an Xcode archive.
+continue
+print('falling back to binary inside "%s"' % dsym)
+self.symfile = dsym
 for filename in os.listdir(dwarf_dir):
-self.path = os.path.join(dwarf_dir, filename)
-if not self.find_matching_slice():
-return False
-break
+   self.path = os.path.join(dwarf_dir, filename)
+   if self.find_matching_slice():
+  found_matching_slice = True
+  break
+if found_matching_slice:
+   break
 except:
 pass
 if (self.resolved_path and os.path.exists(self.resolved_path)) or (



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


[Lldb-commits] [PATCH] D106226: [lldb] Improve error message when "lldb attach" fails

2021-09-07 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added a comment.

Maybe I can help a little with the error code approach/add on.

lldb communicates to lldb-server using gdb-remote packets, you can enable 
logging of these with `log enable gdb-remote packets`. If you're running on the 
same machine, lldb will start an lldb-server in gdbserver mode then connect to 
that. Usually if the target is a different machine you'll run lldb-server in 
"platform" mode there and the first thing lldb will ask it to do is spawn 
another lldb-server in gdb-server mode, then lldb will use that. (and of course 
you could manually do that step and connect to it with the `gdb-remote` command 
if you want)

Here's a log of me trying to attach to a process that GDB is already debugging:

  (lldb) process attach -p 833700
  <...>
  b-remote.async>  <  17> send packet: $vAttach;cb8a4#98
  b-remote.async>  <  54> read packet: 
$E01;4f7065726174696f6e206e6f74207065726d6974746564#83
  error: attach failed: Operation not permitted
  Try again as the root user

The first 90% is negotiating capabilities of the server/client. The important 
bit here is at the end.
We're asking to attach to 833700 in hex then we get a reply with an error code 
1 and an error string encoded as hex chars.

The 1 is the ptrace errno and the string is the string description of that 
errno.

Here's me connecting to a process that doesn't exist:

  (lldb) log enable gdb-remote packets
  (lldb) process attach -p 123456
  <...>
  b-remote.async>  <  17> send packet: $vAttach;1e240#32
  b-remote.async>  <  70> read packet: 
$Eff;43616e6e6f74206765742070726f6365737320617263686974656374757265#d4
  error: attach failed: Cannot get process architecture
  Try again as the root user

Here you could argue the "Try again" doesn't help. Also us not just saying "no 
such process" doesn't help but you get the idea.

> The proper way to check this seems to be checking the errno after we call 
> ptrace and then propagate the error all the way back to lldb from lldb-server.

So in fact we *are* doing this but there are some situations (I just found the 
one above) where either we never get to calling ptrace or the errno is 
overwritten by some other call we make.
(0xff == -1 which I think is `inconvertible_error_code` which is what you use 
when you just want to make a generic error with some string)

What you could do is just look for the "Operation not permitted" case, and only 
show the message then. By the time you get the status in the lldb it won't have 
`eErrorTypePosix` but if you already know in that specific scenario that it 
will be, you can just compare to the errno code.
(be wary of including linux specific headers though, there's probably an llvm 
header you could use to make it generic)

There might be path where we `return 1` for non ptrace reasons but it would 
narrow it down.




Comment at: lldb/source/Target/Target.cpp:3121
 
+const char *fetchPtracePolicyIfApplicable(lldb::PlatformSP platform_sp) {
+  FileSpec filespec =

Make this function static since it's only used in this file.



Comment at: lldb/source/Target/Target.cpp:3143
+if (ptrace_scope != '0') {
+  status_message =
+  "Note that attaching might have failed due to the ptrace_scope "

I get warnings like this with clang-12:
```
/home/david.spickett/llvm-project/lldb/source/Target/Target.cpp:3144:11: 
warning: ISO C++11 does not allow conversion from string literal to 'char *' 
[-Wwritable-strings]
  "Note that attaching might have failed due to the ptrace_scope "
  ^
```

I think just making status_message `const char*` will fix that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106226

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


[Lldb-commits] [PATCH] D109231: [lldb] Improve error handling around GetRngListData()

2021-09-07 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added inline comments.
Herald added a subscriber: JDevlieghere.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp:522
+entry->getContribution(llvm::DW_SECT_RNGLISTS)) {
+  Offset = contribution->Offset;
   return DWARFDataExtractor(data, contribution->Offset,

If I am reading this correctly, it looks like this will only be set on the 
non-error case which will leave `contribution_off` in the caller uninitialized 
in the cases you care about logging.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109231

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


[Lldb-commits] [PATCH] D107701: [lldb] [test] Skip Expr/nodefaultlib.cpp test if LD_PRELOAD Is used

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny added a comment.

In D107701#2986378 , @labath wrote:

> What does the preloaded library do ? Is it actually necessary for the (other) 
> tests to run? I'm wondering if we shouldn't strip the variable from the 
> environment instead...

It detects accesses to files outside the build tree. Stripping the variable 
won't help because it will readd itself on fork.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107701

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


[Lldb-commits] [PATCH] D108548: [lldb] Support "eflags" register name in generic reg fallback

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

seems reasonable


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

https://reviews.llvm.org/D108548

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


[Lldb-commits] [PATCH] D108148: [lldb] [gdb-remote] Use standardized GDB errno values

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I think this would be a good use case for a llvm-style `.def` file. It would 
provide a central place listing all the known constants, and one could use it 
to generate the enum definition and both of the conversion functions (by 
defining a suitable macro).


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

https://reviews.llvm.org/D108148

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


[Lldb-commits] [PATCH] D108018: [lldb] [gdb-remote] Support QEnvironment fallback to hex-encoded

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

cool




Comment at: lldb/test/API/tools/lldb-server/main.cpp:332
+  const char *value = getenv(arg.c_str());
+  printf("%s\n", value ? value : "__unset__");
 } else {

Printing a quoted this in the case of a null pointer is exactly the opposite of 
what one would normally expect. It's not a big deal, since we control the 
inputs, but it may still be better to print `` or something like that 
instead...


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

https://reviews.llvm.org/D108018

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


[Lldb-commits] [PATCH] D107931: [lldb] [gdb-remote] Implement vRun packet

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

I like this. I am saddened to see that neither method supports setting a "fake" 
argv[0], but that's not a problem of this patch,,,


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

https://reviews.llvm.org/D107931

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


[Lldb-commits] [PATCH] D107840: [lldb] [gdb-server] Implement the vFile:fstat packet

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:776
+
+  std::array data;
+  DataEncoder encoder{data.data(), data.size(), lldb::eByteOrderBig,

consider:
```
struct GdbStat {
  llvm::support::ubig32_t st_dev;
  llvm::support::ubig32_t st_ino;
  ...
};

...

translate(gdb_stats.st_dev, file_stats.st_dev, 0); // I'm not sure that this 
clamping is really necessary.
...
```

Seems like it could be nicer, particularly as the vFile_Stat function will need 
to do the same thing...


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

https://reviews.llvm.org/D107840

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


[Lldb-commits] [PATCH] D107821: [lldb] [gdb-server] Add tests for more vFile packets

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Instead of the tempfile thingies I'd probably just use fixed files names in the 
build directory -- it's specific to a single test, automatically cleaned on 
each run and it's where all of our other "temporary" files end up


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

https://reviews.llvm.org/D107821

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


[Lldb-commits] [PATCH] D107811: [lldb] [gdb-remote] Add fallbacks for vFile:mode and vFile:exists

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

It seems useful to note that these are only approximations, as they will fail 
for unreadable files, even though normally these operations should succeed. 
However, I think it is the best we can do given the limited set of supported 
operations (i.e., lack of stat(2) syscall and/or O_PATH argument to open(2)).


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

https://reviews.llvm.org/D107811

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


[Lldb-commits] [PATCH] D107809: [lldb] Add new commands and tests for getting file perms & exists

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I was thinking this would be more useful in the SB form (and indeed we have 
SBPlatform::GetFilePermissions) already, though I suppose making it available 
through the command line does not hurt either..




Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:661-664
+if (mode != llvm::sys::fs::perms_not_known)
+  response.Printf("F%x", mode);
+else
+  response.Printf("F-1,%x", (int)Status(ec).GetError());

Unless I'm mistaken, the test does not actually run this code (as it tests the 
client bits).



Comment at: 
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py:142-150
+
+self.server.responder = Responder()
+
+try:
+self.runCmd("platform select remote-gdb-server")
+self.runCmd("platform connect connect://" +
+self.server.get_connect_address())

Maybe it's time to create a separate test class which would perform this in the 
setUp/tearDown methods?


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

https://reviews.llvm.org/D107809

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


[Lldb-commits] [PATCH] D108739: [LLDB] AArch64 SVE restore SVE registers after expression

2021-09-07 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added a comment.

Hopefully in the future we can get some kind of smarter container for this 
register data in future but this looks good for now with a few extra comments 
for the logic of it. (and so we know where to make changes later)


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

https://reviews.llvm.org/D108739

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


[Lldb-commits] [PATCH] D108739: [LLDB] AArch64 SVE restore SVE registers after expression

2021-09-07 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:451
 
 Status NativeRegisterContextLinux_arm64::ReadAllRegisterValues(
 lldb::DataBufferSP _sp) {

omjavaid wrote:
> DavidSpickett wrote:
> > Do we need PAC registers here too? (and in write values)
> We implement PAC as read only so we dont wanna save them either.
Cool, please add a comment in both places to that effect.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:543
+  bool contains_sve_reg_data =
+  (data_sp->GetByteSize() > (reg_data_min_size + GetSVEHeaderSize()));
+

omjavaid wrote:
> omjavaid wrote:
> > DavidSpickett wrote:
> > > I'm a bit dubious about these size checks as a way to tell if things are 
> > > present, should this one have `GetRegisterInfo().IsSVEEnabled()` also?
> > > 
> > > I'm thinking what if PAC plus MTE plus  adds enough 
> > > registers to exceed the size of the SVE header, but the process doesn't 
> > > in fact have SVE.
> > > 
> > > You could do the size checks in terms of bytes left to read from the 
> > > data_sp, that might simplify it some too.
> > We are not sure if SVE was enabled or not when we restore. So size checks 
> > is the only way we can figure out if a register checkpoint was created when 
> > SVE was enabled. This works for now but if we have to stack another 
> > register set which is greater than size of SVE header then we will have to 
> > put information about enabled register sets inside the checkpoint maybe in 
> > a bitmap describing which register set is enabled and look for those at 
> > predefined offsets. I thought this wasn't needed for now and will over 
> > complicate already complicated variable sized checkpoint.
> Just to shed more light on this if SVE is note enabled we just have GPR + FPR 
> + MTE predictable from size. As MTE is just 8 bytes we can be sure if 
> checkpoint has data beyond FPR which is greater than GPR + FPR + SVE_HEADER 
> that means we atleast have SVE header present. Then we check if its a valid 
> header using !sve_vl_valid(m_sve_header.vl)) check and write it to configure 
> SVE registers size before writing actual registers.
> If we dont have register data beyond greater than GPR+FPR+MTE then we can 
> safely say there is no SVE present at all.
Right, of course because PAC is read only we only care about MTE and we know 
that the SVE header is > 8 bytes. Sounds good to me.

Another comment with that explanation please.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:587
 
+  if (GetRegisterInfo().IsMTEEnabled() && data_sp->GetByteSize() > 
reg_data_min_size) {
+::memcpy(GetMTEControl(), src, GetMTEControlSize());

omjavaid wrote:
> DavidSpickett wrote:
> > This could go wrong if data_sp contains GPR+FPR+SVE data and somehow the 
> > register info thinks MTE is enabled. Not sure if that's a realistic thing 
> > to handle here.
> > 
> > If you did this in terms of bytes left you could check that there are bytes 
> > left to read from data_sp by this point.
> > 
> > (it's a shame the data_sp we get isn't some richer structure we could ask 
> > for offsets into)
> FPR and SVE cannot live together when SVE is present FPR registers are 
> replicated by first 128bits of SVE Z registers so we will either save FPR or 
> SVE data not both.
> 
> reg_data_min_size can either be FPR + GPR or SVE + GPR thats why we calculate 
> it again when data has SVE.
Got it.


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

https://reviews.llvm.org/D108739

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


[Lldb-commits] [PATCH] D107701: [lldb] [test] Skip Expr/nodefaultlib.cpp test if LD_PRELOAD Is used

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

What does the preloaded library do ? Is it actually necessary for the (other) 
tests to run? I'm wondering if we shouldn't strip the variable from the 
environment instead...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107701

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


[Lldb-commits] [PATCH] D109345: MemoryBuffer: Migrate to Expected/llvm::Error from ErrorOr/std::error_code

2021-09-07 Thread Thomas Preud'homme via Phabricator via lldb-commits
thopre added a comment.

Is there no way to split this patch further? It's going to be hard finding 
someone who can review something so big. If there's no way to split it in 
incremental changes, you could perhaps split per subsystem only for review and 
refer to this diff for CI as well as when landing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109345

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


[Lldb-commits] [PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

2021-09-07 Thread Mark de Wever via Phabricator via lldb-commits
Mordante added a comment.

Since @ldionne approved this patch it's good to land. If you don't have commit 
access, can you provide "Your name" , then somebody can 
commit the change for you.


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

https://reviews.llvm.org/D107717

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


[Lldb-commits] [PATCH] D107717: [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project

2021-09-07 Thread Alf via Phabricator via lldb-commits
gAlfonso-bit updated this revision to Diff 370957.
gAlfonso-bit added a comment.

Rebase to Main @ldionne


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

https://reviews.llvm.org/D107717

Files:
  clang/CMakeLists.txt
  clang/lib/Basic/CMakeLists.txt
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  flang/CMakeLists.txt
  libcxx/cmake/Modules/HandleOutOfTreeLLVM.cmake
  libunwind/CMakeLists.txt
  lld/CMakeLists.txt
  lld/Common/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake
  lldb/source/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/include/llvm/Support/CMakeLists.txt
  runtimes/CMakeLists.txt

Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -65,7 +65,7 @@
 
 # This variable makes sure that e.g. llvm-lit is found.
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR})
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 
 # This variable is used by individual runtimes to locate LLVM files.
 set(LLVM_PATH ${LLVM_BUILD_MAIN_SRC_DIR})
Index: llvm/include/llvm/Support/CMakeLists.txt
===
--- llvm/include/llvm/Support/CMakeLists.txt
+++ llvm/include/llvm/Support/CMakeLists.txt
@@ -3,7 +3,7 @@
 # The VC revision include that we want to generate.
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSRevision.h")
 
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(LLVM_APPEND_VC_REV)
   set(llvm_source_dir ${LLVM_MAIN_SRC_DIR})
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -295,8 +295,8 @@
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/include ) # --includedir
 set(LLVM_BINARY_DIR   ${CMAKE_CURRENT_BINARY_DIR}  ) # --prefix
 
-# Note: LLVM_CMAKE_PATH does not include generated files
-set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
+# Note: LLVM_CMAKE_DIR does not include generated files
+set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
 set(LLVM_EXAMPLES_BINARY_DIR ${LLVM_BINARY_DIR}/examples)
 set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/include)
 
Index: lldb/source/CMakeLists.txt
===
--- lldb/source/CMakeLists.txt
+++ lldb/source/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLDB_SOURCE_DIR}" lldb_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lldb_vc AND LLVM_APPEND_VC_REV)
   set(lldb_source_dir ${LLDB_SOURCE_DIR})
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -3,8 +3,8 @@
 find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang NO_CMAKE_FIND_ROOT_PATH)
 
-# We set LLVM_CMAKE_PATH so that GetSVN.cmake is found correctly when building SVNVersion.inc
-set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
+# We set LLVM_CMAKE_DIR so that GetSVN.cmake is found correctly when building SVNVersion.inc
+set(LLVM_CMAKE_DIR ${LLVM_CMAKE_DIR} CACHE PATH "Path to LLVM CMake modules")
 
 set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
 set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
Index: lld/Common/CMakeLists.txt
===
--- lld/Common/CMakeLists.txt
+++ lld/Common/CMakeLists.txt
@@ -8,7 +8,7 @@
 find_first_existing_vc_file("${LLD_SOURCE_DIR}" lld_vc)
 
 set(version_inc "${CMAKE_CURRENT_BINARY_DIR}/VCSVersion.inc")
-set(generate_vcs_version_script "${LLVM_CMAKE_PATH}/GenerateVersionFromVCS.cmake")
+set(generate_vcs_version_script "${LLVM_CMAKE_DIR}/GenerateVersionFromVCS.cmake")
 
 if(lld_vc AND LLVM_APPEND_VC_REV)
   set(lld_source_dir ${LLD_SOURCE_DIR})
Index: lld/CMakeLists.txt
===
--- lld/CMakeLists.txt
+++ lld/CMakeLists.txt
@@ -27,7 +27,7 @@
 
   list(GET LLVM_CONFIG_OUTPUT 0 OBJ_ROOT)
   list(GET LLVM_CONFIG_OUTPUT 1 MAIN_INCLUDE_DIR)
-  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_PATH)
+  list(GET LLVM_CONFIG_OUTPUT 2 LLVM_CMAKE_DIR)
   list(GET LLVM_CONFIG_OUTPUT 3 MAIN_SRC_DIR)
 
   set(LLVM_OBJ_ROOT ${OBJ_ROOT} CACHE PATH "path to LLVM build tree")
@@ -35,14 +35,14 @@
   set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} 

[Lldb-commits] [PATCH] D109326: [lldb] [Process/FreeBSD] Support SaveCore() using PT_COREDUMP

2021-09-07 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski accepted this revision.
krytarowski added a comment.
This revision is now accepted and ready to land.

Looks good


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

https://reviews.llvm.org/D109326

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


[Lldb-commits] [PATCH] D108061: [lldb] Add support for shared library load when executable called through ld.

2021-09-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:571-579
+
+  // ld.so saves empty file name for the executable file in the link map.
+  // When argv[0] is ld.so, we need to be update executable path.
+  if (file_path.empty()) {
+MemoryRegionInfo region;
+Status region_status =
+m_process->GetMemoryRegionInfo(entry.dyn_addr, region);

Setting this here defeats all the `if (!SOEntryIsMainExecutable(entry))` checks 
in this code, for the "normal" case of running the executable directly. I'm 
guessing that will result in multiple modules being added for the main 
executable.

I think it would be better to remove this logic from here (it seems a bit too 
fancy for a function called `ReadSOEntryFromMemory`), and then teach the higher 
levels that they ought to treat "" specially (in some circumstances).



Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp:345-350
+  if (NameMatches(m_process->GetTarget()
+  .GetExecutableModulePointer()
+  ->GetFileSpec()
+  .GetFilename()
+  .GetCString(),
+  NameMatch::StartsWith, "ld-")) {

This check is unnecessary. A statically linked executable can still contain the 
dynamic linker structures (even though it does not have an elf interpreter), if 
it contains runtime calls to dlopen. In this case the main executable will 
contain _dl_debug_state et al. through the inclusion of libdl.a, and omitting 
this check should make that case work too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108061

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


[Lldb-commits] [PATCH] D108078: [lldb] Support gdbserver signals

2021-09-07 Thread Michał Górny via Phabricator via lldb-commits
mgorny updated this revision to Diff 371011.
mgorny marked an inline comment as done.
mgorny added a comment.

Rebased.


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

https://reviews.llvm.org/D108078

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/source/Plugins/Process/Utility/GDBRemoteSignals.cpp
  lldb/source/Plugins/Process/Utility/GDBRemoteSignals.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
  lldb/tools/debugserver/source/RNBRemote.cpp

Index: lldb/tools/debugserver/source/RNBRemote.cpp
===
--- lldb/tools/debugserver/source/RNBRemote.cpp
+++ lldb/tools/debugserver/source/RNBRemote.cpp
@@ -3462,7 +3462,8 @@
   uint32_t max_packet_size = 128 * 1024; // 128KBytes is a reasonable max packet
  // size--debugger can always use less
   char buf[256];
-  snprintf(buf, sizeof(buf), "qXfer:features:read+;PacketSize=%x;qEcho+",
+  snprintf(buf, sizeof(buf),
+   "qXfer:features:read+;PacketSize=%x;qEcho+;native-signals+",
max_packet_size);
 
   bool enable_compression = false;
Index: lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py
@@ -351,3 +351,49 @@
   "QEnvironmentHexEncoded:4e45454453454e43343d6623726f62",
   "QEnvironmentHexEncoded:455155414c533d666f6f3d626172",
 ])
+
+def test_signal_gdb(self):
+class MyResponder(MockGDBServerResponder):
+def qSupported(self, client_supported):
+return "PacketSize=3fff;QStartNoAckMode+"
+
+def haltReason(self):
+return "S0a"
+
+def cont(self):
+return self.haltReason()
+
+self.server.responder = MyResponder()
+
+target = self.createTarget("a.yaml")
+process = self.connect(target)
+
+self.assertEqual(process.threads[0].GetStopReason(),
+ lldb.eStopReasonSignal)
+self.assertEqual(process.threads[0].GetStopDescription(100),
+ 'signal SIGBUS')
+
+def test_signal_lldb(self):
+class MyResponder(MockGDBServerResponder):
+def qSupported(self, client_supported):
+return "PacketSize=3fff;QStartNoAckMode+;native-signals+"
+
+def qHostInfo(self):
+return "triple:61726d76372d756e6b6e6f776e2d6c696e75782d676e75;"
+
+def haltReason(self):
+return "S0a"
+
+def cont(self):
+return self.haltReason()
+
+self.server.responder = MyResponder()
+
+target = self.createTarget("a.yaml")
+process = self.connect(target)
+
+self.assertEqual(process.threads[0].GetStopReason(),
+ lldb.eStopReasonSignal)
+# NB: this may need adjusting per current platform
+self.assertEqual(process.threads[0].GetStopDescription(100),
+ 'signal SIGUSR1')
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -720,14 +720,6 @@
 __FUNCTION__, GetID(),
 GetTarget().GetArchitecture().GetTriple().getTriple().c_str());
 
-  if (error.Success()) {
-PlatformSP platform_sp = GetTarget().GetPlatform();
-if (platform_sp && platform_sp->IsConnected())
-  SetUnixSignals(platform_sp->GetUnixSignals());
-else
-  SetUnixSignals(UnixSignals::Create(GetTarget().GetArchitecture()));
-  }
-
   return error;
 }
 
@@ -1112,6 +1104,18 @@
   if (StructuredData::Array *supported_packets =
   m_gdb_comm.GetSupportedStructuredDataPlugins())
 MapSupportedStructuredDataPlugins(*supported_packets);
+
+  // If connected to LLDB ("native-signals+"), use signal defs for
+  // the remote platform.  If connected to GDB, just use the standard set.
+  if (!m_gdb_comm.UsesNativeSignals()) {
+SetUnixSignals(std::make_shared());
+  } else {
+PlatformSP platform_sp = GetTarget().GetPlatform();
+if (platform_sp && platform_sp->IsConnected())
+  SetUnixSignals(platform_sp->GetUnixSignals());
+else
+  SetUnixSignals(UnixSignals::Create(GetTarget().GetArchitecture()));
+  }
 }
 
 void 

[Lldb-commits] [PATCH] D104413: Fixed use of -o and -k in LLDB under Windows when statically compiled with vcruntime.

2021-09-07 Thread Levon Ter-Grigoryan via Phabricator via lldb-commits
PatriosTheGreat updated this revision to Diff 371002.

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

https://reviews.llvm.org/D104413

Files:
  lldb/bindings/interface/SBDebugger.i
  lldb/include/lldb/API/SBDebugger.h
  lldb/include/lldb/Core/Debugger.h
  lldb/source/API/SBDebugger.cpp
  lldb/source/Core/Debugger.cpp
  lldb/test/API/python_api/default-constructor/sb_debugger.py
  lldb/test/API/python_api/file_handle/TestFileHandle.py
  lldb/tools/driver/Driver.cpp

Index: lldb/tools/driver/Driver.cpp
===
--- lldb/tools/driver/Driver.cpp
+++ lldb/tools/driver/Driver.cpp
@@ -23,7 +23,6 @@
 #include "llvm/Support/Format.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/Path.h"
-#include "llvm/Support/Process.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/WithColor.h"
 #include "llvm/Support/raw_ostream.h"
@@ -43,14 +42,6 @@
 #include 
 #include 
 
-// Includes for pipe()
-#if defined(_WIN32)
-#include 
-#include 
-#else
-#include 
-#endif
-
 #if !defined(__APPLE__)
 #include "llvm/Support/DataTypes.h"
 #endif
@@ -401,60 +392,6 @@
   return error;
 }
 
-static inline int OpenPipe(int fds[2], std::size_t size) {
-#ifdef _WIN32
-  return _pipe(fds, size, O_BINARY);
-#else
-  (void)size;
-  return pipe(fds);
-#endif
-}
-
-static ::FILE *PrepareCommandsForSourcing(const char *commands_data,
-  size_t commands_size) {
-  enum PIPES { READ, WRITE }; // Indexes for the read and write fds
-  int fds[2] = {-1, -1};
-
-  if (OpenPipe(fds, commands_size) != 0) {
-WithColor::error()
-<< "can't create pipe file descriptors for LLDB commands\n";
-return nullptr;
-  }
-
-  ssize_t nrwr = write(fds[WRITE], commands_data, commands_size);
-  if (size_t(nrwr) != commands_size) {
-WithColor::error()
-<< format(
-   "write(%i, %p, %" PRIu64
-   ") failed (errno = %i) when trying to open LLDB commands pipe",
-   fds[WRITE], static_cast(commands_data),
-   static_cast(commands_size), errno)
-<< '\n';
-llvm::sys::Process::SafelyCloseFileDescriptor(fds[READ]);
-llvm::sys::Process::SafelyCloseFileDescriptor(fds[WRITE]);
-return nullptr;
-  }
-
-  // Close the write end of the pipe, so that the command interpreter will exit
-  // when it consumes all the data.
-  llvm::sys::Process::SafelyCloseFileDescriptor(fds[WRITE]);
-
-  // Open the read file descriptor as a FILE * that we can return as an input
-  // handle.
-  ::FILE *commands_file = fdopen(fds[READ], "rb");
-  if (commands_file == nullptr) {
-WithColor::error() << format("fdopen(%i, \"rb\") failed (errno = %i) "
- "when trying to open LLDB commands pipe",
- fds[READ], errno)
-   << '\n';
-llvm::sys::Process::SafelyCloseFileDescriptor(fds[READ]);
-return nullptr;
-  }
-
-  // 'commands_file' now owns the read descriptor.
-  return commands_file;
-}
-
 std::string EscapeString(std::string arg) {
   std::string::size_type pos = 0;
   while ((pos = arg.find_first_of("\"\\", pos)) != std::string::npos) {
@@ -584,21 +521,15 @@
   // Check if we have any data in the commands stream, and if so, save it to a
   // temp file
   // so we can then run the command interpreter using the file contents.
-  const char *commands_data = commands_stream.GetData();
-  const size_t commands_size = commands_stream.GetSize();
-
   bool go_interactive = true;
-  if ((commands_data != nullptr) && (commands_size != 0u)) {
-FILE *commands_file =
-PrepareCommandsForSourcing(commands_data, commands_size);
-
-if (commands_file == nullptr) {
-  // We should have already printed an error in PrepareCommandsForSourcing.
+  if ((commands_stream.GetData() != nullptr) &&
+  (commands_stream.GetSize() != 0u)) {
+SBError error = m_debugger.SetInputString(commands_stream.GetData());
+if (error.Fail()) {
+  WithColor::error() << error.GetCString() << '\n';
   return 1;
 }
 
-m_debugger.SetInputFileHandle(commands_file, true);
-
 // Set the debugger into Sync mode when running the command file. Otherwise
 // command files that run the target won't run in a sensible way.
 bool old_async = m_debugger.GetAsync();
@@ -630,12 +561,9 @@
   SBStream crash_commands_stream;
   WriteCommandsForSourcing(eCommandPlacementAfterCrash,
crash_commands_stream);
-  const char *crash_commands_data = crash_commands_stream.GetData();
-  const size_t crash_commands_size = crash_commands_stream.GetSize();
-  commands_file =
-  PrepareCommandsForSourcing(crash_commands_data, crash_commands_size);
-  if (commands_file != nullptr) {
-m_debugger.SetInputFileHandle(commands_file, true);
+  SBError error =
+  m_debugger.SetInputString(crash_commands_stream.GetData());