[Lldb-commits] [PATCH] D95710: [lldb/Commands] Add command options for ScriptedProcess to ProcessLaunch

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

Add getters and setters for scripted process managing class name and dictionary 
in `SBLaunchInfo`.


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

https://reviews.llvm.org/D95710

Files:
  lldb/bindings/interface/SBLaunchInfo.i
  lldb/include/lldb/API/SBLaunchInfo.h
  lldb/include/lldb/API/SBStream.h
  lldb/include/lldb/API/SBStructuredData.h
  lldb/include/lldb/Host/ProcessLaunchInfo.h
  lldb/source/API/SBLaunchInfo.cpp
  lldb/source/API/SBTarget.cpp
  lldb/source/Commands/CommandObjectPlatform.cpp
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/CommandOptionsProcessLaunch.cpp
  lldb/source/Commands/CommandOptionsProcessLaunch.h
  lldb/source/Host/common/ProcessLaunchInfo.cpp

Index: lldb/source/Host/common/ProcessLaunchInfo.cpp
===
--- lldb/source/Host/common/ProcessLaunchInfo.cpp
+++ lldb/source/Host/common/ProcessLaunchInfo.cpp
@@ -32,7 +32,8 @@
 : ProcessInfo(), m_working_dir(), m_plugin_name(), m_flags(0),
   m_file_actions(), m_pty(new PseudoTerminal), m_resume_count(0),
   m_monitor_callback(nullptr), m_monitor_callback_baton(nullptr),
-  m_monitor_signals(false), m_listener_sp(), m_hijack_listener_sp() {}
+  m_monitor_signals(false), m_listener_sp(), m_hijack_listener_sp(),
+  m_scripted_process_class_name(), m_scripted_process_dictionary_sp() {}
 
 ProcessLaunchInfo::ProcessLaunchInfo(const FileSpec &stdin_file_spec,
  const FileSpec &stdout_file_spec,
@@ -42,7 +43,8 @@
 : ProcessInfo(), m_working_dir(), m_plugin_name(), m_flags(launch_flags),
   m_file_actions(), m_pty(new PseudoTerminal), m_resume_count(0),
   m_monitor_callback(nullptr), m_monitor_callback_baton(nullptr),
-  m_monitor_signals(false), m_listener_sp(), m_hijack_listener_sp() {
+  m_monitor_signals(false), m_listener_sp(), m_hijack_listener_sp(),
+  m_scripted_process_class_name(), m_scripted_process_dictionary_sp() {
   if (stdin_file_spec) {
 FileAction file_action;
 const bool read = true;
@@ -171,6 +173,8 @@
   m_resume_count = 0;
   m_listener_sp.reset();
   m_hijack_listener_sp.reset();
+  m_scripted_process_class_name.clear();
+  m_scripted_process_dictionary_sp.reset();
 }
 
 void ProcessLaunchInfo::SetMonitorProcessCallback(
Index: lldb/source/Commands/CommandOptionsProcessLaunch.h
===
--- lldb/source/Commands/CommandOptionsProcessLaunch.h
+++ lldb/source/Commands/CommandOptionsProcessLaunch.h
@@ -1,4 +1,4 @@
-//===-- CommandOptionsProcessLaunch.h -===//
+//===-- CommandOptionsProcessLaunch.h ---*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -16,9 +16,9 @@
 
 // CommandOptionsProcessLaunch
 
-class CommandOptionsProcessLaunch : public lldb_private::Options {
+class CommandOptionsProcessLaunch : public lldb_private::OptionGroup {
 public:
-  CommandOptionsProcessLaunch() : lldb_private::Options() {
+  CommandOptionsProcessLaunch() : lldb_private::OptionGroup() {
 // Keep default values of all options in one place: OptionParsingStarting
 // ()
 OptionParsingStarting(nullptr);
Index: lldb/source/Commands/CommandOptionsProcessLaunch.cpp
===
--- lldb/source/Commands/CommandOptionsProcessLaunch.cpp
+++ lldb/source/Commands/CommandOptionsProcessLaunch.cpp
@@ -30,7 +30,7 @@
 uint32_t option_idx, llvm::StringRef option_arg,
 ExecutionContext *execution_context) {
   Status error;
-  const int short_option = m_getopt_table[option_idx].val;
+  const int short_option = g_process_launch_options[option_idx].short_option;
 
   switch (short_option) {
   case 's': // Stop at program entry point
Index: lldb/source/Commands/CommandObjectProcess.cpp
===
--- lldb/source/Commands/CommandObjectProcess.cpp
+++ lldb/source/Commands/CommandObjectProcess.cpp
@@ -17,6 +17,7 @@
 #include "lldb/Interpreter/CommandInterpreter.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
 #include "lldb/Interpreter/OptionArgParser.h"
+#include "lldb/Interpreter/OptionGroupPythonClassWithDict.h"
 #include "lldb/Interpreter/Options.h"
 #include "lldb/Target/Platform.h"
 #include "lldb/Target/Process.h"
@@ -108,7 +109,12 @@
 interpreter, "process launch",
 "Launch the executable in the debugger.", nullptr,
 eCommandRequiresTarget, "restart"),
-m_options() {
+m_options(), m_class_options("scripted process"), m_all_options() {
+m_all_options.Append(&m_options);
+m_all_options.Append(&m_class_options, LLDB_OPT_SET_1 | LLDB

[Lldb-commits] [PATCH] D95602: [lldb][AArch64] Add MTE memory tag reading for lldb

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

> This patch also looks quite good. Some minor nits inline and also move gdb* 
> changes into a single patch with both client and server side code.

Cool, I wasn't sure how to split while keeping it readable but that sounds good.




Comment at: lldb/include/lldb/Target/Process.h:1701
+  /// handler that can be used to maniupulate those memory tags.
+  /// Tags present in the addresses given are ignored.
+  ///

omjavaid wrote:
> Can you explain this line a bit? What i understood we dont include start and 
> end address in tag range. right?
Does the description of `end_addr` answer your question?

GetMemoryTagHandler(10, 21) would check a range from 10-20.



Comment at: lldb/include/lldb/Target/Process.h:2773
+  virtual llvm::Expected>
+  DoReadMemoryTags(lldb::addr_t addr, size_t len, int32_t type) {
+return llvm::createStringError(llvm::inconvertibleErrorCode(),

omjavaid wrote:
> I guess if there are no restrictions by specs then we should rethink use of 
> int32_t for type may be uint32_t if possible.
GDB is using a signed int, though we don't have need for negative numbers at 
this time. I'll cite the GDB design for this.

We could say well, for the moment it might as well be unsigned but I don't want 
to introduce a situation where in future we mix client/servers and lldb falls 
over on a "-".



Comment at: lldb/packages/Python/lldbsuite/test/lldbtest.py:1272
 
-def isAArch64SVE(self):
+def hasLinuxCPUInfoFeature(self, feature):
 triple = self.dbg.GetSelectedPlatform().GetTriple()

omjavaid wrote:
> omjavaid wrote:
> > This change look good and can be committed outside this patch.
> This change looks fine commit it separately.
Yeah your registers patch does the same thing so depending on timing I might 
end up using that.



Comment at: lldb/source/Target/Process.cpp:6031
+  const MemoryTagHandler *tag_handler =
+  arch ? arch->GetMemoryTagHandler() : nullptr;
+  if (!arch || !tag_handler) {

omjavaid wrote:
> 'arch' may be nullptr so call to GetMemoryTagHandler is not safe.
Sure, that's why I check it first with the `arch ?`. Happy to refactor if it 
could be clearer.

I should say that some of this boilerplate looking for the tag handler is 
subject to change once I've written more commands. It's repetitive now but 
later I should be able to refactor with the context of how all the commands use 
it.



Comment at: lldb/source/Target/Process.cpp:6058
+  MemoryRegionInfo::RangeType tag_range(untagged_addr, len);
+  tag_range = tag_handler->AlignToGranules(tag_range);
+

omjavaid wrote:
> Can there be multiple 'granules' defined for an implementation ? if not this 
> func may be renamed (AlignToGranule) to reflect that 
MTE only has one granule size, Sparc ADI uses cache lines so I assume theirs is 
just the cache line size.

If I read "align to granule" singular I think it's align to a single granule, 
probably up. Since this aligns up and down granules plural made more sense to 
me.

That said, it's never going to shrink the range, so ExpandToGranule would be 
more descriptive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95602

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


[Lldb-commits] [PATCH] D95711: [lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 323916.
mib marked an inline comment as done.
mib edited the summary of this revision.
mib added a comment.

- Fixed unittest's `liblldb` linking issue by unwrapping the `SBError` type 
into a  `lldb_private::Status` in the ScriptInterpreter.
- Renamed ScriptInterpreter `SBData` -> `lldb_private::DataExtractor` helper 
function to make it more understandable.
- Added interface endpoints to fetch MemoryRegions and Threads lazily (as 
@labath suggested in D95712 ).
- Refactored the `ScriptedProcessInterface` by fixing typos, adding missing 
arguments, removing useless methods.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95711

Files:
  lldb/bindings/python/python-wrapper.swig
  lldb/include/lldb/API/SBData.h
  lldb/include/lldb/API/SBError.h
  lldb/include/lldb/API/SBThreadPlan.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/include/lldb/Interpreter/ScriptedProcessInterface.h
  lldb/include/lldb/lldb-forward.h
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Interpreter/ScriptedProcessInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  
lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
  lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Index: lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
===
--- lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -12,6 +12,7 @@
 
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h"
+#include "lldb/API/SBError.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
 
@@ -153,6 +154,14 @@
   return 0;
 }
 
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBData(void *data) {
+  return nullptr;
+}
+
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBError(void *data) {
+  return nullptr;
+}
+
 extern "C" void *LLDBSWIGPython_CastPyObjectToSBValue(void *data) {
   return nullptr;
 }
@@ -207,6 +216,13 @@
   return nullptr;
 }
 
+extern "C" void *LLDBSwigPythonCreateScriptedProcess(
+const char *python_class_name, const char *session_dictionary_name,
+const lldb::TargetSP &target_sp, StructuredDataImpl *args_impl,
+std::string &error_string) {
+  return nullptr;
+}
+
 extern "C" void *
 LLDBSWIGPython_CreateFrameRecognizer(const char *python_class_name,
  const char *session_dictionary_name) {
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
===
--- /dev/null
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
@@ -0,0 +1,69 @@
+//===-- ScriptedProcessPythonInterface.h *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+#define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+
+#include "lldb/Host/Config.h"
+
+#if LLDB_ENABLE_PYTHON
+
+#include "lldb/Interpreter/ScriptedProcessInterface.h"
+
+namespace lldb_private {
+class ScriptInterpreterPythonImpl;
+class ScriptedProcessPythonInterface : public ScriptedProcessInterface {
+public:
+  ScriptedProcessPythonInterface(ScriptInterpreterPythonImpl &interpreter)
+  : ScriptedProcessInterface(), m_interpreter(interpreter) {}
+
+  StructuredData::GenericSP
+  CreatePluginObject(const llvm::StringRef class_name, lldb::TargetSP target_sp,
+ StructuredData::DictionarySP args_sp) override;
+
+  Status Launch() override;
+
+  Status Resume() override;
+
+  size_t GetNumMemoryRegions() override;
+
+  lldb::MemoryRegionInfoSP GetMemoryRegionAtIndex(size_t index) override;
+
+  lldb::MemoryRegionInfoSP
+  GetMemoryRegionContainingAddress(lldb::addr_t address) override;
+
+  size_t GetNumThreads() override;
+
+  StructuredData::DictionarySP GetThreadAtIndex(size_t index) override;
+
+  StructuredData

[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

thanks @DavidSpickett for the review. I have updated diff incorporating you 
suggestions.




Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:454
 bool NativeRegisterContextLinux_arm64::IsSVE(unsigned reg) const {
-  if (GetRegisterInfo().GetRegisterSetFromRegisterIndex(reg) ==
-  RegisterInfoPOSIX_arm64::SVERegSet)
+  if (GetRegisterInfo().IsSVEReg(reg))
 return true;

DavidSpickett wrote:
> `return GetRegisterInfo().IsSVEReg(reg)` ?
Ack.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1120
+  GetRegisterInfo().ConfigureVectorLength(vq);
   m_sve_ptrace_payload.resize(SVE_PT_SIZE(vq, SVE_PT_REGS_SVE));
 }

DavidSpickett wrote:
> I spent a good few minutes getting my head around this logic but tell me if I 
> missed something. (a comment explaining it would be great)
> 
> * If we don't have a cached sve header and we don't know that SVE is 
> disabled...
> * Try to read the SVE header
> * if it succeeded and we're doing this read for the first time, setup 
> register infos
> * otherwise it failed so SVE must be disabled
> * if it succeeded (first time or otherwise) query the vector length (this is 
> the bit that tripped me up trying to think how you'd refactor it)
> * if we did have a cached sve header, we'd already know the config, no point 
> reading it again
> * if it's disabled, then it's disabled, same thing.
> 
> I think that means you're missing the corner case where we have 
> SVEState::Full say, but then the header fails to read. Is that possible on a 
> real system though? I guess not.
> 
> And vector length can change at runtime, correct?
I have updated the comment to reflect what this piece of code tries to do. 

Register Infos are maintained by debuggers per process however for SVE we may 
have per thread register infos but what I understood from linux documentation 
is for a process to support SVE ptrace call to NT_ARM_SVE should succeed on 
first stop. This is what we are using to enabled or disabled SVE at startup.

if SVEState::Full is full and we fail to read NT_ARM_SVE at some stage for any 
reason. we can do try to read again on subsequent stop.





Comment at: 
lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp:43
 bool RegisterContextPOSIX_arm64::IsSVE(unsigned reg) const {
-  if (m_register_info_up->GetRegisterSetFromRegisterIndex(reg) ==
-  RegisterInfoPOSIX_arm64::SVERegSet)
+  if (m_register_info_up->IsSVEReg(reg))
 return true;

DavidSpickett wrote:
> `return m_register_info_up->IsSVEReg(reg);` ?
Ack.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:243
+  for (const auto ®set_range : m_per_regset_regnum_range) {
+if (reg_index >= regset_range.second.first &&
+reg_index <= regset_range.second.second)

DavidSpickett wrote:
> Should the last condition be  ```
> m_per_regset_regnum_range[FPRegSet] = std::make_pair(fpu_v0, fpu_fpcr);
> ```
> Where the last index is the first non FP register.
m_per_regset_regnum_range includes start and end register number of a register 
set with start and end inlucded.

fpu_fpcr is included in FPU regset. On non SVE targets Vx, Dx. Sx register plus 
fpcr and fpsr are part of FPU regset.





Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h:93
+
+  uint32_t ConfigureVectorLength(uint32_t mode);
 

DavidSpickett wrote:
> Just curious, is "mode" the term we use for the SVE length? I guess because 
> it's going to be some multiples of 128 isn't it, not an arbitrary bit length.
We had chosen mode when we started but then moves away from this terminology. I 
ve fixed it in next update.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 323928.

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

https://reviews.llvm.org/D96458

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp

Index: lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
===
--- lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -70,15 +70,18 @@
  sve::ptrace_regs_sve)
   m_sve_state = SVEState::Full;
 
-if (sve::vl_valid(m_sve_vector_length))
-  m_register_info_up->ConfigureVectorRegisterInfos(
-  sve::vq_from_vl(m_sve_vector_length));
-else {
+if (!sve::vl_valid(m_sve_vector_length)) {
   m_sve_state = SVEState::Disabled;
   m_sve_vector_length = 0;
 }
   } else
 m_sve_state = SVEState::Disabled;
+
+  if (m_sve_state != SVEState::Disabled) {
+m_register_info_up->ConfigureRegisterInfos(ARM64_REGS_CONFIG_SVE);
+m_register_info_up->ConfigureVectorLength(
+sve::vq_from_vl(m_sve_vector_length));
+  }
 }
 
 uint32_t RegisterContextCorePOSIX_arm64::CalculateSVEOffset(
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -14,6 +14,9 @@
 #include "lldb/lldb-private.h"
 #include 
 
+#define ARM64_REGS_CONFIG_DEFAULT 0x00
+#define ARM64_REGS_CONFIG_SVE 0x01
+
 enum class SVEState { Unknown, Disabled, FPSIMD, Full };
 
 class RegisterInfoPOSIX_arm64
@@ -85,7 +88,9 @@
 
   size_t GetRegisterSetFromRegisterIndex(uint32_t reg_index) const override;
 
-  uint32_t ConfigureVectorRegisterInfos(uint32_t sve_vq);
+  void ConfigureRegisterInfos(uint32_t opt_regsets);
+
+  uint32_t ConfigureVectorLength(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
 if (vq >= eVectorQuadwordAArch64 && vq <= eVectorQuadwordAArch64SVEMax)
@@ -95,6 +100,7 @@
 
   bool IsSVEEnabled() const { return m_vector_reg_vq > eVectorQuadwordAArch64; }
 
+  bool IsSVEReg(unsigned reg) const;
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
@@ -115,6 +121,18 @@
 
   const lldb_private::RegisterInfo *m_register_info_p;
   uint32_t m_register_info_count;
+
+  const lldb_private::RegisterSet *m_register_set_p;
+  uint32_t m_register_set_count;
+
+  // Contains pair of (start, end) register numbers of a register set with start
+  // and end included.
+  std::map> m_per_regset_regnum_range;
+
+  bool m_reg_infos_is_dynamic = false;
+
+  std::vector m_dynamic_reg_infos;
+  std::vector m_dynamic_reg_sets;
 };
 
 #endif
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -203,10 +203,17 @@
 const lldb_private::ArchSpec &target_arch)
 : lldb_private::RegisterInfoAndSetInterface(target_arch),
   m_register_info_p(GetRegisterInfoPtr(target_arch)),
-  m_register_info_count(GetRegisterInfoCount(target_arch)) {
+  m_register_info_count(GetRegisterInfoCount(target_arch)),
+  m_register_set_p(g_reg_sets_arm64),
+  m_register_set_count(k_num_register_sets - 1) {
+  m_per_regset_regnum_range[GPRegSet] = std::make_pair(gpr_x0, gpr_w28);
+  m_per_regset_regnum_range[FPRegSet] = std::make_pair(fpu_v0, fpu_fpcr);
 }
 
 uint32_t RegisterInfoPOSIX_arm64::GetRegisterCount() const {
+  if (m_reg_infos_is_dynamic)
+return m_register_info_count;
+
   if (IsSVEEnabled())
 return k_num_gpr_registers + k_num_fpr_registers + k_num_sve_registers;
 
@@ -227,31 +234,72 @@
 }
 
 size_t RegisterInfoPOSIX_arm64::GetRegisterSetCount() const {
-  if (IsSVEEnabled())
-return k_num_register_sets;
-  return k_num_register_sets - 1;
+  return m_register_set_count;
 }
 
 size_t RegisterInfoPOSIX_arm64::GetRegisterSetFromRegisterIndex(
 uint32_t reg_index) const {
-  if (reg_index <= gpr_w28)
-return GPRegSet;
-  if (reg_index <= fpu_fpcr)
-return FPRegSet;
-  if (reg_index <= sve_ffr)
-return SVERegSet;
+  for (const auto ®set_range : m_per_regset_regnum_range) {
+if (reg_index >= regset_range.second.first &&
+reg_index <= regset_range.second.second)
+  return regset_range.first;
+  }
   return LLDB_INVALID_REGNUM;
 }
 
 const lldb_private::RegisterSet *
 RegisterInfoPOSIX_ar

[Lldb-commits] [PATCH] D95711: [lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 323930.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95711

Files:
  lldb/bindings/python/python-wrapper.swig
  lldb/include/lldb/API/SBData.h
  lldb/include/lldb/API/SBError.h
  lldb/include/lldb/API/SBThreadPlan.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/include/lldb/Interpreter/ScriptedProcessInterface.h
  lldb/include/lldb/lldb-forward.h
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Interpreter/ScriptedProcessInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  
lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
  lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Index: lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
===
--- lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -12,6 +12,7 @@
 
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h"
+#include "lldb/API/SBError.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
 
@@ -153,6 +154,14 @@
   return 0;
 }
 
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBData(void *data) {
+  return nullptr;
+}
+
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBError(void *data) {
+  return nullptr;
+}
+
 extern "C" void *LLDBSWIGPython_CastPyObjectToSBValue(void *data) {
   return nullptr;
 }
@@ -207,6 +216,13 @@
   return nullptr;
 }
 
+extern "C" void *LLDBSwigPythonCreateScriptedProcess(
+const char *python_class_name, const char *session_dictionary_name,
+const lldb::TargetSP &target_sp, StructuredDataImpl *args_impl,
+std::string &error_string) {
+  return nullptr;
+}
+
 extern "C" void *
 LLDBSWIGPython_CreateFrameRecognizer(const char *python_class_name,
  const char *session_dictionary_name) {
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
===
--- /dev/null
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
@@ -0,0 +1,61 @@
+//===-- ScriptedProcessPythonInterface.h *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+#define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+
+#include "lldb/Host/Config.h"
+
+#if LLDB_ENABLE_PYTHON
+
+#include "lldb/Interpreter/ScriptedProcessInterface.h"
+
+namespace lldb_private {
+class ScriptInterpreterPythonImpl;
+class ScriptedProcessPythonInterface : public ScriptedProcessInterface {
+public:
+  ScriptedProcessPythonInterface(ScriptInterpreterPythonImpl &interpreter)
+  : ScriptedProcessInterface(), m_interpreter(interpreter) {}
+
+  StructuredData::GenericSP
+  CreatePluginObject(const llvm::StringRef class_name, lldb::TargetSP target_sp,
+ StructuredData::DictionarySP args_sp) override;
+
+  Status Launch() override;
+
+  Status Resume() override;
+
+  lldb::MemoryRegionInfoSP
+  GetMemoryRegionContainingAddress(lldb::addr_t address) override;
+
+  StructuredData::DictionarySP GetThreadWithID(lldb::tid_t tid) override;
+
+  StructuredData::DictionarySP GetRegistersForThread(lldb::tid_t tid) override;
+
+  lldb::DataExtractorSP ReadMemoryAtAddress(lldb::addr_t address, size_t size,
+Status &error) override;
+
+  StructuredData::DictionarySP GetLoadedImages() override;
+
+  lldb::pid_t GetProcessID() override;
+
+  bool IsAlive() override;
+
+protected:
+  size_t GetGenericInteger(llvm::StringRef method_name);
+  Status LaunchOrResume(llvm::StringRef method_name);
+
+private:
+  // The lifetime is managed by the ScriptInterpreter
+  ScriptInterpreterPythonImpl &m_interpreter;
+  StructuredData::GenericSP m_object_instance_sp;
+};
+} // namespace lldb_private
+
+#endif // LLDB_ENABLE_PYTHON
+#endif // LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDP

[Lldb-commits] [PATCH] D95712: [lldb/bindings] Add Python ScriptedProcess base class to lldb module

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib added a comment.

In D95712#2563091 , @labath wrote:

> Unfortunately I don't have the bandwidth to review this, though I feel that 
> this should have a wider discussion, given that its destined to become a 
> pretty big chunk of our public immutable api surface.

Thanks for taking the time to peek at this :) !

> Some questions to seed that discussion:
>
>   get_num_memory_regions() -> int:
>   get_memory_region_at_index(idx: int) -> lldb.SBMemoryRegionInfo:
>
> This means that the implementation needs to know the exact count of memory 
> regions at any given moment. Elsewhere, we've handled this by having a single 
> api like `get_memory_region_containing_address`. This permits (but doesn't 
> force) the implementation to be lazy in calculating the memory regions, and 
> the caller can still enumerate the memory regions by starting with 
> `get_memory_region_containing_address(0)` and continuing by 
> `get_memory_region_containing_address(prev_region.base + prev_region+size)`. 
> I think we should do the same here.
>
>   get_num_threads() -> int:
>   get_thread_at_index(idx: int) -> Dict:
>
> This suffers from the same problem, though the solution is not that simple. 
> But given that, not too long ago, we've (me&Jim) had a long discussion about 
> how materializing all the threads all the time is prohibitively expensive, it 
> might be good to elaborate on how exactly is this supposed to work (must the 
> implementation always return all threads, or can it have threads disappear 
> temporarily, etc.)

Sounds good! Regarding the threads, after talking to @jingham and 
@jasonmolenda, it sounds like XNU doesn't have a way to provide all its kernel 
threads at a single time, only the one loaded in each CPU core.
I changed the python interface to allow lazy loading, using the address to 
fetch a memory region or a thread ID to fetch a certain thread.

>   get_register_for_thread(tid:int) -> Dict:
>
> I guess this should be at least get_register**s**_for_thread

Typo :p !

>   read_memory_at_address(addr:int) -> lldb.SBData:
>
> How much memory is this supposed to read?

Right ... Originally, I didn't want to limit the users on how much data they 
should store in the SBData, that's why I didn't provided the size and checked 
the SBData size in the C++ interface.
In hindsight, this was a wrong design.

>   can_debug() -> bool:
>
> What's the use case for this?

Indeed, that didn't serve much purpose. Got rid of it :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95712

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


[Lldb-commits] [PATCH] D96766: [lldb] [Process/FreeBSD] Introduce mips64 FPU reg support

2021-02-16 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: labath, emaste, krytarowski.
Herald added subscribers: atanasyan, arichardson, ki.stfu, sdardis.
mgorny requested review of this revision.

https://reviews.llvm.org/D96766

Files:
  lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_mips64.cpp
  lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_mips64.h
  lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h
  lldb/source/Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -409,6 +409,11 @@
   EXPECT_THAT(GetRegParams(reg_ctx, gpr_##lldb_reg##_mips64),  \
   ::testing::Pair(offsetof(reg, r_regs[fbsd_regno]),   \
   sizeof(reg::r_regs[fbsd_regno])))
+#define EXPECT_FPU_MIPS64(lldb_reg, fbsd_regno)\
+  EXPECT_THAT( \
+  GetRegParams(reg_ctx, fpr_##lldb_reg##_mips64),  \
+  ::testing::Pair(offsetof(fpreg, r_regs[fbsd_regno]) + base_offset,   \
+  sizeof(fpreg::r_regs[fbsd_regno])))
 
 TEST(RegisterContextFreeBSDTest, mips64) {
   ArchSpec arch{"mips64-unknown-freebsd"};
@@ -457,6 +462,10 @@
   EXPECT_GPR_MIPS64(pc, 37);
   EXPECT_GPR_MIPS64(ic, 38);
   EXPECT_GPR_MIPS64(dummy, 39);
+
+  size_t base_offset = reg_ctx.GetRegisterInfo()[fpr_f0_mips64].byte_offset;
+
+  EXPECT_FPU_MIPS64(f0, 0);
 }
 
 #endif // defined(__mips64__)
Index: lldb/source/Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h
===
--- lldb/source/Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h
+++ lldb/source/Plugins/Process/Utility/lldb-mips-freebsd-register-enums.h
@@ -57,9 +57,47 @@
   gpr_dummy_mips64,
   k_last_gpr_mips64 = gpr_dummy_mips64,
 
+  k_first_fpr_mips64,
+  fpr_f0_mips64 = k_first_fpr_mips64,
+  fpr_f1_mips64,
+  fpr_f2_mips64,
+  fpr_f3_mips64,
+  fpr_f4_mips64,
+  fpr_f5_mips64,
+  fpr_f6_mips64,
+  fpr_f7_mips64,
+  fpr_f8_mips64,
+  fpr_f9_mips64,
+  fpr_f10_mips64,
+  fpr_f11_mips64,
+  fpr_f12_mips64,
+  fpr_f13_mips64,
+  fpr_f14_mips64,
+  fpr_f15_mips64,
+  fpr_f16_mips64,
+  fpr_f17_mips64,
+  fpr_f18_mips64,
+  fpr_f19_mips64,
+  fpr_f20_mips64,
+  fpr_f21_mips64,
+  fpr_f22_mips64,
+  fpr_f23_mips64,
+  fpr_f24_mips64,
+  fpr_f25_mips64,
+  fpr_f26_mips64,
+  fpr_f27_mips64,
+  fpr_f28_mips64,
+  fpr_f29_mips64,
+  fpr_f30_mips64,
+  fpr_f31_mips64,
+  fpr_fcsr_mips64,
+  fpr_fir_mips64,
+  k_last_fpr_mips64 = fpr_fir_mips64,
+
   k_num_registers_mips64,
 
-  k_num_gpr_registers_mips64 = k_last_gpr_mips64 - k_first_gpr_mips64 + 1
+  k_num_gpr_registers_mips64 = k_last_gpr_mips64 - k_first_gpr_mips64 + 1,
+  k_num_fpr_registers_mips64 = k_last_fpr_mips64 - k_first_fpr_mips64 + 1,
 };
-}
+} // namespace lldb_private
 #endif // LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_LLDB_MIPS_FREEBSD_REGISTER_ENUMS_H
Index: lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h
@@ -11,7 +11,6 @@
 #include "lldb/Core/dwarf.h"
 #include "llvm/Support/Compiler.h"
 
-
 #ifdef DECLARE_REGISTER_INFOS_MIPS64_STRUCT
 
 // Computes the offset of the given GPR in the user data area.
@@ -24,9 +23,15 @@
 #endif
 
 // Computes the offset of the given FPR in the extended data area.
+#ifdef LINUX_MIPS64
 #define FPR_OFFSET(regname)\
   (LLVM_EXTENSION offsetof(UserArea, fpr) +\
LLVM_EXTENSION offsetof(FPR_linux_mips, regname))
+#else
+#define FPR_OFFSET(regname)\
+  (sizeof(GPR_freebsd_mips) +  \
+   LLVM_EXTENSION offsetof(FPR_freebsd_mips, regname))
+#endif
 
 // Computes the offset of the given MSA in the extended data area.
 #define MSA_OFFSET(regname)\
@@ -70,6 +75,7 @@
 llvm::dwarf::DW_OP_lit26, llvm::dwarf::DW_OP_shl, llvm::dwarf::DW_OP_and,
 llvm::dwarf::DW_OP_lit26, llvm::dwarf::DW_OP_shr};
 
+#ifdef LINUX_MIPS64
 #define DEFINE_FPR(reg, alt, kind1, kind2, kind3)  \
   {\
 #reg, alt, sizeof(((FPR_linux_mips *) 0)->reg),\
@@ -

[Lldb-commits] [PATCH] D95712: [lldb/bindings] Add Python ScriptedProcess base class to lldb module

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 323940.
mib added a comment.

Changed python API to allow lazy fetching for threads and memory regions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95712

Files:
  lldb/bindings/python/CMakeLists.txt
  lldb/examples/python/scripted_process/my_scripted_process.py
  lldb/examples/python/scripted_process/scripted_process.py
  lldb/test/API/functionalities/scripted_process/Makefile
  lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
  lldb/test/API/functionalities/scripted_process/main.c

Index: lldb/test/API/functionalities/scripted_process/main.c
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/main.c
@@ -0,0 +1,5 @@
+#include 
+
+int main() {
+  return 0; // break here
+}
Index: lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
@@ -0,0 +1,45 @@
+"""
+Test python scripted process in lldb
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbtest
+
+
+class PlatformProcessCrashInfoTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+self.source = "main.c"
+
+def tearDown(self):
+TestBase.tearDown(self)
+
+@skipUnlessDarwin
+def test_python_plugin_package(self):
+"""Test that the lldb python module has a `plugins.scripted_process`
+package."""
+self.expect('script import lldb.plugins',
+patterns=["^((?!ModuleNotFoundError: No module named \'lldb\.plugins\').)*$"])
+
+self.expect('script dir(lldb.plugins)',
+patterns=["scripted_process"])
+
+self.expect('script import lldb.plugins.scripted_process',
+patterns=["^((?!ModuleNotFoundError: No module named \'lldb\.plugins\.scripted_process\').)*$"])
+
+self.expect('script dir(lldb.plugins.scripted_process)',
+patterns=["ScriptedProcess"])
+
+self.expect('script from lldb.plugins.scripted_process import ScriptedProcess',
+patterns=["^((?!ImportError: cannot import name \'ScriptedProcess\' from \'lldb.plugins\.scripted_process\').)*$"])
+
+self.expect('script dir(ScriptedProcess)',
+patterns=["launch"])
Index: lldb/test/API/functionalities/scripted_process/Makefile
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+
+include Makefile.rules
+
Index: lldb/examples/python/scripted_process/scripted_process.py
===
--- /dev/null
+++ lldb/examples/python/scripted_process/scripted_process.py
@@ -0,0 +1,188 @@
+from abc import ABCMeta, abstractmethod
+import six
+
+import lldb
+
+@six.add_metaclass(ABCMeta)
+class ScriptedProcess:
+
+"""
+The base class for a scripted process.
+
+Most of the base class methods are `@abstractmethod` that need to be
+overwritten by the inheriting class.
+
+Attributes:
+args (lldb.SBStructuredData): Dictionary holding arbitrary values
+loaded_images (list): List of the scripted process loaded images.
+memory_regions (list): List of the current memory regions.
+process_id (int): Scripted process identifier.
+stops (list): List of public stops.
+target (lldb.SBTarget): Target launching the scripted process.
+threads (list): List of the scripted process threads.
+
+Methods:
+get_memory_region_containing_address(addr: int) -> lldb.SBMemoryRegionInfo:
+Get the memory region for the scripted process, containing a
+specific address.
+
+get_thread_with_id(tid: int) -> Dict:
+Get the scripted process thread with a specific ID.
+
+get_registers_for_thread(tid:int) -> Dict:
+Get the register context dictionary for a certain thread.
+
+read_memory_at_address(addr:int, size:int) -> lldb.SBData:
+Get a memory buffer from the scripted process at a certain address,
+of a certain size.
+
+get_loaded_images() -> List:
+Get the list of loaded images for the scripted process.
+
+get_process_id() -> int:
+Get the scripted process identifier.
+
+launch() -> lldb.SBError:
+Simulate the scripted process launch.
+
+resume() -> lldb.SBError:
+Simulate the scripted process resume.
+
+is_alive() -> bool:
+Ch

[Lldb-commits] [PATCH] D95713: [lldb/Plugins] Add ScriptedProcess Process Plugin

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 323943.
mib marked 10 inline comments as done.
mib added a comment.

- Address @JDevlieghere comments:
- Add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95713

Files:
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/Scripted/CMakeLists.txt
  lldb/source/Plugins/Process/Scripted/ScriptedProcess.cpp
  lldb/source/Plugins/Process/Scripted/ScriptedProcess.h
  lldb/source/Target/Target.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
@@ -43,3 +43,24 @@
 
 self.expect('script dir(ScriptedProcess)',
 patterns=["launch"])
+
+@skipUnlessDarwin
+def test_launch_scripted_process(self):
+"""Test that we can launch an lldb scripted process and check its
+process ID """
+self.build()
+target = self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
+self.assertTrue(target, VALID_TARGET)
+scripted_process_example_relpath = "../../../../examples/python/scripted_process/my_scripted_process.py"
+os.environ['SKIP_SCRIPTED_PROCESS_LAUNCH'] = '1'
+self.runCmd("command script import " + os.path.join(self.getSourceDir(),
+scripted_process_example_relpath))
+
+launch_info = lldb.SBLaunchInfo(None)
+launch_info.SetProcessPluginName('ScriptedProcess')
+launch_info.SetScriptedProcessClassName('my_scripted_process.MyScriptedProcess')
+
+error = lldb.SBError()
+process = target.Launch(launch_info, error)
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertEqual(process.GetProcessID(), 42)
Index: lldb/source/Target/Target.cpp
===
--- lldb/source/Target/Target.cpp
+++ lldb/source/Target/Target.cpp
@@ -2950,7 +2950,7 @@
   // If we're not already connected to the process, and if we have a platform
   // that can launch a process for debugging, go ahead and do that here.
   if (state != eStateConnected && platform_sp &&
-  platform_sp->CanDebugProcess()) {
+  platform_sp->CanDebugProcess() && !launch_info.IsScriptedProcess()) {
 LLDB_LOGF(log, "Target::%s asking the platform to debug the process",
   __FUNCTION__);
 
Index: lldb/source/Plugins/Process/Scripted/ScriptedProcess.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Scripted/ScriptedProcess.h
@@ -0,0 +1,109 @@
+//===-- ScriptedProcess.h - -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+#define LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/Status.h"
+
+namespace lldb_private {
+
+class ScriptedProcess : public Process {
+protected:
+  class LaunchInfo {
+  public:
+LaunchInfo(const ProcessLaunchInfo &launch_info) {
+  m_class_name = launch_info.GetScriptedProcessClassName();
+  m_dictionary_sp = launch_info.GetScriptedProcessDictionarySP();
+}
+
+std::string GetClassName() const { return m_class_name; }
+StructuredData::DictionarySP GetDictionarySP() const {
+  return m_dictionary_sp;
+}
+
+  private:
+std::string m_class_name;
+StructuredData::DictionarySP m_dictionary_sp;
+  };
+
+public:
+  static lldb::ProcessSP CreateInstance(lldb::TargetSP target_sp,
+lldb::ListenerSP listener_sp,
+const FileSpec *crash_file_path,
+bool can_connect);
+
+  static void Initialize();
+
+  static void Terminate();
+
+  static ConstString GetPluginNameStatic();
+
+  static const char *GetPluginDescriptionStatic();
+
+  ScriptedProcess(lldb::TargetSP target_sp, lldb::ListenerSP listener_sp,
+  const ScriptedProcess::LaunchInfo &launch_info);
+
+  ~ScriptedProcess() override;
+
+  bool CanDebug(lldb::TargetSP target_sp,
+bool plugin_specified_by_name) override;
+
+  DynamicLoader *GetDynamicLoader() override { return nullptr; }
+
+  ConstString GetPluginName() override;
+
+  uint32_t GetPluginVersion() override;
+
+  SystemRuntime *GetSystemRunti

[Lldb-commits] [PATCH] D95713: [lldb/Plugins] Add ScriptedProcess Process Plugin

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 323945.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95713

Files:
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/scripted/CMakeLists.txt
  lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
  lldb/source/Plugins/Process/scripted/ScriptedProcess.h
  lldb/source/Target/Target.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
@@ -43,3 +43,24 @@
 
 self.expect('script dir(ScriptedProcess)',
 patterns=["launch"])
+
+@skipUnlessDarwin
+def test_launch_scripted_process(self):
+"""Test that we can launch an lldb scripted process and check its
+process ID """
+self.build()
+target = self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
+self.assertTrue(target, VALID_TARGET)
+scripted_process_example_relpath = "../../../../examples/python/scripted_process/my_scripted_process.py"
+os.environ['SKIP_SCRIPTED_PROCESS_LAUNCH'] = '1'
+self.runCmd("command script import " + os.path.join(self.getSourceDir(),
+scripted_process_example_relpath))
+
+launch_info = lldb.SBLaunchInfo(None)
+launch_info.SetProcessPluginName('ScriptedProcess')
+launch_info.SetScriptedProcessClassName('my_scripted_process.MyScriptedProcess')
+
+error = lldb.SBError()
+process = target.Launch(launch_info, error)
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertEqual(process.GetProcessID(), 42)
Index: lldb/source/Target/Target.cpp
===
--- lldb/source/Target/Target.cpp
+++ lldb/source/Target/Target.cpp
@@ -2950,7 +2950,7 @@
   // If we're not already connected to the process, and if we have a platform
   // that can launch a process for debugging, go ahead and do that here.
   if (state != eStateConnected && platform_sp &&
-  platform_sp->CanDebugProcess()) {
+  platform_sp->CanDebugProcess() && !launch_info.IsScriptedProcess()) {
 LLDB_LOGF(log, "Target::%s asking the platform to debug the process",
   __FUNCTION__);
 
Index: lldb/source/Plugins/Process/scripted/ScriptedProcess.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/scripted/ScriptedProcess.h
@@ -0,0 +1,109 @@
+//===-- ScriptedProcess.h - -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+#define LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/Status.h"
+
+namespace lldb_private {
+
+class ScriptedProcess : public Process {
+protected:
+  class LaunchInfo {
+  public:
+LaunchInfo(const ProcessLaunchInfo &launch_info) {
+  m_class_name = launch_info.GetScriptedProcessClassName();
+  m_dictionary_sp = launch_info.GetScriptedProcessDictionarySP();
+}
+
+std::string GetClassName() const { return m_class_name; }
+StructuredData::DictionarySP GetDictionarySP() const {
+  return m_dictionary_sp;
+}
+
+  private:
+std::string m_class_name;
+StructuredData::DictionarySP m_dictionary_sp;
+  };
+
+public:
+  static lldb::ProcessSP CreateInstance(lldb::TargetSP target_sp,
+lldb::ListenerSP listener_sp,
+const FileSpec *crash_file_path,
+bool can_connect);
+
+  static void Initialize();
+
+  static void Terminate();
+
+  static ConstString GetPluginNameStatic();
+
+  static const char *GetPluginDescriptionStatic();
+
+  ScriptedProcess(lldb::TargetSP target_sp, lldb::ListenerSP listener_sp,
+  const ScriptedProcess::LaunchInfo &launch_info);
+
+  ~ScriptedProcess() override;
+
+  bool CanDebug(lldb::TargetSP target_sp,
+bool plugin_specified_by_name) override;
+
+  DynamicLoader *GetDynamicLoader() override { return nullptr; }
+
+  ConstString GetPluginName() override;
+
+  uint32_t GetPluginVersion() override;
+
+  SystemRuntime *GetSystemRuntime() override { return nullptr; }
+
+  Status DoLaunch(Module *exe_module, ProcessLaunchInfo &launch_info) 

[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Andy Yankovsky via Phabricator via lldb-commits
werat created this revision.
werat added a reviewer: jankratochvil.
Herald added a reviewer: shafik.
werat requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: lldb-commits, sstefan1.
Herald added a project: LLDB.

Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF 
entries are being processed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96778

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3126,8 +3126,8 @@
   continue;
 switch (attr) {
 case DW_AT_decl_file:
-  decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
-  form_value.Unsigned()));
+  decl.SetFile(
+  attributes.CompileUnitAtIndex(i)->GetFile(form_value.Unsigned()));
   break;
 case DW_AT_decl_line:
   decl.SetLine(form_value.Unsigned());
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2201,7 +2201,8 @@
 case DW_AT_description:
 default:
 case DW_AT_decl_file:
-  decl.SetFile(die.GetCU()->GetFile(form_value.Unsigned()));
+  decl.SetFile(attributes.CompileUnitAtIndex(i)->GetFile(
+  form_value.Unsigned()));
   break;
 case DW_AT_decl_line:
   decl.SetLine(form_value.Unsigned());


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3126,8 +3126,8 @@
   continue;
 switch (attr) {
 case DW_AT_decl_file:
-  decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
-  form_value.Unsigned()));
+  decl.SetFile(
+  attributes.CompileUnitAtIndex(i)->GetFile(form_value.Unsigned()));
   break;
 case DW_AT_decl_line:
   decl.SetLine(form_value.Unsigned());
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2201,7 +2201,8 @@
 case DW_AT_description:
 default:
 case DW_AT_decl_file:
-  decl.SetFile(die.GetCU()->GetFile(form_value.Unsigned()));
+  decl.SetFile(attributes.CompileUnitAtIndex(i)->GetFile(
+  form_value.Unsigned()));
   break;
 case DW_AT_decl_line:
   decl.SetLine(form_value.Unsigned());
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Andy Yankovsky via Phabricator via lldb-commits
werat added a comment.
Herald added a subscriber: JDevlieghere.

Hi @jankratochvil, can you take a look at this, please?

I can't claim I fully understand what's the difference here, but this aligns 
with your comment at https://reviews.llvm.org/D92643#inline-900717 :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: JDevlieghere, stella.stamenova.
labath requested review of this revision.
Herald added a project: LLDB.

Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.

When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.

On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202 
.

To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.

To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.

I also strenghten the existing path test to ensure the returned path is
the right one.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96779

Files:
  lldb/include/lldb/Host/HostInfoBase.h
  lldb/include/lldb/Host/linux/HostInfoLinux.h
  lldb/include/lldb/Host/windows/HostInfoWindows.h
  lldb/include/lldb/Initialization/SystemInitializerCommon.h
  lldb/source/API/SystemInitializerFull.cpp
  lldb/source/Host/common/HostInfoBase.cpp
  lldb/source/Host/linux/HostInfoLinux.cpp
  lldb/source/Host/windows/HostInfoWindows.cpp
  lldb/source/Initialization/SystemInitializerCommon.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/test/API/functionalities/paths/TestPaths.py
  lldb/tools/lldb-server/SystemInitializerLLGS.h
  lldb/tools/lldb-test/SystemInitializerTest.cpp

Index: lldb/tools/lldb-test/SystemInitializerTest.cpp
===
--- lldb/tools/lldb-test/SystemInitializerTest.cpp
+++ lldb/tools/lldb-test/SystemInitializerTest.cpp
@@ -22,7 +22,8 @@
 
 using namespace lldb_private;
 
-SystemInitializerTest::SystemInitializerTest() = default;
+SystemInitializerTest::SystemInitializerTest()
+: SystemInitializerCommon(nullptr) {}
 SystemInitializerTest::~SystemInitializerTest() = default;
 
 llvm::Error SystemInitializerTest::Initialize() {
Index: lldb/tools/lldb-server/SystemInitializerLLGS.h
===
--- lldb/tools/lldb-server/SystemInitializerLLGS.h
+++ lldb/tools/lldb-server/SystemInitializerLLGS.h
@@ -14,6 +14,8 @@
 
 class SystemInitializerLLGS : public lldb_private::SystemInitializerCommon {
 public:
+  SystemInitializerLLGS() : SystemInitializerCommon(nullptr) {}
+
   llvm::Error Initialize() override;
   void Terminate() override;
 };
Index: lldb/test/API/functionalities/paths/TestPaths.py
===
--- lldb/test/API/functionalities/paths/TestPaths.py
+++ lldb/test/API/functionalities/paths/TestPaths.py
@@ -8,6 +8,7 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbplatformutil
 
 
 class TestPaths(TestBase):
@@ -29,7 +30,18 @@
 for path_type in dir_path_types:
 f = lldb.SBHostOS.GetLLDBPath(path_type)
 # No directory path types should have the filename set
-self.assertTrue(f.GetFilename() is None)
+self.assertIsNone(f.GetFilename())
+
+shlib_dir = lldb.SBHostOS.GetLLDBPath(lldb.ePathTypeLLDBShlibDir).GetDirectory()
+if lldbplatformutil.getHostPlatform() == 'windows':
+filenames = ['liblldb.dll']
+elif lldbplatformutil.getHostPlatform() == 'darwin':
+filenames = ['LLDB', 'liblldb.dylib']
+else:
+filenames = ['liblldb.so']
+self.assertTrue(any([os.path.exists(os.path.join(shlib_dir, f)) for f in
+filenames]), "shlib_dir = " + shlib_dir)
+
 
 @no_debug_info_test
 def test_directory_doesnt_end_with_slash(self):
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
@@ -51,6 +51,7 @@

[Lldb-commits] [lldb] 85f025e - [lldb/test] Test lldb-server named pipe functionality on windows

2021-02-16 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2021-02-16T15:47:39+01:00
New Revision: 85f025e5b33d148808177427eebca4cc14f93079

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

LOG: [lldb/test] Test lldb-server named pipe functionality on windows

lldb-server can use a named pipe to communicate the port number it is
listening on. This windows bits of this are already implemented, but we
did not have a test for that, most likely because python does not have
native pipe functionality.

This patch implements the windows bits necessary to test this. I'm using
the ctypes package to call the native APIs directly to avoid a
dependency to non-standard python packages. This introduces some amount
of boilerplate, but our named pipe use case is fairly limited, so we
should not end up needing to wrap large chunks of windows APIs.

Surprisingly to changes to lldb-server were needed to make the test
pass.

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

Added: 


Modified: 
lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py 
b/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
index 5a7220f76fe0..c9799d1976cb 100644
--- a/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
+++ b/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
@@ -5,6 +5,122 @@
 import socket
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbplatformutil
+import random
+
+if lldbplatformutil.getHostPlatform() == "windows":
+import ctypes
+import ctypes.wintypes
+from ctypes.wintypes import (BOOL, DWORD, HANDLE, LPCWSTR, LPDWORD, LPVOID)
+
+kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+
+PIPE_ACCESS_INBOUND = 1
+FILE_FLAG_FIRST_PIPE_INSTANCE = 0x0008
+FILE_FLAG_OVERLAPPED = 0x4000
+PIPE_TYPE_BYTE = 0
+PIPE_REJECT_REMOTE_CLIENTS = 8
+INVALID_HANDLE_VALUE = -1
+ERROR_ACCESS_DENIED = 5
+ERROR_IO_PENDING = 997
+
+
+class OVERLAPPED(ctypes.Structure):
+_fields_ = [("Internal", LPVOID), ("InternalHigh", LPVOID), ("Offset",
+DWORD), ("OffsetHigh", DWORD), ("hEvent", HANDLE)]
+
+def __init__(self):
+super(OVERLAPPED, self).__init__(Internal=0, InternalHigh=0,
+Offset=0, OffsetHigh=0, hEvent=None)
+LPOVERLAPPED = ctypes.POINTER(OVERLAPPED)
+
+CreateNamedPipe = kernel32.CreateNamedPipeW
+CreateNamedPipe.restype = HANDLE
+CreateNamedPipe.argtypes = (LPCWSTR, DWORD, DWORD, DWORD, DWORD, DWORD,
+DWORD, LPVOID)
+
+ConnectNamedPipe = kernel32.ConnectNamedPipe
+ConnectNamedPipe.restype = BOOL
+ConnectNamedPipe.argtypes = (HANDLE, LPOVERLAPPED)
+
+CreateEvent = kernel32.CreateEventW
+CreateEvent.restype = HANDLE
+CreateEvent.argtypes = (LPVOID, BOOL, BOOL, LPCWSTR)
+
+GetOverlappedResultEx = kernel32.GetOverlappedResultEx
+GetOverlappedResultEx.restype = BOOL
+GetOverlappedResultEx.argtypes = (HANDLE, LPOVERLAPPED, LPDWORD, DWORD,
+BOOL)
+
+ReadFile = kernel32.ReadFile
+ReadFile.restype = BOOL
+ReadFile.argtypes = (HANDLE, LPVOID, DWORD, LPDWORD, LPOVERLAPPED)
+
+CloseHandle = kernel32.CloseHandle
+CloseHandle.restype = BOOL
+CloseHandle.argtypes = (HANDLE,)
+
+class Pipe(object):
+def __init__(self, prefix):
+while True:
+self.name = "lldb-" + str(random.randrange(1e10))
+full_name = ".\\pipe\\" + self.name
+self._handle = CreateNamedPipe(full_name, PIPE_ACCESS_INBOUND |
+FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_BYTE | PIPE_REJECT_REMOTE_CLIENTS, 1, 4096,
+4096, 0, None)
+if self._handle != INVALID_HANDLE_VALUE:
+break
+if ctypes.get_last_error() != ERROR_ACCESS_DENIED:
+raise ctypes.WinError(ctypes.get_last_error())
+
+self._overlapped = OVERLAPPED()
+self._overlapped.hEvent = CreateEvent(None, True, False, None)
+result = ConnectNamedPipe(self._handle, self._overlapped)
+assert result == 0
+if ctypes.get_last_error() != ERROR_IO_PENDING:
+raise ctypes.WinError(ctypes.get_last_error())
+
+def finish_connection(self, timeout):
+if not GetOverlappedResultEx(self._handle, self._overlapped,
+ctypes.byref(DWORD(0)), timeout*1000, True):
+raise ctypes.WinError(ctypes.get_last_error())
+
+def read(self, size, timeout):
+  

[Lldb-commits] [PATCH] D96260: [lldb/test] Test lldb-server named pipe functionality on windows

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG85f025e5b33d: [lldb/test] Test lldb-server named pipe 
functionality on windows (authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96260

Files:
  lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py

Index: lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
===
--- lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
+++ lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
@@ -5,6 +5,122 @@
 import socket
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
+import lldbsuite.test.lldbplatformutil
+import random
+
+if lldbplatformutil.getHostPlatform() == "windows":
+import ctypes
+import ctypes.wintypes
+from ctypes.wintypes import (BOOL, DWORD, HANDLE, LPCWSTR, LPDWORD, LPVOID)
+
+kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+
+PIPE_ACCESS_INBOUND = 1
+FILE_FLAG_FIRST_PIPE_INSTANCE = 0x0008
+FILE_FLAG_OVERLAPPED = 0x4000
+PIPE_TYPE_BYTE = 0
+PIPE_REJECT_REMOTE_CLIENTS = 8
+INVALID_HANDLE_VALUE = -1
+ERROR_ACCESS_DENIED = 5
+ERROR_IO_PENDING = 997
+
+
+class OVERLAPPED(ctypes.Structure):
+_fields_ = [("Internal", LPVOID), ("InternalHigh", LPVOID), ("Offset",
+DWORD), ("OffsetHigh", DWORD), ("hEvent", HANDLE)]
+
+def __init__(self):
+super(OVERLAPPED, self).__init__(Internal=0, InternalHigh=0,
+Offset=0, OffsetHigh=0, hEvent=None)
+LPOVERLAPPED = ctypes.POINTER(OVERLAPPED)
+
+CreateNamedPipe = kernel32.CreateNamedPipeW
+CreateNamedPipe.restype = HANDLE
+CreateNamedPipe.argtypes = (LPCWSTR, DWORD, DWORD, DWORD, DWORD, DWORD,
+DWORD, LPVOID)
+
+ConnectNamedPipe = kernel32.ConnectNamedPipe
+ConnectNamedPipe.restype = BOOL
+ConnectNamedPipe.argtypes = (HANDLE, LPOVERLAPPED)
+
+CreateEvent = kernel32.CreateEventW
+CreateEvent.restype = HANDLE
+CreateEvent.argtypes = (LPVOID, BOOL, BOOL, LPCWSTR)
+
+GetOverlappedResultEx = kernel32.GetOverlappedResultEx
+GetOverlappedResultEx.restype = BOOL
+GetOverlappedResultEx.argtypes = (HANDLE, LPOVERLAPPED, LPDWORD, DWORD,
+BOOL)
+
+ReadFile = kernel32.ReadFile
+ReadFile.restype = BOOL
+ReadFile.argtypes = (HANDLE, LPVOID, DWORD, LPDWORD, LPOVERLAPPED)
+
+CloseHandle = kernel32.CloseHandle
+CloseHandle.restype = BOOL
+CloseHandle.argtypes = (HANDLE,)
+
+class Pipe(object):
+def __init__(self, prefix):
+while True:
+self.name = "lldb-" + str(random.randrange(1e10))
+full_name = ".\\pipe\\" + self.name
+self._handle = CreateNamedPipe(full_name, PIPE_ACCESS_INBOUND |
+FILE_FLAG_FIRST_PIPE_INSTANCE | FILE_FLAG_OVERLAPPED,
+PIPE_TYPE_BYTE | PIPE_REJECT_REMOTE_CLIENTS, 1, 4096,
+4096, 0, None)
+if self._handle != INVALID_HANDLE_VALUE:
+break
+if ctypes.get_last_error() != ERROR_ACCESS_DENIED:
+raise ctypes.WinError(ctypes.get_last_error())
+
+self._overlapped = OVERLAPPED()
+self._overlapped.hEvent = CreateEvent(None, True, False, None)
+result = ConnectNamedPipe(self._handle, self._overlapped)
+assert result == 0
+if ctypes.get_last_error() != ERROR_IO_PENDING:
+raise ctypes.WinError(ctypes.get_last_error())
+
+def finish_connection(self, timeout):
+if not GetOverlappedResultEx(self._handle, self._overlapped,
+ctypes.byref(DWORD(0)), timeout*1000, True):
+raise ctypes.WinError(ctypes.get_last_error())
+
+def read(self, size, timeout):
+buf = ctypes.create_string_buffer(size)
+if not ReadFile(self._handle, ctypes.byref(buf), size, None,
+self._overlapped):
+if ctypes.get_last_error() != ERROR_IO_PENDING:
+raise ctypes.WinError(ctypes.get_last_error())
+read = DWORD(0)
+if not GetOverlappedResultEx(self._handle, self._overlapped,
+ctypes.byref(read), timeout*1000, True):
+raise ctypes.WinError(ctypes.get_last_error())
+return buf.raw[0:read.value]
+
+def close(self):
+CloseHandle(self._overlapped.hEvent)
+CloseHandle(self._handle)
+
+
+else:
+class Pipe(object):
+def __init__(self, prefix):
+self.name = os.path.join(prefix, "stub_port_number")
+os.mkfifo(self.name)
+self._fd = os.open(self.name, os.O_RDONLY | os.O_NONBLOCK)

[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil accepted this revision.
jankratochvil added a comment.
This revision is now accepted and ready to land.

Thanks for catching those.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

In D96778#2565414 , @werat wrote:

> I can't claim I fully understand what's the difference here, but this aligns 
> with your comment at https://reviews.llvm.org/D92643#inline-900717 :)

If interested the problem was `DWARFAttributes` can contain attributes 
collected from multiple DIEs (linked by `DW_AT_specification` or 
`DW_AT_abstract_origin`). And with (future) DWZ patchset applied for LLDB such 
DIEs can come from multiple CUs. Therefore it is not enough to assume each 
attribute comes from CU of the original DIE.

Without DWZ it is sure not a bug. And DWZ is not yet in LLDB.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96634: [lldb][JITLoaderGDB] Test debug support in llvm-jitlink

2021-02-16 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

Thanks for taking a look. Planning to to give this a try as soon as JITLink 
support landed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96634

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


[Lldb-commits] [PATCH] D96460: [LLDB] Arm64/Linux Add MTE and Pointer Authentication registers

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added a comment.

Subsequent update will resolve review comments. @DavidSpickett  thanks for 
review. much appreciated




Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:79
 
+  m_mte_ctrl_reg = 0;
+

DavidSpickett wrote:
> Should m_pac_mask also be initialised or is it already?
Ack. Forgot to do it. 



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:120
+  uint32_t result = 0;
+  if (*auxv_at_hwcap & HWCAP_PACA)
+result |= ARM64_REGS_CONFIG_PAUTH;

DavidSpickett wrote:
> I think this should be more defensive:
> ```
> if (auxv_at_hwcap && (*auxv_at_hwcap & HWCAP_PACA))
> ```
> 
> Otherwise you'll deference an invalid optional, which might work if its 
> storage happens to be zeroed but it's not intended use.
Agreed



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:126
+
+  if (*auxv_at_hwcap2 & HWCAP2_MTE)
+result |= ARM64_REGS_CONFIG_MTE;

DavidSpickett wrote:
> Same here, auxv_at_hwcap2 could be llvm::None.
Ack.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1100
   m_sve_header_is_valid = false;
+  m_pac_mask_is_valid = false;
 

DavidSpickett wrote:
> I think `m_mte_ctrl_is_valid` is missing here.
Ack.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1198
+
+  if (m_mte_ctrl_is_valid)
+return error;

DavidSpickett wrote:
> Just to confirm I understand this logic.
> 
> If `m_mte_ctrl_is_valid` would mean that our cached value of the register is 
> valid. So if something tries to read a new copy of it we fail because they 
> should have used the cached version?
> 
> Then if `m_mte_ctrl_is_valid` is false, our cache is out of date so we do the 
> read.
> 
> Seems odd to error on asking for a read of a value that is cached but then 
> again I don't know the surrounding code too well. If that pattern is already 
> established no point disturbing it now.
Status is used to hold error codes and default error code is 'success'. If we 
have a valid cache value that means we dont need to read and return success 
thats why returning error without setting the error code.

If we need to read then we call ReadRegisterSet which will set the error code 
in case of failure.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1216
+
+  error = ReadMTEControl();
+  if (error.Fail())

DavidSpickett wrote:
> This is a sanity check that we didn't ask to write this register on a system 
> that doesn't have it?
This may only be relevant for optional regsets where we need to check if 
registers are readable before writing and registers which need partial 
modification and we need to have most recent value.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h:182
+
+  void *GetMTEControl() { return &m_pac_mask; }
+

DavidSpickett wrote:
> This looks like a mistake.
yes!!!



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:320
+  uint32_t pa_regnum = m_dynamic_reg_infos.size();
+  for (uint32_t i = 0; i < 2; i++) {
+pauth_regnum_collection.push_back(pa_regnum + i);

DavidSpickett wrote:
> Can you get this 2 from some list somewhere in this class? E.g. 
> PauthRegs.Size(). Or add a comment if not.
> 
> g_register_infos_pauth perhaps?
k_num_pauth_register already populated and will be used here as well.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:324
+m_dynamic_reg_infos[pa_regnum + i].byte_offset =
+m_dynamic_reg_infos[pa_regnum + i - 1].byte_offset +
+m_dynamic_reg_infos[pa_regnum + i - 1].byte_size;

DavidSpickett wrote:
> Is it possible at this point that `m_dynamic_reg_infos.size()` is 0 making 
> `m_dynamic_reg_infos[pa_regnum + i - 1]` into `m_dynamic_reg_infos[0 + 0 - 
> 1]` ?
> 
> I guess this could happen if SVE wasn't present but maybe you already account 
> for that.
Its not possible for m_dynamic_reg_infos.size to be zero because it is 
populated with either g_register_infos_arm64_sve_le or 
g_register_infos_arm64_le register infos array.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:326
+m_dynamic_reg_infos[pa_regnum + i - 1].byte_size;
+m_dynamic_reg_infos[pa_regnum + i].kinds[4] = pa_regnum + i;
+  }

DavidSpickett wrote:
> Please comment what the [4] is getting.
Ack.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:330
+  m_dynamic_reg_sets.push_back(g_reg_set_pauth_arm64);
+  m_dynamic_reg_sets[m_dynamic_reg_sets.size() - 1].registers =
+  pauth_regn

[Lldb-commits] [PATCH] D96460: [LLDB] Arm64/Linux Add MTE and Pointer Authentication registers

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 324017.

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

https://reviews.llvm.org/D96460

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
@@ -470,6 +470,13 @@
 LLDB_INVALID_REGNUM, lldb_kind \
   }
 
+// Generates register kinds array for registers with only lldb kind
+#define KIND_ALL_INVALID   \
+  {\
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, \
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM   \
+  }
+
 // Generates register kinds array for vector registers
 #define GPR64_KIND(reg, generic_kind) MISC_KIND(reg, gpr, generic_kind)
 #define VREG_KIND(reg) MISC_KIND(reg, fpu, LLDB_INVALID_REGNUM)
@@ -526,6 +533,13 @@
 nullptr, 0 \
   }
 
+// Defines pointer authentication mask registers
+#define DEFINE_EXTENSION_REG(reg)  \
+  {\
+#reg, nullptr, 8, 0, lldb::eEncodingUint, lldb::eFormatHex,\
+KIND_ALL_INVALID, nullptr, nullptr, nullptr, 0 \
+  }
+
 static lldb_private::RegisterInfo g_register_infos_arm64_le[] = {
 // DEFINE_GPR64(name, GENERIC KIND)
 DEFINE_GPR64(x0, LLDB_REGNUM_GENERIC_ARG1),
@@ -772,7 +786,12 @@
 {DEFINE_DBG(wcr, 13)},
 {DEFINE_DBG(wcr, 14)},
 {DEFINE_DBG(wcr, 15)}
-// clang-format on
 };
+// clang-format on
+static lldb_private::RegisterInfo g_register_infos_pauth[] = {
+DEFINE_EXTENSION_REG(data_mask), DEFINE_EXTENSION_REG(code_mask)};
+
+static lldb_private::RegisterInfo g_register_infos_mte[] = {
+DEFINE_EXTENSION_REG(mte_ctrl)};
 
 #endif // DECLARE_REGISTER_INFOS_ARM64_STRUCT
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -19,10 +19,15 @@
 
 enum class SVEState { Unknown, Disabled, FPSIMD, Full };
 
+#define ARM64_REGS_CONFIG_DEFAULT 0x00
+#define ARM64_REGS_CONFIG_SVE 0x01
+#define ARM64_REGS_CONFIG_PAUTH 0x02
+#define ARM64_REGS_CONFIG_MTE 0x04
+
 class RegisterInfoPOSIX_arm64
 : public lldb_private::RegisterInfoAndSetInterface {
 public:
-  enum { GPRegSet = 0, FPRegSet, SVERegSet };
+  enum { GPRegSet = 0, FPRegSet };
 
   // AArch64 Register set FP/SIMD feature configuration
   enum {
@@ -90,6 +95,10 @@
 
   void ConfigureRegisterInfos(uint32_t opt_regsets);
 
+  void AddRegSetPAuth();
+
+  void AddRegSetMTE();
+
   uint32_t ConfigureVectorLength(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
@@ -104,12 +113,16 @@
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
+  bool IsPAuthReg(unsigned reg) const;
+  bool IsMTEReg(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
+  uint32_t GetPAuthOffset() const;
+  uint32_t GetMTEOffset() const;
 
 private:
   typedef std::map>
@@ -129,10 +142,15 @@
   // and end included.
   std::map> m_per_regset_regnum_range;
 
+  bool m_mte_regset_enabled = false;
+  bool m_pauth_regset_enabled = false;
   bool m_reg_infos_is_dynamic = false;
 
   std::vector m_dynamic_reg_infos;
   std::vector m_dynamic_reg_sets;
+
+  std::vector pauth_regnum_collection;
+  std::vector m_mte_regnum_collection;
 };
 
 #endif
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -89,6 +89,8 @@
   k_num_gpr_registers = gpr_w28 - gpr_x0 + 1,
   k_num_fpr_registers = fpu_fpcr - fpu_v0 + 1,
   k_num_sve_registers = sve_ffr - sve_vg + 1,
+  k_num_mte_register = 1,
+  k_num_pauth_register = 2,
   k_num_register_sets = 3
 };
 
@@ -186,6 +188,12 @@
 {"Scalable Vector Extension Registers", "sve", k

[Lldb-commits] [PATCH] D96460: [LLDB] Arm64/Linux Add MTE and Pointer Authentication registers

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 324018.

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

https://reviews.llvm.org/D96460

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_arm64.h
@@ -470,6 +470,13 @@
 LLDB_INVALID_REGNUM, lldb_kind \
   }
 
+// Generates register kinds array for registers with only lldb kind
+#define KIND_ALL_INVALID   \
+  {\
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM, \
+LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM   \
+  }
+
 // Generates register kinds array for vector registers
 #define GPR64_KIND(reg, generic_kind) MISC_KIND(reg, gpr, generic_kind)
 #define VREG_KIND(reg) MISC_KIND(reg, fpu, LLDB_INVALID_REGNUM)
@@ -526,6 +533,13 @@
 nullptr, 0 \
   }
 
+// Defines pointer authentication mask registers
+#define DEFINE_EXTENSION_REG(reg)  \
+  {\
+#reg, nullptr, 8, 0, lldb::eEncodingUint, lldb::eFormatHex,\
+KIND_ALL_INVALID, nullptr, nullptr, nullptr, 0 \
+  }
+
 static lldb_private::RegisterInfo g_register_infos_arm64_le[] = {
 // DEFINE_GPR64(name, GENERIC KIND)
 DEFINE_GPR64(x0, LLDB_REGNUM_GENERIC_ARG1),
@@ -772,7 +786,12 @@
 {DEFINE_DBG(wcr, 13)},
 {DEFINE_DBG(wcr, 14)},
 {DEFINE_DBG(wcr, 15)}
-// clang-format on
 };
+// clang-format on
+static lldb_private::RegisterInfo g_register_infos_pauth[] = {
+DEFINE_EXTENSION_REG(data_mask), DEFINE_EXTENSION_REG(code_mask)};
+
+static lldb_private::RegisterInfo g_register_infos_mte[] = {
+DEFINE_EXTENSION_REG(mte_ctrl)};
 
 #endif // DECLARE_REGISTER_INFOS_ARM64_STRUCT
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
@@ -19,10 +19,15 @@
 
 enum class SVEState { Unknown, Disabled, FPSIMD, Full };
 
+#define ARM64_REGS_CONFIG_DEFAULT 0x00
+#define ARM64_REGS_CONFIG_SVE 0x01
+#define ARM64_REGS_CONFIG_PAUTH 0x02
+#define ARM64_REGS_CONFIG_MTE 0x04
+
 class RegisterInfoPOSIX_arm64
 : public lldb_private::RegisterInfoAndSetInterface {
 public:
-  enum { GPRegSet = 0, FPRegSet, SVERegSet };
+  enum { GPRegSet = 0, FPRegSet };
 
   // AArch64 Register set FP/SIMD feature configuration
   enum {
@@ -90,6 +95,10 @@
 
   void ConfigureRegisterInfos(uint32_t opt_regsets);
 
+  void AddRegSetPAuth();
+
+  void AddRegSetMTE();
+
   uint32_t ConfigureVectorLength(uint32_t sve_vq);
 
   bool VectorSizeIsValid(uint32_t vq) {
@@ -104,12 +113,16 @@
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
+  bool IsPAuthReg(unsigned reg) const;
+  bool IsMTEReg(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
+  uint32_t GetPAuthOffset() const;
+  uint32_t GetMTEOffset() const;
 
 private:
   typedef std::map>
@@ -129,10 +142,15 @@
   // and end included.
   std::map> m_per_regset_regnum_range;
 
+  bool m_mte_regset_enabled = false;
+  bool m_pauth_regset_enabled = false;
   bool m_reg_infos_is_dynamic = false;
 
   std::vector m_dynamic_reg_infos;
   std::vector m_dynamic_reg_sets;
+
+  std::vector pauth_regnum_collection;
+  std::vector m_mte_regnum_collection;
 };
 
 #endif
Index: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -89,6 +89,8 @@
   k_num_gpr_registers = gpr_w28 - gpr_x0 + 1,
   k_num_fpr_registers = fpu_fpcr - fpu_v0 + 1,
   k_num_sve_registers = sve_ffr - sve_vg + 1,
+  k_num_mte_register = 1,
+  k_num_pauth_register = 2,
   k_num_register_sets = 3
 };
 
@@ -186,6 +188,12 @@
 {"Scalable Vector Extension Registers", "sve", k

[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:104
+
+  return 0;
+}

DavidSpickett wrote:
> Do I understand correctly that this will be filled in in a further patch? So 
> right now it's only returning 0 because it's not hooked up yet.
> For the sake of clean patches I'd rather it just returned 0, then put the 
> rest of the work in the follow up.
Agreed. We can move implementation details to next inline patch where MTE/PAuth 
regs are being added.


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

https://reviews.llvm.org/D96459

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


[Lldb-commits] [PATCH] D96459: [LLDB] Pull AuxVec info into NativeRegisterContextLinux_arm64

2021-02-16 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 324021.

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

https://reviews.llvm.org/D96459

Files:
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -166,6 +166,8 @@
 
   Status ReadHardwareDebugInfo();
 
+  uint32_t QueryAuxvForOptionalRegset();
+
   Status WriteHardwareDebugRegs(int hwbType);
 
   uint32_t CalculateFprOffset(const RegisterInfo *reg_info) const;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -21,6 +21,7 @@
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "Plugins/Process/Linux/Procfs.h"
 #include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "Plugins/Process/Utility/AuxVector.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 
 // System includes - They have to be included after framework includes because
@@ -84,6 +85,10 @@
   return static_cast(*m_register_info_interface_up);
 }
 
+uint32_t NativeRegisterContextLinux_arm64::QueryAuxvForOptionalRegset() {
+  return ARM64_REGS_CONFIG_DEFAULT;
+}
+
 uint32_t NativeRegisterContextLinux_arm64::GetRegisterSetCount() const {
   return GetRegisterInfo().GetRegisterSetCount();
 }
@@ -1096,10 +1101,10 @@
   // be deemed non operational for the lifetime of current process.
   if (!m_sve_header_is_valid && m_sve_state != SVEState::Disabled) {
 Status error = ReadSVEHeader();
-uint32_t opt_regset = ARM64_REGS_CONFIG_DEFAULT;
 // m_sve_state is set to SVEState::Unknown on first stop and ReadSVEHeader
 // is called to enable or disable SVE register set.
 if (m_sve_state == SVEState::Unknown) {
+  uint32_t opt_regset = QueryAuxvForOptionalRegset();
   if (error.Success()) {
 opt_regset |= ARM64_REGS_CONFIG_SVE;
 GetRegisterInfo().ConfigureRegisterInfos(opt_regset);
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -156,6 +156,8 @@
 
   static Status SetDefaultPtraceOpts(const lldb::pid_t);
 
+  llvm::Optional GetAuxValue(enum AuxVector::EntryType type);
+
   void MonitorCallback(lldb::pid_t pid, bool exited, WaitStatus status);
 
   void WaitForNewThread(::pid_t tid);
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -2021,3 +2021,18 @@
 
   return error;
 }
+
+llvm::Optional
+NativeProcessLinux::GetAuxValue(enum AuxVector::EntryType type) {
+  if (m_aux_vector == nullptr) {
+auto buffer_or_error = GetAuxvData();
+if (!buffer_or_error)
+  return llvm::None;
+DataExtractor auxv_data(buffer_or_error.get()->getBufferStart(),
+buffer_or_error.get()->getBufferSize(),
+GetByteOrder(), GetAddressByteSize());
+m_aux_vector = std::make_unique(auxv_data);
+  }
+
+  return m_aux_vector->GetAuxValue(type);
+}


Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
@@ -166,6 +166,8 @@
 
   Status ReadHardwareDebugInfo();
 
+  uint32_t QueryAuxvForOptionalRegset();
+
   Status WriteHardwareDebugRegs(int hwbType);
 
   uint32_t CalculateFprOffset(const RegisterInfo *reg_info) const;
Index: lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -21,6 +21,7 @@
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
 #include "Plugins/Process/Linux/Procfs.h"
 #include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "Plugins/Process/Utility/AuxVector.h"
 #include "Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h"
 
 // System includes - They have to be i

[Lldb-commits] [PATCH] D96460: [LLDB] Arm64/Linux Add MTE and Pointer Authentication registers

2021-02-16 Thread David Spickett via Phabricator via lldb-commits
DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1198
+
+  if (m_mte_ctrl_is_valid)
+return error;

omjavaid wrote:
> DavidSpickett wrote:
> > Just to confirm I understand this logic.
> > 
> > If `m_mte_ctrl_is_valid` would mean that our cached value of the register 
> > is valid. So if something tries to read a new copy of it we fail because 
> > they should have used the cached version?
> > 
> > Then if `m_mte_ctrl_is_valid` is false, our cache is out of date so we do 
> > the read.
> > 
> > Seems odd to error on asking for a read of a value that is cached but then 
> > again I don't know the surrounding code too well. If that pattern is 
> > already established no point disturbing it now.
> Status is used to hold error codes and default error code is 'success'. If we 
> have a valid cache value that means we dont need to read and return success 
> thats why returning error without setting the error code.
> 
> If we need to read then we call ReadRegisterSet which will set the error code 
> in case of failure.
Doh, yes I missed that that "error" will not be a failure at that point.


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

https://reviews.llvm.org/D96460

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In general, I believe such a situation can occur even now, if 
DW_AT_specification/DW_AT_abstract_origin uses DW_FORM_ref_addr. And I think 
dsymutil actually produces such references. However, I don't think one can 
meaningfully use DW_AT_specification/DW_AT_abstract_origin for enumerators. It 
might be possible for variable DIEs in inlined functions (with the function's 
abstract origin residing in another CU), but as the only effect of that will be 
a change in the file the variable was supposedly declared in, I don't think 
anybody would notice, even if we ran into debug info like this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96427: Support multi-configuration generators correctly in several config files

2021-02-16 Thread Stella Stamenova via Phabricator via lldb-commits
stella.stamenova created this revision.
Herald added subscribers: teijeong, rdzhabarov, tatianashp, msifontes, jurahul, 
Kayjukh, grosul1, Joonsoo, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, 
antiagainst, shauheen, rriddle, mehdi_amini, mgorny.
Herald added a reviewer: JDevlieghere.
Herald added a reviewer: aartbik.
stella.stamenova requested review of this revision.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits, 
stephenneuendorffer, nicolasvasilache.
Herald added projects: clang, LLDB, MLIR, LLVM.

Multi-configuration generators (such as Visual Studio and XCode) allow the 
specification of a build flavor at build time instead of config time, so the 
lit configuration files need to support that - and they do for the most part. 
There are several places that had one of two issues (or both!):

1. Paths had %(build_mode)s set up, but then not configured, resulting in 
values that would not work correctly e.g. 
D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2. Paths did not have %(build_mode)s set up, but instead contained 
$(Configuration) (which is the value for Visual Studio at configuration time, 
for Xcode they would have had the equivalent) e.g. 
"D:/llvm-build/$(Configuration)/lib".

This seems to indicate that we still have a lot of fragility in the 
configurations, but also that a number of these paths are never used (at least 
on Windows) since the errors appear to have been there a while.

This patch fixes the configurations and it has been tested with Ninja and 
Visual Studio to generate the correct paths. We should consider removing some 
of these settings altogether.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96427

Files:
  clang/test/Unit/lit.site.cfg.py.in
  lld/test/CMakeLists.txt
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/CMakeLists.txt
  llvm/test/Unit/lit.site.cfg.py.in
  llvm/test/lit.site.cfg.py.in
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/integration_test/lit.site.cfg.py.in
  mlir/test/Unit/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in

Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -51,6 +51,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/test/Unit/lit.site.cfg.py.in
===
--- mlir/test/Unit/lit.site.cfg.py.in
+++ mlir/test/Unit/lit.site.cfg.py.in
@@ -17,6 +17,7 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args
Index: mlir/integration_test/lit.site.cfg.py.in
===
--- mlir/integration_test/lit.site.cfg.py.in
+++ mlir/integration_test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -38,6 +38,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -35,6 +35,7 @@
 # used w

[Lldb-commits] [PATCH] D96427: Support multi-configuration generators correctly in several config files

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.

LGTM. I'm surprised the `dsymutil` one slipped through the cracks, we have a 
bot that should (?) be testing this configuration: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

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


[Lldb-commits] [PATCH] D96427: Support multi-configuration generators correctly in several config files

2021-02-16 Thread Stella Stamenova 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 rGed98676fa483: Support multi-configuration generators 
correctly in several config files (authored by stella.stamenova).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

Files:
  clang/test/Unit/lit.site.cfg.py.in
  lld/test/CMakeLists.txt
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/CMakeLists.txt
  llvm/test/Unit/lit.site.cfg.py.in
  llvm/test/lit.site.cfg.py.in
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/integration_test/lit.site.cfg.py.in
  mlir/test/Unit/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in

Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -51,6 +51,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/test/Unit/lit.site.cfg.py.in
===
--- mlir/test/Unit/lit.site.cfg.py.in
+++ mlir/test/Unit/lit.site.cfg.py.in
@@ -17,6 +17,7 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args
Index: mlir/integration_test/lit.site.cfg.py.in
===
--- mlir/integration_test/lit.site.cfg.py.in
+++ mlir/integration_test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -40,6 +40,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -35,6 +35,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = path(r"@LLVM_SOURCE_DIR@")
 config.llvm_obj_root = path(r"@LLVM_BINARY_DIR@")
 config.llvm_tools_dir = path(r"@LLVM_TOOLS_DIR@")
-config.llvm_lib_dir = path(r"@LLVM_LIBRARY_DIR@")
+config.llvm_lib_dir = path(r"@LLVM_LIBS_DIR@")
 config.llvm_shlib_dir = path(r"@SHLIBDIR@")
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -56,6 +56,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/Unit/lit.site.cfg.py.in
===

[Lldb-commits] [PATCH] D96427: Support multi-configuration generators correctly in several config files

2021-02-16 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment.

In D96427#2555251 , @JDevlieghere 
wrote:

> LGTM. I'm surprised the `dsymutil` one slipped through the cracks, we have a 
> bot that should (?) be testing this configuration: 
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/

Maybe it used the system dsymutil or something? (or maybe it worked by accident 
in the Xcode setup)

Anyway, I wonder if we could have some (low frequency) bot that could test this 
configuration? There is the LLDB+Xcode one and I have my own standalone build 
bot, but I guess we would need a Visual studio one too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

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


[Lldb-commits] [PATCH] D96427: Support multi-configuration generators correctly in several config files

2021-02-16 Thread Stella Stamenova via Phabricator via lldb-commits
stella.stamenova updated this revision to Diff 323053.
stella.stamenova edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

Files:
  clang/test/Unit/lit.site.cfg.py.in
  lld/test/CMakeLists.txt
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/CMakeLists.txt
  llvm/test/Unit/lit.site.cfg.py.in
  llvm/test/lit.site.cfg.py.in
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/integration_test/lit.site.cfg.py.in
  mlir/test/Unit/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in

Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -51,6 +51,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/test/Unit/lit.site.cfg.py.in
===
--- mlir/test/Unit/lit.site.cfg.py.in
+++ mlir/test/Unit/lit.site.cfg.py.in
@@ -17,6 +17,7 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args
Index: mlir/integration_test/lit.site.cfg.py.in
===
--- mlir/integration_test/lit.site.cfg.py.in
+++ mlir/integration_test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -40,6 +40,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -35,6 +35,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = path(r"@LLVM_SOURCE_DIR@")
 config.llvm_obj_root = path(r"@LLVM_BINARY_DIR@")
 config.llvm_tools_dir = path(r"@LLVM_TOOLS_DIR@")
-config.llvm_lib_dir = path(r"@LLVM_LIBRARY_DIR@")
+config.llvm_lib_dir = path(r"@LLVM_LIBS_DIR@")
 config.llvm_shlib_dir = path(r"@SHLIBDIR@")
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -56,6 +56,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/Unit/lit.site.cfg.py.in
===
--- llvm/test/Unit/lit.site.cfg.py.in
+++ llvm/test/Unit/lit.site.cfg.py.in
@@ -14,6 +14,7 @@
 try:
 config.llvm_tools_dir = co

[Lldb-commits] [PATCH] D95712: [lldb/bindings] Add Python ScriptedProcess base class to lldb module

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere requested changes to this revision.
JDevlieghere added a comment.
This revision now requires changes to proceed.

In D95712#2563091 , @labath wrote:

> Unfortunately I don't have the bandwidth to review this, though I feel that 
> this should have a wider discussion, given that its destined to become a 
> pretty big chunk of our public immutable api surface.

When @mib and I discussed this offline, the idea was to start with an interface 
that matches the C++ class and iterate on it as we gain more experience through 
different use cases. Initially those uses cases consist of core file debugging 
with a scripted process and using it to write tests for things that have 
historically hard to test (@jasonmolenda has a better idea of what these are). 
Long term the scriptable process plugin would be like the OS plugins on 
steroids and would probably superseed them. I expect the XNU people (who are 
currently the main users of the OS plugins) to have valuable input on the 
interface as well. Until then the interface shouldn't be considered stable.

@mib Can you please add a disclaimed to the base class saying that the 
interface is subject to change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95712

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread David Blaikie via Phabricator via lldb-commits
dblaikie added a comment.

In D96778#2565677 , @jankratochvil 
wrote:

> In D96778#2565414 , @werat wrote:
>
>> I can't claim I fully understand what's the difference here, but this aligns 
>> with your comment at https://reviews.llvm.org/D92643#inline-900717 :)
>
> If interested the problem was `DWARFAttributes` can contain attributes 
> collected from multiple DIEs (linked by `DW_AT_specification` or 
> `DW_AT_abstract_origin`). And with (future) DWZ patchset applied for LLDB 
> such DIEs can come from multiple CUs. Therefore it is not enough to assume 
> each attribute comes from CU of the original DIE.
>
> Without DWZ it is sure not a bug. And DWZ is not yet in LLDB.

As @labath mentioned, certainly there's some support in LLDB for cross-CU 
references, as LLVM produces these when performing LTO.

I expect it'd be good to have a test case showing the sort of DWARF that DWZ 
produces for cross-CU references of enumerators.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 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.

Seems like a reasonable solution. LGTM.




Comment at: lldb/include/lldb/Host/HostInfoBase.h:44-46
+  using SharedLibraryDirectoryHelper = void(FileSpec &this_file);
+
+  static void Initialize(SharedLibraryDirectoryHelper *helper = nullptr);

Why a function pointer and no `function_ref`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96779

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


[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/include/lldb/Host/HostInfoBase.h:44-46
+  using SharedLibraryDirectoryHelper = void(FileSpec &this_file);
+
+  static void Initialize(SharedLibraryDirectoryHelper *helper = nullptr);

JDevlieghere wrote:
> Why a function pointer and no `function_ref`?
function_ref can only be used for objects which do not escape the current 
function (just like StringRef), while this value is persisted. It could be a 
std::function, but that seems a bit overkill.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96779

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


[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added inline comments.



Comment at: lldb/include/lldb/Host/HostInfoBase.h:44-46
+  using SharedLibraryDirectoryHelper = void(FileSpec &this_file);
+
+  static void Initialize(SharedLibraryDirectoryHelper *helper = nullptr);

labath wrote:
> JDevlieghere wrote:
> > Why a function pointer and no `function_ref`?
> function_ref can only be used for objects which do not escape the current 
> function (just like StringRef), while this value is persisted. It could be a 
> std::function, but that seems a bit overkill.
Forgive my ignorance, but how does that apply to `SharedLibraryDirectoryHelper` 
which is a static method? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96779

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


[Lldb-commits] [PATCH] D96548: [lldb] [Process/FreeBSDRemote] Introduce aarch64 hw break/watchpoint support [WIP]

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a reviewer: omjavaid.
labath added a comment.

I'm torn about the ReadHardwareDebugInfo interface. On one hand, there's no use 
case now for distinguishing the failure to retrieve breakpoint info from 
successfully determining that we support zero breakpoints. So we could make the 
function return void, move the log statement into the function, and simplify a 
bunch of stuff. OTOH, if those functions are later changed to propagate errors, 
they would become simpler too, and we might be able to forward this error all 
the way to the user...

Apart from that, I think this is fine, but maybe @omjavaid could take a quick 
look.




Comment at: 
lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.h:62-63
   std::array m_reg_data;
+  dbreg m_dbreg;
+  bool m_read_dbreg;
 

maybe Optional


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

https://reviews.llvm.org/D96548

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


[Lldb-commits] [PATCH] D96458: [LLDB] Add support for Arm64/Linux dynamic register sets

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I'm sorry, my response times are pretty slow these days.

I'm thinking about this `ConfigureRegisterInfos` business. I get that the 
vector length is variable, and so we need to refresh it after every stop. 
However, the set of enabled extensions seems more static.

Is it possible for that to change during the lifetime of the process? I'd guess 
not, because otherwise we'd have to also resend the register lists after every 
stop. And, if that's the case, I'm wondering if there's a way to reflect this 
static-ness in the code. For example, by doing this setup in the constructor, 
instead of a late `ConfigureRegisterInfos` call. IIRC, the register contexts 
are created when the thread is stopped, so it should be possible to fetch the 
information about supported registers quite early.

What do you think?




Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h:17-18
 
+#define ARM64_REGS_CONFIG_DEFAULT 0x00
+#define ARM64_REGS_CONFIG_SVE 0x01
+

let's not use macros here.


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

https://reviews.llvm.org/D96458

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


[Lldb-commits] [PATCH] D96795: [FileCollector] Fix that the file system case-sensitivity check was inverted

2021-02-16 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf88b502d9bc7: [FileCollector] Fix that the file system 
case-sensitivity check was inverted (authored by teemperor).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96795

Files:
  
lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
  llvm/lib/Support/FileCollector.cpp


Index: llvm/lib/Support/FileCollector.cpp
===
--- llvm/lib/Support/FileCollector.cpp
+++ llvm/lib/Support/FileCollector.cpp
@@ -35,7 +35,7 @@
   SmallString<256> TmpDest = Path, UpperDest, RealDest;
 
   // Remove component traversals, links, etc.
-  if (!sys::fs::real_path(Path, TmpDest))
+  if (sys::fs::real_path(Path, TmpDest))
 return true; // Current default value in vfs.yaml
   Path = TmpDest;
 
@@ -44,7 +44,7 @@
   // sensitive in the absence of real_path, since this is the YAMLVFSWriter
   // default.
   UpperDest = Path.upper();
-  if (sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
+  if (!sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
 return false;
   return true;
 }
Index: 
lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
===
--- /dev/null
+++ 
lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
@@ -0,0 +1,57 @@
+"""
+Test if the reproducer correctly detects whether the file system is case 
sensitive.
+"""
+
+import lldb
+import tempfile
+from lldbsuite.test import lldbtest_config
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ReproducerFileSystemSensitivityTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipIfNetBSD
+@skipIfWindows
+@skipIfRemote
+@skipIfiOSSimulator
+@skipIfReproducer
+def test_reproducer_attach(self):
+# The reproducer output path. Note that this is on purpose a lower-case
+# file name. See the case-sensitivity check below.
+reproducer = self.getBuildArtifact('test.reproducer')
+try:
+shutil.rmtree(reproducer)
+except OSError:
+pass
+# Use Popen because pexpect is overkill and spawnSubprocess is
+# asynchronous.
+capture = subprocess.Popen([
+lldbtest_config.lldbExec, '-b', '--no-lldbinit', '--no-use-colors']
++ sum(map(lambda x: ['-O', x], self.setUpCommands()), [])
++ ['--capture', '--capture-path', reproducer,
+'-o', 'reproducer generate'
+],
+   stdin=subprocess.PIPE,
+   stdout=subprocess.PIPE,
+   stderr=subprocess.PIPE)
+outs, _ = capture.communicate()
+outs = outs.decode('utf-8')
+self.assertIn('Reproducer written', outs)
+
+# Read in the YAML file. We only care about a single value, so no
+# need to parse the full file.
+with open(os.path.join(reproducer, "files.yaml"), 'r') as file:
+files_yaml = file.read()
+
+# Detect the file system case sensitivity by checking if we can
+# find the reproducer path after converting it to upper case (the
+# file name is lower case before conversion, so this only works
+# on case insensitive file systems).
+case_sensitive = "false" if os.path.exists(reproducer.upper()) else 
"true"
+
+self.assertIn("'case-sensitive': '" + case_sensitive + "'", files_yaml)


Index: llvm/lib/Support/FileCollector.cpp
===
--- llvm/lib/Support/FileCollector.cpp
+++ llvm/lib/Support/FileCollector.cpp
@@ -35,7 +35,7 @@
   SmallString<256> TmpDest = Path, UpperDest, RealDest;
 
   // Remove component traversals, links, etc.
-  if (!sys::fs::real_path(Path, TmpDest))
+  if (sys::fs::real_path(Path, TmpDest))
 return true; // Current default value in vfs.yaml
   Path = TmpDest;
 
@@ -44,7 +44,7 @@
   // sensitive in the absence of real_path, since this is the YAMLVFSWriter
   // default.
   UpperDest = Path.upper();
-  if (sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
+  if (!sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
 return false;
   return true;
 }
Index: lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
===
--- /dev/null
+++ lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensit

[Lldb-commits] [lldb] f88b502 - [FileCollector] Fix that the file system case-sensitivity check was inverted

2021-02-16 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2021-02-16T20:21:32+01:00
New Revision: f88b502d9bc7c2d7db8db340d5b98fc7f46eba9c

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

LOG: [FileCollector] Fix that the file system case-sensitivity check was 
inverted

real_path returns an `std::error_code` which evaluates to `true` in case an
error happens and `false` if not. This code was checking the inverse, so
case-insensitive file systems ended up being detected as case sensitive.

Tested using an LLDB reproducer test as we anyway need a real file system and
also some matching logic to detect whether the respective file system is
case-sensitive (which the test is doing via some Python checks that we can't
really emulate with the usual FileCheck logic).

Fixes rdar://67003004

Reviewed By: JDevlieghere

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

Added: 

lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py

Modified: 
llvm/lib/Support/FileCollector.cpp

Removed: 




diff  --git 
a/lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
 
b/lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
new file mode 100644
index ..c4f832967553
--- /dev/null
+++ 
b/lldb/test/API/functionalities/reproducers/fs-case-sensitivity/TestReproducerFSCaseSensitivity.py
@@ -0,0 +1,57 @@
+"""
+Test if the reproducer correctly detects whether the file system is case 
sensitive.
+"""
+
+import lldb
+import tempfile
+from lldbsuite.test import lldbtest_config
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ReproducerFileSystemSensitivityTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipIfNetBSD
+@skipIfWindows
+@skipIfRemote
+@skipIfiOSSimulator
+@skipIfReproducer
+def test_reproducer_attach(self):
+# The reproducer output path. Note that this is on purpose a lower-case
+# file name. See the case-sensitivity check below.
+reproducer = self.getBuildArtifact('test.reproducer')
+try:
+shutil.rmtree(reproducer)
+except OSError:
+pass
+# Use Popen because pexpect is overkill and spawnSubprocess is
+# asynchronous.
+capture = subprocess.Popen([
+lldbtest_config.lldbExec, '-b', '--no-lldbinit', '--no-use-colors']
++ sum(map(lambda x: ['-O', x], self.setUpCommands()), [])
++ ['--capture', '--capture-path', reproducer,
+'-o', 'reproducer generate'
+],
+   stdin=subprocess.PIPE,
+   stdout=subprocess.PIPE,
+   stderr=subprocess.PIPE)
+outs, _ = capture.communicate()
+outs = outs.decode('utf-8')
+self.assertIn('Reproducer written', outs)
+
+# Read in the YAML file. We only care about a single value, so no
+# need to parse the full file.
+with open(os.path.join(reproducer, "files.yaml"), 'r') as file:
+files_yaml = file.read()
+
+# Detect the file system case sensitivity by checking if we can
+# find the reproducer path after converting it to upper case (the
+# file name is lower case before conversion, so this only works
+# on case insensitive file systems).
+case_sensitive = "false" if os.path.exists(reproducer.upper()) else 
"true"
+
+self.assertIn("'case-sensitive': '" + case_sensitive + "'", files_yaml)

diff  --git a/llvm/lib/Support/FileCollector.cpp 
b/llvm/lib/Support/FileCollector.cpp
index 99482075f675..7d23d036fac2 100644
--- a/llvm/lib/Support/FileCollector.cpp
+++ b/llvm/lib/Support/FileCollector.cpp
@@ -35,7 +35,7 @@ static bool isCaseSensitivePath(StringRef Path) {
   SmallString<256> TmpDest = Path, UpperDest, RealDest;
 
   // Remove component traversals, links, etc.
-  if (!sys::fs::real_path(Path, TmpDest))
+  if (sys::fs::real_path(Path, TmpDest))
 return true; // Current default value in vfs.yaml
   Path = TmpDest;
 
@@ -44,7 +44,7 @@ static bool isCaseSensitivePath(StringRef Path) {
   // sensitive in the absence of real_path, since this is the YAMLVFSWriter
   // default.
   UpperDest = Path.upper();
-  if (sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
+  if (!sys::fs::real_path(UpperDest, RealDest) && Path.equals(RealDest))
 return false;
   return true;
 }



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

[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/include/lldb/Host/HostInfoBase.h:44-46
+  using SharedLibraryDirectoryHelper = void(FileSpec &this_file);
+
+  static void Initialize(SharedLibraryDirectoryHelper *helper = nullptr);

JDevlieghere wrote:
> labath wrote:
> > JDevlieghere wrote:
> > > Why a function pointer and no `function_ref`?
> > function_ref can only be used for objects which do not escape the current 
> > function (just like StringRef), while this value is persisted. It could be 
> > a std::function, but that seems a bit overkill.
> Forgive my ignorance, but how does that apply to 
> `SharedLibraryDirectoryHelper` which is a static method? 
It doesn't -- persisting a function_ref pointing to a static method would 
actually work in this case. However, that's the _only_ thing that would work, 
so there's no benefit to doing it.
And there's the downside that if someone tries to something more fancy through 
that function_ref, it would blow up. E.g., something like this would be 
impossible
```
HostInfo::Initialize([important_variable](FileSpec &this_file) { 
do_stuff(this_file, important_variable); });
```
Because by the time that the function_ref gets called, the storage for 
`important_variable` (along with the entire lambda object) would be destroyed. 
It's exactly the same situation as with a StringRef. Imagine code like:
```
StringRef g_foo;
HostInfo::Initialize(StringRef foo) { g_foo = foo; } 
HostInfo::Stuff() { /* do something with g_foo */ }
```
This would work just fine if you always pass a string literal for the 
StringRef, but would blow up as soon as one tries to pass a temporary string. 
And there are two ways to make it safer:
- use std::string (like std::function)
- use const char * (like a raw function pointer, except function pointers are 
even safer, as dynamically allocating functions is not common)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96779

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


[Lldb-commits] [PATCH] D96779: [lldb] Fix shared library directory computation on windows

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added inline comments.



Comment at: lldb/include/lldb/Host/HostInfoBase.h:44-46
+  using SharedLibraryDirectoryHelper = void(FileSpec &this_file);
+
+  static void Initialize(SharedLibraryDirectoryHelper *helper = nullptr);

labath wrote:
> JDevlieghere wrote:
> > labath wrote:
> > > JDevlieghere wrote:
> > > > Why a function pointer and no `function_ref`?
> > > function_ref can only be used for objects which do not escape the current 
> > > function (just like StringRef), while this value is persisted. It could 
> > > be a std::function, but that seems a bit overkill.
> > Forgive my ignorance, but how does that apply to 
> > `SharedLibraryDirectoryHelper` which is a static method? 
> It doesn't -- persisting a function_ref pointing to a static method would 
> actually work in this case. However, that's the _only_ thing that would work, 
> so there's no benefit to doing it.
> And there's the downside that if someone tries to something more fancy 
> through that function_ref, it would blow up. E.g., something like this would 
> be impossible
> ```
> HostInfo::Initialize([important_variable](FileSpec &this_file) { 
> do_stuff(this_file, important_variable); });
> ```
> Because by the time that the function_ref gets called, the storage for 
> `important_variable` (along with the entire lambda object) would be 
> destroyed. It's exactly the same situation as with a StringRef. Imagine code 
> like:
> ```
> StringRef g_foo;
> HostInfo::Initialize(StringRef foo) { g_foo = foo; } 
> HostInfo::Stuff() { /* do something with g_foo */ }
> ```
> This would work just fine if you always pass a string literal for the 
> StringRef, but would blow up as soon as one tries to pass a temporary string. 
> And there are two ways to make it safer:
> - use std::string (like std::function)
> - use const char * (like a raw function pointer, except function pointers are 
> even safer, as dynamically allocating functions is not common)
Okay, sounds like we're on the same page, I misunderstood your comment as "this 
can't work for the current case" which led to the confusion on my part. I agree 
that making the interface as safe as possible is desirable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96779

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


[Lldb-commits] [PATCH] D96807: Modify TypePrinter to differentiate between anonymous struct and unnamed struct

2021-02-16 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik created this revision.
shafik added reviewers: aaron.ballman, rsmith, teemperor.
Herald added a subscriber: arphaman.
shafik requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

Currently `TypePrinter` lumps anonymous classes and unnamed classes in one 
group `"anonymous"` this is not correct and can be confusing in some contexts. 
e.g.

LLDB SBType  
provides an `IsAnonymousType()` function but when displaying the type we see 
conflicting information, given:

struct A { 
 struct { int x; }; // A
 struct { int y; } B;
  };
  
  int main() {
 A a1; 
//...
  }

we get the following in LLDB:

  (lldb) script var = lldb.frame.FindVariable("a1")
  (lldb) script print(var.GetChildAtIndex(0).GetType().IsAnonymousType())
  True
  (lldb) script print(var.GetChildAtIndex(1).GetType().IsAnonymousType())
  False
  (lldb) script print(var.GetChildAtIndex(0).GetType().GetName())
  A::(anonymous struct)
  (lldb) script print(var.GetChildAtIndex(1).GetType().GetName())
  A::(anonymous struct)


https://reviews.llvm.org/D96807

Files:
  clang/lib/AST/TypePrinter.cpp
  clang/test/AST/ast-dump-decl-json.c
  clang/test/AST/ast-dump-openmp-cancel.c
  clang/test/AST/ast-dump-openmp-cancellation-point.c
  clang/test/AST/ast-dump-openmp-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-distribute-parallel-for.c
  clang/test/AST/ast-dump-openmp-distribute-simd.c
  clang/test/AST/ast-dump-openmp-distribute.c
  clang/test/AST/ast-dump-openmp-for-simd.c
  clang/test/AST/ast-dump-openmp-for.c
  clang/test/AST/ast-dump-openmp-ordered.c
  clang/test/AST/ast-dump-openmp-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-parallel-for.c
  clang/test/AST/ast-dump-openmp-parallel-sections.c
  clang/test/AST/ast-dump-openmp-parallel.c
  clang/test/AST/ast-dump-openmp-section.c
  clang/test/AST/ast-dump-openmp-sections.c
  clang/test/AST/ast-dump-openmp-simd.c
  clang/test/AST/ast-dump-openmp-single.c
  clang/test/AST/ast-dump-openmp-target-data.c
  clang/test/AST/ast-dump-openmp-target-enter-data.c
  clang/test/AST/ast-dump-openmp-target-exit-data.c
  clang/test/AST/ast-dump-openmp-target-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-target-parallel-for.c
  clang/test/AST/ast-dump-openmp-target-parallel.c
  clang/test/AST/ast-dump-openmp-target-simd.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute-simd.c
  clang/test/AST/ast-dump-openmp-target-teams-distribute.c
  clang/test/AST/ast-dump-openmp-target-teams.c
  clang/test/AST/ast-dump-openmp-target-update.c
  clang/test/AST/ast-dump-openmp-target.c
  clang/test/AST/ast-dump-openmp-task.c
  clang/test/AST/ast-dump-openmp-taskgroup.c
  clang/test/AST/ast-dump-openmp-taskloop-simd.c
  clang/test/AST/ast-dump-openmp-taskloop.c
  clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for-simd.c
  clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for.c
  clang/test/AST/ast-dump-openmp-teams-distribute-simd.c
  clang/test/AST/ast-dump-openmp-teams-distribute.c
  clang/test/AST/ast-dump-openmp-teams.c
  clang/test/AST/ast-dump-records-json.cpp
  clang/test/AST/ast-dump-records.c
  clang/test/AST/ast-dump-records.cpp
  clang/test/AST/ast-dump-stmt-json.m
  clang/test/ASTMerge/struct/test.c
  clang/test/Analysis/cfg.cpp
  clang/test/Analysis/padding_c.c
  clang/test/Index/print-type.c
  clang/test/Layout/ms-x86-alias-avoidance-padding.cpp
  clang/test/PCH/stmt-openmp_structured_block-bit.cpp
  clang/test/Sema/assign.c
  clang/test/SemaCXX/condition.cpp
  
lldb/test/Shell/SymbolFile/DWARF/clang-ast-from-dwarf-unamed-and-anon-structs.cpp
  lldb/test/Shell/SymbolFile/DWARF/debug-types-missing-signature.test

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


[Lldb-commits] [PATCH] D96807: Modify TypePrinter to differentiate between anonymous struct and unnamed struct

2021-02-16 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added a comment.

Note: I am not fixing how we treat anonymous and unnamed enums, I could not 
find a way to figure out if an enum was anonymous or not.


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

https://reviews.llvm.org/D96807

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


[Lldb-commits] [PATCH] D95711: [lldb/Interpreter] Add ScriptInterpreter Wrapper for ScriptedProcess

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 324071.
mib added a comment.

Fixed null deref crash when unwrapping SBError opaque ptr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95711

Files:
  lldb/bindings/python/python-wrapper.swig
  lldb/include/lldb/API/SBData.h
  lldb/include/lldb/API/SBError.h
  lldb/include/lldb/API/SBThreadPlan.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/include/lldb/Interpreter/ScriptedProcessInterface.h
  lldb/include/lldb/lldb-forward.h
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Interpreter/ScriptedProcessInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  
lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
  lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Index: lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
===
--- lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -12,6 +12,7 @@
 
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h"
+#include "lldb/API/SBError.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
 
@@ -153,6 +154,14 @@
   return 0;
 }
 
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBData(void *data) {
+  return nullptr;
+}
+
+extern "C" void *LLDBSWIGPython_CastPyObjectToSBError(void *data) {
+  return nullptr;
+}
+
 extern "C" void *LLDBSWIGPython_CastPyObjectToSBValue(void *data) {
   return nullptr;
 }
@@ -207,6 +216,13 @@
   return nullptr;
 }
 
+extern "C" void *LLDBSwigPythonCreateScriptedProcess(
+const char *python_class_name, const char *session_dictionary_name,
+const lldb::TargetSP &target_sp, StructuredDataImpl *args_impl,
+std::string &error_string) {
+  return nullptr;
+}
+
 extern "C" void *
 LLDBSWIGPython_CreateFrameRecognizer(const char *python_class_name,
  const char *session_dictionary_name) {
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
===
--- /dev/null
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
@@ -0,0 +1,61 @@
+//===-- ScriptedProcessPythonInterface.h *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+#define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_SCRIPTEDPROCESSPYTHONINTERFACE_H
+
+#include "lldb/Host/Config.h"
+
+#if LLDB_ENABLE_PYTHON
+
+#include "lldb/Interpreter/ScriptedProcessInterface.h"
+
+namespace lldb_private {
+class ScriptInterpreterPythonImpl;
+class ScriptedProcessPythonInterface : public ScriptedProcessInterface {
+public:
+  ScriptedProcessPythonInterface(ScriptInterpreterPythonImpl &interpreter)
+  : ScriptedProcessInterface(), m_interpreter(interpreter) {}
+
+  StructuredData::GenericSP
+  CreatePluginObject(const llvm::StringRef class_name, lldb::TargetSP target_sp,
+ StructuredData::DictionarySP args_sp) override;
+
+  Status Launch() override;
+
+  Status Resume() override;
+
+  lldb::MemoryRegionInfoSP
+  GetMemoryRegionContainingAddress(lldb::addr_t address) override;
+
+  StructuredData::DictionarySP GetThreadWithID(lldb::tid_t tid) override;
+
+  StructuredData::DictionarySP GetRegistersForThread(lldb::tid_t tid) override;
+
+  lldb::DataExtractorSP ReadMemoryAtAddress(lldb::addr_t address, size_t size,
+Status &error) override;
+
+  StructuredData::DictionarySP GetLoadedImages() override;
+
+  lldb::pid_t GetProcessID() override;
+
+  bool IsAlive() override;
+
+protected:
+  size_t GetGenericInteger(llvm::StringRef method_name);
+  Status LaunchOrResume(llvm::StringRef method_name);
+
+private:
+  // The lifetime is managed by the ScriptInterpreter
+  ScriptInterpreterPythonImpl &m_interpreter;
+  StructuredData::GenericSP m_object_instance_sp;
+};
+} // namespace lldb_private
+
+#endi

[Lldb-commits] [PATCH] D95712: [lldb/bindings] Add Python ScriptedProcess base class to lldb module

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 324072.
mib added a comment.

Add disclaimer in the base class docstring saying that the interface is not 
stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95712

Files:
  lldb/bindings/python/CMakeLists.txt
  lldb/examples/python/scripted_process/my_scripted_process.py
  lldb/examples/python/scripted_process/scripted_process.py
  lldb/test/API/functionalities/scripted_process/Makefile
  lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
  lldb/test/API/functionalities/scripted_process/main.c

Index: lldb/test/API/functionalities/scripted_process/main.c
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/main.c
@@ -0,0 +1,5 @@
+#include 
+
+int main() {
+  return 0; // break here
+}
Index: lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/TestScriptedProcess.py
@@ -0,0 +1,45 @@
+"""
+Test python scripted process in lldb
+"""
+
+import os
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbtest
+
+
+class PlatformProcessCrashInfoTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+self.source = "main.c"
+
+def tearDown(self):
+TestBase.tearDown(self)
+
+@skipUnlessDarwin
+def test_python_plugin_package(self):
+"""Test that the lldb python module has a `plugins.scripted_process`
+package."""
+self.expect('script import lldb.plugins',
+patterns=["^((?!ModuleNotFoundError: No module named \'lldb\.plugins\').)*$"])
+
+self.expect('script dir(lldb.plugins)',
+patterns=["scripted_process"])
+
+self.expect('script import lldb.plugins.scripted_process',
+patterns=["^((?!ModuleNotFoundError: No module named \'lldb\.plugins\.scripted_process\').)*$"])
+
+self.expect('script dir(lldb.plugins.scripted_process)',
+patterns=["ScriptedProcess"])
+
+self.expect('script from lldb.plugins.scripted_process import ScriptedProcess',
+patterns=["^((?!ImportError: cannot import name \'ScriptedProcess\' from \'lldb.plugins\.scripted_process\').)*$"])
+
+self.expect('script dir(ScriptedProcess)',
+patterns=["launch"])
Index: lldb/test/API/functionalities/scripted_process/Makefile
===
--- /dev/null
+++ lldb/test/API/functionalities/scripted_process/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+
+include Makefile.rules
+
Index: lldb/examples/python/scripted_process/scripted_process.py
===
--- /dev/null
+++ lldb/examples/python/scripted_process/scripted_process.py
@@ -0,0 +1,191 @@
+from abc import ABCMeta, abstractmethod
+import six
+
+import lldb
+
+@six.add_metaclass(ABCMeta)
+class ScriptedProcess:
+
+"""
+The base class for a scripted process.
+
+Most of the base class methods are `@abstractmethod` that need to be
+overwritten by the inheriting class.
+
+DISCLAIMER: THIS INTERFACE IS STILL UNDER DEVELOPMENT AND NOT STABLE.
+THE METHODS EXPOSED MIGHT CHANGE IN THE FUTURE.
+
+Attributes:
+args (lldb.SBStructuredData): Dictionary holding arbitrary values
+loaded_images (list): List of the scripted process loaded images.
+memory_regions (list): List of the current memory regions.
+process_id (int): Scripted process identifier.
+stops (list): List of public stops.
+target (lldb.SBTarget): Target launching the scripted process.
+threads (list): List of the scripted process threads.
+
+Methods:
+get_memory_region_containing_address(addr: int) -> lldb.SBMemoryRegionInfo:
+Get the memory region for the scripted process, containing a
+specific address.
+
+get_thread_with_id(tid: int) -> Dict:
+Get the scripted process thread with a specific ID.
+
+get_registers_for_thread(tid:int) -> Dict:
+Get the register context dictionary for a certain thread.
+
+read_memory_at_address(addr:int, size:int) -> lldb.SBData:
+Get a memory buffer from the scripted process at a certain address,
+of a certain size.
+
+get_loaded_images() -> List:
+Get the list of loaded images for the scripted process.
+
+get_process_id() -> int:
+Get the scripted process identifier.
+
+launch() -> lldb.SBError:
+Simulate the script

[Lldb-commits] [PATCH] D95713: [lldb/Plugins] Add ScriptedProcess Process Plugin

2021-02-16 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib updated this revision to Diff 324075.
mib added a comment.

Update `ScriptedProcess::GetMemoryRegions` to load regions lazily.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95713

Files:
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/scripted/CMakeLists.txt
  lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp
  lldb/source/Plugins/Process/scripted/ScriptedProcess.h
  lldb/source/Target/Target.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
@@ -43,3 +43,24 @@
 
 self.expect('script dir(ScriptedProcess)',
 patterns=["launch"])
+
+@skipUnlessDarwin
+def test_launch_scripted_process(self):
+"""Test that we can launch an lldb scripted process and check its
+process ID """
+self.build()
+target = self.dbg.CreateTarget(self.getBuildArtifact("a.out"))
+self.assertTrue(target, VALID_TARGET)
+scripted_process_example_relpath = "../../../../examples/python/scripted_process/my_scripted_process.py"
+os.environ['SKIP_SCRIPTED_PROCESS_LAUNCH'] = '1'
+self.runCmd("command script import " + os.path.join(self.getSourceDir(),
+scripted_process_example_relpath))
+
+launch_info = lldb.SBLaunchInfo(None)
+launch_info.SetProcessPluginName('ScriptedProcess')
+launch_info.SetScriptedProcessClassName('my_scripted_process.MyScriptedProcess')
+
+error = lldb.SBError()
+process = target.Launch(launch_info, error)
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertEqual(process.GetProcessID(), 42)
Index: lldb/source/Target/Target.cpp
===
--- lldb/source/Target/Target.cpp
+++ lldb/source/Target/Target.cpp
@@ -2950,7 +2950,7 @@
   // If we're not already connected to the process, and if we have a platform
   // that can launch a process for debugging, go ahead and do that here.
   if (state != eStateConnected && platform_sp &&
-  platform_sp->CanDebugProcess()) {
+  platform_sp->CanDebugProcess() && !launch_info.IsScriptedProcess()) {
 LLDB_LOGF(log, "Target::%s asking the platform to debug the process",
   __FUNCTION__);
 
Index: lldb/source/Plugins/Process/scripted/ScriptedProcess.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/scripted/ScriptedProcess.h
@@ -0,0 +1,109 @@
+//===-- ScriptedProcess.h - -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+#define LLDB_SOURCE_PLUGINS_SCRIPTED_PROCESS_H
+
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/ConstString.h"
+#include "lldb/Utility/Status.h"
+
+namespace lldb_private {
+
+class ScriptedProcess : public Process {
+protected:
+  class LaunchInfo {
+  public:
+LaunchInfo(const ProcessLaunchInfo &launch_info) {
+  m_class_name = launch_info.GetScriptedProcessClassName();
+  m_dictionary_sp = launch_info.GetScriptedProcessDictionarySP();
+}
+
+std::string GetClassName() const { return m_class_name; }
+StructuredData::DictionarySP GetDictionarySP() const {
+  return m_dictionary_sp;
+}
+
+  private:
+std::string m_class_name;
+StructuredData::DictionarySP m_dictionary_sp;
+  };
+
+public:
+  static lldb::ProcessSP CreateInstance(lldb::TargetSP target_sp,
+lldb::ListenerSP listener_sp,
+const FileSpec *crash_file_path,
+bool can_connect);
+
+  static void Initialize();
+
+  static void Terminate();
+
+  static ConstString GetPluginNameStatic();
+
+  static const char *GetPluginDescriptionStatic();
+
+  ScriptedProcess(lldb::TargetSP target_sp, lldb::ListenerSP listener_sp,
+  const ScriptedProcess::LaunchInfo &launch_info);
+
+  ~ScriptedProcess() override;
+
+  bool CanDebug(lldb::TargetSP target_sp,
+bool plugin_specified_by_name) override;
+
+  DynamicLoader *GetDynamicLoader() override { return nullptr; }
+
+  ConstString GetPluginName() override;
+
+  uint32_t GetPluginVersion() override;
+
+  SystemRuntime *GetSystemRuntime() override { r

[Lldb-commits] [lldb] 1db2888 - [lldb] Remove some nanosleep preprocessor magic

2021-02-16 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2021-02-16T21:07:57+01:00
New Revision: 1db2888e70709930da6c22ab83706c7695962ace

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

LOG: [lldb] Remove some nanosleep preprocessor magic

It's obsolete, as we use (portable) std::this_thread::sleep_for now.

Added: 


Modified: 
lldb/source/Host/posix/PipePosix.cpp

Removed: 




diff  --git a/lldb/source/Host/posix/PipePosix.cpp 
b/lldb/source/Host/posix/PipePosix.cpp
index 7cd05a1ad2eb..2ccf0007a770 100644
--- a/lldb/source/Host/posix/PipePosix.cpp
+++ b/lldb/source/Host/posix/PipePosix.cpp
@@ -12,13 +12,6 @@
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/Errno.h"
 #include "llvm/Support/FileSystem.h"
-
-#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 
8))
-#ifndef _GLIBCXX_USE_NANOSLEEP
-#define _GLIBCXX_USE_NANOSLEEP
-#endif
-#endif
-
 #include 
 #include 
 



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


[Lldb-commits] [lldb] 901ea29 - [lldb] Delete superfluous semicolon

2021-02-16 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2021-02-16T21:07:58+01:00
New Revision: 901ea29662c88cb8f87d650cef2ed64a9f0d480f

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

LOG: [lldb] Delete superfluous semicolon

Added: 


Modified: 
lldb/source/Commands/CommandOptionsProcessLaunch.h

Removed: 




diff  --git a/lldb/source/Commands/CommandOptionsProcessLaunch.h 
b/lldb/source/Commands/CommandOptionsProcessLaunch.h
index 4028d8e02cb2..e0ece8a5159d 100644
--- a/lldb/source/Commands/CommandOptionsProcessLaunch.h
+++ b/lldb/source/Commands/CommandOptionsProcessLaunch.h
@@ -44,6 +44,6 @@ class CommandOptionsProcessLaunch : public 
lldb_private::Options {
   lldb_private::LazyBool disable_aslr;
 }; // CommandOptionsProcessLaunch
 
-}; // namespace lldb_private
+} // namespace lldb_private
 
 #endif // LLDB_SOURCE_COMMANDS_COMMANDOPTIONSPROCESSLAUNCH_H



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


[Lldb-commits] [PATCH] D96807: Modify TypePrinter to differentiate between anonymous struct and unnamed struct

2021-02-16 Thread Aaron Ballman via Phabricator via lldb-commits
aaron.ballman added a comment.

Thank you for working on this! In general, I like the change.




Comment at: clang/lib/AST/TypePrinter.cpp:1308
+} else if ((isa(D) && 
cast(D)->isAnonymousStructOrUnion()) ||
+isa(D)) {
   OS << "anonymous";

I think `EnumDecl` should probably be `unnamed` rather than `anonymous` because 
there's no term of art for an anonymous enumeration (there's only anonymous 
structures and anonymous unions). WDYT?


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

https://reviews.llvm.org/D96807

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


[Lldb-commits] [lldb] 9f38001 - [lldb] [Process/FreeBSD] Ensure that errors are always handled

2021-02-16 Thread Michał Górny via lldb-commits

Author: Michał Górny
Date: 2021-02-16T22:21:37+01:00
New Revision: 9f38001bf07252bc29671cf49b42351f34172dea

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

LOG: [lldb] [Process/FreeBSD] Ensure that errors are always handled

Ensure that the llvm::Error instances are always considered handled
by replacing LLDB_LOG with LLDB_LOG_ERROR.

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

Added: 


Modified: 
lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
index 10fafe675221..44797cd555c9 100644
--- a/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -213,8 +213,9 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) {
   llvm::Error error = t.CopyWatchpointsFrom(
   static_cast(*GetCurrentThread()));
   if (error) {
-LLDB_LOG(log, "failed to copy watchpoints to new thread {0}: {1}",
- info.pl_lwpid, llvm::toString(std::move(error)));
+LLDB_LOG_ERROR(log, std::move(error),
+   "failed to copy watchpoints to new thread {1}: {0}",
+   info.pl_lwpid);
 SetState(StateType::eStateInvalid);
 return;
   }



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


[Lldb-commits] [PATCH] D96558: [lldb] [Process/FreeBSD] Ensure that errors are always handled

2021-02-16 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9f38001bf072: [lldb] [Process/FreeBSD] Ensure that errors 
are always handled (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96558

Files:
  lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp


Index: lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
===
--- lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -213,8 +213,9 @@
   llvm::Error error = t.CopyWatchpointsFrom(
   static_cast(*GetCurrentThread()));
   if (error) {
-LLDB_LOG(log, "failed to copy watchpoints to new thread {0}: {1}",
- info.pl_lwpid, llvm::toString(std::move(error)));
+LLDB_LOG_ERROR(log, std::move(error),
+   "failed to copy watchpoints to new thread {1}: {0}",
+   info.pl_lwpid);
 SetState(StateType::eStateInvalid);
 return;
   }


Index: lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
===
--- lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
+++ lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
@@ -213,8 +213,9 @@
   llvm::Error error = t.CopyWatchpointsFrom(
   static_cast(*GetCurrentThread()));
   if (error) {
-LLDB_LOG(log, "failed to copy watchpoints to new thread {0}: {1}",
- info.pl_lwpid, llvm::toString(std::move(error)));
+LLDB_LOG_ERROR(log, std::move(error),
+   "failed to copy watchpoints to new thread {1}: {0}",
+   info.pl_lwpid);
 SetState(StateType::eStateInvalid);
 return;
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D96817: Fix deep copying for OptionValue classes

2021-02-16 Thread Tatyana Krasnukha via Phabricator via lldb-commits
tatyana-krasnukha created this revision.
tatyana-krasnukha added reviewers: clayborg, JDevlieghere, labath, teemperor.
tatyana-krasnukha added a project: LLDB.
Herald added a subscriber: mgorny.
tatyana-krasnukha requested review of this revision.
Herald added a subscriber: lldb-commits.

Some implementations of the DeepCopy function called the copy constructor that 
copied m_parent member instead of setting a new parent. Others just lived the 
base class's members (m_parent, m_callback, m_was_set) empty.
One more problem is that not all classes override this function, e.g. 
OptionValueArgs::DeepCopy produces OptionValueArray instance, and 
Target[Process/Thread]ValueProperty::DeepCopy produces OptionValueProperty. 
This makes downcasting via static_cast invalid.

This patch adds a virtual Clone function, which implements well-known idiom 
"virtual constructor", and overrides it in every derived class. DeepCopy calls 
Clone to instantiate an object of a correct type. It also sets valid m_parent.
Add a test that checks DeepCopy for correct copying/setting all data members of 
the base class.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96817

Files:
  lldb/include/lldb/Interpreter/OptionValue.h
  lldb/include/lldb/Interpreter/OptionValueArch.h
  lldb/include/lldb/Interpreter/OptionValueArgs.h
  lldb/include/lldb/Interpreter/OptionValueArray.h
  lldb/include/lldb/Interpreter/OptionValueBoolean.h
  lldb/include/lldb/Interpreter/OptionValueChar.h
  lldb/include/lldb/Interpreter/OptionValueDictionary.h
  lldb/include/lldb/Interpreter/OptionValueEnumeration.h
  lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
  lldb/include/lldb/Interpreter/OptionValueFileSpec.h
  lldb/include/lldb/Interpreter/OptionValueFileSpecList.h
  lldb/include/lldb/Interpreter/OptionValueFormat.h
  lldb/include/lldb/Interpreter/OptionValueFormatEntity.h
  lldb/include/lldb/Interpreter/OptionValueLanguage.h
  lldb/include/lldb/Interpreter/OptionValuePathMappings.h
  lldb/include/lldb/Interpreter/OptionValueProperties.h
  lldb/include/lldb/Interpreter/OptionValueRegex.h
  lldb/include/lldb/Interpreter/OptionValueSInt64.h
  lldb/include/lldb/Interpreter/OptionValueString.h
  lldb/include/lldb/Interpreter/OptionValueUInt64.h
  lldb/include/lldb/Interpreter/OptionValueUUID.h
  lldb/include/lldb/Target/Target.h
  lldb/source/Interpreter/OptionValue.cpp
  lldb/source/Interpreter/OptionValueArch.cpp
  lldb/source/Interpreter/OptionValueArgs.cpp
  lldb/source/Interpreter/OptionValueArray.cpp
  lldb/source/Interpreter/OptionValueBoolean.cpp
  lldb/source/Interpreter/OptionValueChar.cpp
  lldb/source/Interpreter/OptionValueDictionary.cpp
  lldb/source/Interpreter/OptionValueEnumeration.cpp
  lldb/source/Interpreter/OptionValueFileColonLine.cpp
  lldb/source/Interpreter/OptionValueFileSpec.cpp
  lldb/source/Interpreter/OptionValueFileSpecList.cpp
  lldb/source/Interpreter/OptionValueFormat.cpp
  lldb/source/Interpreter/OptionValueFormatEntity.cpp
  lldb/source/Interpreter/OptionValueLanguage.cpp
  lldb/source/Interpreter/OptionValuePathMappings.cpp
  lldb/source/Interpreter/OptionValueProperties.cpp
  lldb/source/Interpreter/OptionValueRegex.cpp
  lldb/source/Interpreter/OptionValueSInt64.cpp
  lldb/source/Interpreter/OptionValueString.cpp
  lldb/source/Interpreter/OptionValueUInt64.cpp
  lldb/source/Interpreter/OptionValueUUID.cpp
  lldb/source/Target/Process.cpp
  lldb/source/Target/Target.cpp
  lldb/source/Target/Thread.cpp
  lldb/test/API/commands/settings/TestSettings.py
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Interpreter/TestOptionValue.cpp

Index: lldb/unittests/Interpreter/TestOptionValue.cpp
===
--- /dev/null
+++ lldb/unittests/Interpreter/TestOptionValue.cpp
@@ -0,0 +1,175 @@
+//===-- TestOptionValue.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Interpreter/OptionValues.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+
+class Callback {
+public:
+  virtual void Invoke() const {}
+  void operator()() const { Invoke(); }
+};
+
+class MockCallback : public Callback {
+public:
+  MOCK_CONST_METHOD0(Invoke, void());
+};
+
+// Test a single-value class.
+TEST(OptionValueString, DeepCopy) {
+  OptionValueString str;
+  str.SetValueFromString(llvm::StringRef("ab"));
+
+  MockCallback callback;
+  str.SetValueChangedCallback([&callback] { callback(); });
+  EXPECT_CALL(callback, Invoke());
+
+  auto copy_sp = str.DeepCopy(nullptr);
+
+  // Test that the base class data members are copied/set correctly.
+  ASSERT_TRUE(copy_sp);
+  ASSERT_EQ(copy_sp->GetParent().get(), nullptr);
+  

[Lldb-commits] [PATCH] D96548: [lldb] [Process/FreeBSDRemote] Introduce aarch64 hw break/watchpoint support [WIP]

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



Comment at: 
lldb/source/Plugins/Process/FreeBSD/NativeRegisterContextFreeBSD_arm64.h:62-63
   std::array m_reg_data;
+  dbreg m_dbreg;
+  bool m_read_dbreg;
 

labath wrote:
> maybe Optional
Tried it but it feels really artificial here. I think the `bool` is both 
cleaner and results in less code.


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

https://reviews.llvm.org/D96548

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


[Lldb-commits] [PATCH] D96623: [lldb-vscode] Fix lldb init file stdout issue

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

After thinking about this a bit more, it seems a mistake that we can't change 
the file handles _prior_ to sourcing the init files. I have proposed one 
solution in the inline comments to create a new SBDebugger::Create() method 
that takes the input output and error file handles as arguments. The other way 
to do this is to make it so that we _can_ run the init files later. Currently 
if we say "false" to "bool source_init_files", then the command interpreter 
marks the init files as not being able to be run again later if you call the 
SBCommandInterpreter::SourceInitFileInHomeDirectory(...). So we need to either 
be able to either specify the file handles at debugger creation time, or run 
them one time later. The current "run them once" means "you can only do this at 
debugger creation time, but never again if you specify false for 
source_init_files. We can change this to be "only run the init files once. so 
if we already run them in SBDebugger::Create(), then don't run them again if 
you call SBCommandInterpreter::SourceInitFileInHomeDirectory()




Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:1444
+  // call SourceInitFile() below after dev_null redirection.
+  g_vsc.debugger = lldb::SBDebugger::Create(false /*source_init_files*/);
+

So after thinking about this some more, it might be better to add a new 
lldb::SBDebugger::Create method that takes the input, output and error handles 
as SBFile objects. This will allow us to not have to duplicate the entire 
.lldbinit loading stuff in this patch. My proposal would be to add a new create 
method:

```
lldb::SBDebugger lldb::SBDebugger::Create(bool source_init_files, SBFile input, 
SBFile output, SBFile error);
```
SBFile has multiple constructors that will work for us:
```
SBFile()
SBFile(FILE *file, bool transfer_ownership);
SBFile(int fd, const char *mode, bool transfer_ownership);
```
If we default construct a SBFile, it will contain no valid shared pointer in 
the private "FileSP m_opaque_sp;" member. Any of the SBFile objects that are 
not valid, won't end up being set in the debugger. All valid file handles will 
be set _prior_ to sourcing the init files, and then we can avoid any problems.

in the SBDebugger.cpp you would do something like:
```
lldb::SBDebugger lldb::SBDebugger::Create(bool source_init_files, SBFile input, 
SBFile output, SBFile error) {

  static std::recursive_mutex g_mutex;
  std::lock_guard guard(g_mutex);
  debugger.reset(Debugger::CreateInstance(callback, baton));
  if (input.IsValid())
debugger.SetInputFile(input);
  if (output.IsValid())
debugger.SetOutputFile(output):
  if (error.IsValid())
debugger.SetErrorFile(error);
  SBCommandInterpreter interp = debugger.GetCommandInterpreter();
  if (source_init_files) {
interp.get()->SkipLLDBInitFiles(false);
interp.get()->SkipAppInitFiles(false);
SBCommandReturnObject result;
interp.SourceInitFileInHomeDirectory(result, false);
  } else {
interp.get()->SkipLLDBInitFiles(true);
interp.get()->SkipAppInitFiles(true);
  }
  return debugger;
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96623

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


[Lldb-commits] [PATCH] D96623: [lldb-vscode] Fix lldb init file stdout issue

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

I added Jim and Pavel to get some more feedback.

The main issue is the Visual Studio Code debug adaptors like lldb-vscode 
receive and send packets on STDIN and STDOUT. The debugger is created during 
the "initialize" request which expects a response. If the debugger tries to run 
the init files when the debugger is created, it risks outputting some info to 
STDOUT and causing the entire debug session to fail the stdout is the default 
output file handle for debuggers. If you don't run the init files, they are 
marked as skipped in the command interpreter and calling 
SBCommandInterpreter::SourceInitFileInHomeDirectory(...) will do nothing if you 
call it later.

A further complication of this patch is that we intend to support different 
LLDB.framework binaries in order to support Swift debugging in the future by 
setting a DYLD_FRAMEWORK_PATH in the environment of lldb-vscode when it is 
launched so we can use the LLDB.framework (or liblldb.so for linux) that 
matches the swift we need. This means that if we change the API by adding the 
new lldb::SBDebugger::Create() method that takes the SBFile handles for 
in/out/error, then we can't use these older LLDB versions since it will crash 
when it doesn't find this new create method. The current version of this patch 
does actually allow us to use these older LLDB.framework binaries, though it 
does duplicate the running of the init files manually. So maybe this is the 
best option for now, but I wanted to include a few other people to get their 
input.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96623

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


[Lldb-commits] [PATCH] D96817: Fix deep copying for OptionValue classes

2021-02-16 Thread David Blaikie via Phabricator via lldb-commits
dblaikie added a comment.

Perhaps all these clone implementations could be provided via mixin instead?

  struct base {
virtual std::shared_ptr Clone() = 0;
...
  };
  template
  struct base_clone_helper : IntermediateBase {
static_assert(std::is_base_of::value);
std::shared_ptr Clone() const override {
  return std::make_shared(static_cast(*this*));
}
  };
  struct some_immediate_derivation final : 
base_clone_helper {
  };
  struct some_intermediate_helper : base {
...
  };
  struct some_concrete_derivation final : 
base_clone_helper {
  };

Requiring that all such types be copy constructible (I guess the template 
helper could also provide an rvalue overload of Clone if there's a need to have 
move cloning, though that seems unlikely to be needed/useful)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96817

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


[Lldb-commits] [PATCH] D96817: Fix deep copying for OptionValue classes

2021-02-16 Thread David Blaikie via Phabricator via lldb-commits
dblaikie added inline comments.



Comment at: lldb/unittests/Interpreter/TestOptionValue.cpp:173
+  // Trigger the callback second time.
+  file_list_copy_ptr->SetValueFromString(llvm::StringRef("0 another/path"),
+ eVarSetOperationReplace);

Generally it shouldn't be necessary to write `llvm::StringRef(...)` around a 
string literal - StringRef is implicitly convertible from a string literal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96817

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

In D96778#2566208 , @dblaikie wrote:

> I expect it'd be good to have a test case showing the sort of DWARF that DWZ 
> produces for cross-CU references of enumerators.

There is a testcase in D91014 : 
lldb/test/Shell/SymbolFile/DWARF/DW_AT_decl_file-DW_AT_specification-crosscu.s
There is no testcase in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread David Blaikie via Phabricator via lldb-commits
dblaikie added a comment.

In D96778#2567255 , @jankratochvil 
wrote:

> In D96778#2566208 , @dblaikie wrote:
>
>> I expect it'd be good to have a test case showing the sort of DWARF that DWZ 
>> produces for cross-CU references of enumerators.
>
> There is a testcase in D91014 : 
> lldb/test/Shell/SymbolFile/DWARF/DW_AT_decl_file-DW_AT_specification-crosscu.s
> There is no testcase in this patch.

That tests some other cross-cu references, but if it was testing the changes in 
this patch, wouldn't the test be failing (& I guess it isn't)?

So seems like more test coverage might be in order? (Either in another test 
file, or as an addition to the existing one)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96778: [lldb] Fix handling of `DW_AT_decl_file` according to D91014

2021-02-16 Thread Jan Kratochvil via Phabricator via lldb-commits
jankratochvil added a comment.

In D96778#2567261 , @dblaikie wrote:

> That tests some other cross-cu references, but if it was testing the changes 
> in this patch, wouldn't the test be failing (& I guess it isn't)?

It isn't testing the specific cross-CU case of this patch.

> So seems like more test coverage might be in order? (Either in another test 
> file, or as an addition to the existing one)

Yes, I will try to extend/write one (or @werat can :-) ).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96778

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


[Lldb-commits] [PATCH] D96637: Make sure the interpreter module was loaded before making checks against it

2021-02-16 Thread António Afonso via Phabricator via lldb-commits
aadsm added a comment.

> We should have a test for this.

how do you recommend doing this? I spent a couple of hours on this but got no 
where. From what I understood we should prefer lit tests, so I was thinking of 
creating a binary that dlopens a module. However, I wasn't able to create a 
binary that I can start and capture its pid address so that I can attach to. 
Here's what I've tried so far:

  // RUN: cp %s %s.cpp
  // RUN: %clang -g -O0 --target=x86_64-linux-gnu %s.cpp -o %s.out
  // RUN: PID=$(%s.out)
  // RUN: %lldb -p $PID -b -o 'target list' | FileCheck %s
  // RUN: kill -9 $PID
  // CHECK: foo
  
  #include 
  #include 
  
  int main() {
  pid_t pid = fork();
  if (pid > 0) {
  // parent process, print child pid
  printf("%d", pid);
  return 0;
  } else if (pid < 0) {
  printf("Unable to fork\n");
  return -1;
  }
  // child process
  pause();
  }

The lit test get stuck on `// RUN: PID=$(%s.out)`. Not sure why, the parent 
process shouldn't wait on its children..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96637

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


[Lldb-commits] [PATCH] D96829: Add "Undeclared registers are marked as Undefined" to UnwindPlan, adopt it in arch default unwind plans

2021-02-16 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda created this revision.
jasonmolenda added a reviewer: labath.
jasonmolenda added a project: LLDB.
Herald added subscribers: JDevlieghere, pengfei, atanasyan, jrtc27, kbarton, 
kristof.beyls, nemanjai, sdardis.
jasonmolenda requested review of this revision.

The ABI plugins can provide an architectural default unwind plan -- an 
UnwindPlan that will get you up the stack when you don't have any unwind 
information or function start addresses.  The unwinder uses these arch default 
unwind plans in two cases:  No information for this stack frame, or as a fast 
unwind plan to walk the stack quickly, when you're not retrieving additional 
registers.  (the unwinder will often also try this as a "fallback" unwind plan 
when it thinks there might be more stack to discover, giving us the 
ever-awesome double-start() that we see on Darwin processes at the end of the 
backtrace, sigh)

The big important use of an arch default unwind plan is jitted code -- where 
lldb doesn't have any start addresses for the functions or unwind information.  
We can't detect where registers are spilled to the stack, but at least we can 
walk the stack.

However, when we have a stack 5 frames deep,

0  func1()
1  func2()
2  
3  func3()
4  main()

If we navigate to frame 3 (func3) and say "p/x $r12", lldb will descend down 
the stack (ultimately to frame 0, func1) looking for a place where r12 was 
saved to stack before it was reused.  If no saves/spills are found, the live 
r12 value in frame 0 is used.

The problem here is that we have no view into what happened in frame 2, the 
jitted code.  It may have spilled r12 and modified the register.  The rule in 
lldb is that we don't provide register values that are *possibly* modified -- 
the same reason why lldb won't pass caller-spilled aka volatile register values 
up the stack, e.g. rax on SysV x86_64, where a function is free to modify it 
without saving the old value.  We cannot be sure that the value of these 
registers haven't been changed, so lldb will refuse to print $rax for frame 3 
in this backtrace.

This patchset adds a new bool to UnwindPlan::Row which specifies that any 
register not explicitly defined should return as Undefined.  This means that 
the saved-register-finder method should NOT continue down the stack looking for 
a saved value - we cannot know what happened in this stack frame, so it's not 
safe to continue searching and pass a register value up the stack.

The second use case of the arch default UnwindPlan is as a "fast Unwind Plan" 
when lldb only needs to retrieve frame pointer & pc values when doing a quick 
stack walk.  In this case, when lldb is searching for a register in 
RegisterContextUnwind::SavedLocationForRegister, it first tries the fast unwind 
plan, and if the register isn't mentioned there, it tries to find a location in 
the Full unwind plan.  I have one small modification here to treat an Undefined 
register in the *fast* unwind plan as meaning that we should look in the full 
unwind plan, instead of stopping here.  The full unwind plan may have a real 
register save location; if it says the register is Undefined, then that will be 
used.

The big risk with this patch, obviously, is that I'm updating all of the 
architectural default unwind plans to mark undefined registers as unavailable.  
I worry that there's some target that is relying on architectural default 
unwind plans heavily and previously the frame 0 register values were passed up 
the stack ... and maybe it was right sometimes, but now lldb won't send them up 
any more.  I'll need to watch the bots closely when this lands.  I could have 
done the cowardly thing and only updated the SysV x86_64 and Darwin AArch64 ABI 
plugins, but this is a change I've been wanting to make for a while.

Testing this is something I don't have a good answer for.  I could unit-test 
that the SysV x86_64 ABI's arch default UnwindPlan sets 
SetUnspecifiedRegistersAreUndefined, but that's not anything really useful.  
Until recently you could jit an expression that stopped at a breakpoint and 
you'd have a wonderfully unsymbolicated stack frame in the middle of the 
backtrace but some rascal like Raphael seems to have changed it so we have a 
Module for the jitted code with a function start address recently. :/  Short of 
a corefile or a test using a scripted process plugin (basically the same 
thing), I don't think I can simulate the use case here.  On the up side, bugs 
show up real fast in the testsuite run as I found when I didn't originally 
remember how the fast unwind plan fallback needed to work when I wrote this 
patch. :)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96829

Files:
  lldb/include/lldb/Symbol/UnwindPlan.h
  lldb/source/Plugins/ABI/AArch64/ABIMacOSX_arm64.cpp
  lldb/source/Plugins/ABI/AArch64/ABISysV_arm64.cpp
  lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
  lldb/source/Plugins/ABI/ARM/ABISysV_arm.cpp
  lldb/source/Plugins/ABI/Hexagon/ABISysV_

[Lldb-commits] [PATCH] D96833: [lldb] Print a useful error message when trying to import modules with dots or dashes

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: labath, kastiglione, mib.
JDevlieghere requested review of this revision.

LLDB does not like to import Python files with dashes or dots in their name. 
While the former are technically allowed, they're discouraged [1]. Dots are 
allowed for subpackages but not in module names. This patch improves the user 
experience by printing a useful error.

Currently lldb prints:

  error: module importing failed: SyntaxError('invalid syntax', ('', 1, 
11, 'import foo-bar\n'))

After this patch:

  error: module importing failed: Python discourages dashes in module 
specification: foo-bar


https://reviews.llvm.org/D96833

Files:
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/test/Shell/ScriptInterpreter/Python/command_import.test


Index: lldb/test/Shell/ScriptInterpreter/Python/command_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/command_import.test
@@ -0,0 +1,20 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: echo "print('Rene Magritte')" >> %t/foo.py
+# RUN: echo "print('Jan van Eyck')" >> %t/foo-bar.py
+# RUN: echo "print('Pieter Bruegel the Elder')" >> %t/foo.bar.py
+# RUN: echo "print('Pieter Bruegel the Younger')" >> %t/foo.bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.py' 
2>&1 | FileCheck %s --check-prefix MAGRITTE
+# MAGRITTE: Rene Magritte
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo-bar.py' 
2>&1 | FileCheck %s --check-prefix VANEYCK
+# VANEYCK-NOT: Jan van Eyck
+# VANEYCK: module importing failed: Python discourages dashes in module 
specification: foo-bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar.py' 
2>&1 | FileCheck %s --check-prefix BRUEGEL
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar' 
2>&1 | FileCheck %s --check-prefix BRUEGEL
+# BRUEGEL-NOT: Pieter Bruegel the Elder
+# BRUEGEL-NOT: Pieter Bruegel the Younger
+# BRUEGEL: module importing failed: Python does not allow dots in module 
specification: foo.bar
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2781,6 +2781,7 @@
   };
 
   std::string module_name(pathname);
+  bool possible_package = false;
 
   if (extra_search_dir) {
 if (llvm::Error e = ExtendSysPath(extra_search_dir.GetPath())) {
@@ -2805,6 +2806,7 @@
 return false;
   }
   // Not a filename, probably a package of some sort, let it go through.
+  possible_package = true;
 } else if (is_directory(st) || is_regular_file(st)) {
   if (module_file.GetDirectory().IsEmpty()) {
 error.SetErrorString("invalid directory name");
@@ -2831,6 +2833,20 @@
   module_name.resize(module_name.length() - 4);
   }
 
+  if (!possible_package && module_name.find('.') != llvm::StringRef::npos) {
+error.SetErrorStringWithFormat(
+"Python does not allow dots in module specification: %s",
+module_name.c_str());
+return false;
+  }
+
+  if (module_name.find('-') != llvm::StringRef::npos) {
+error.SetErrorStringWithFormat(
+"Python discourages dashes in module specification: %s",
+module_name.c_str());
+return false;
+  }
+
   // check if the module is already import-ed
   StreamString command_stream;
   command_stream.Clear();


Index: lldb/test/Shell/ScriptInterpreter/Python/command_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/command_import.test
@@ -0,0 +1,20 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: echo "print('Rene Magritte')" >> %t/foo.py
+# RUN: echo "print('Jan van Eyck')" >> %t/foo-bar.py
+# RUN: echo "print('Pieter Bruegel the Elder')" >> %t/foo.bar.py
+# RUN: echo "print('Pieter Bruegel the Younger')" >> %t/foo.bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.py' 2>&1 | FileCheck %s --check-prefix MAGRITTE
+# MAGRITTE: Rene Magritte
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo-bar.py' 2>&1 | FileCheck %s --check-prefix VANEYCK
+# VANEYCK-NOT: Jan van Eyck
+# VANEYCK: module importing failed: Python discourages dashes in module specification: foo-bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar.py' 2>&1 | FileCheck %s --check-prefix BRUEGEL
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar' 2>&1 | FileCheck %s --check-prefix BRUEGEL
+# BRUEGEL-NOT: Pieter Bruegel the Elder
+# BRUEGEL-NOT: Pieter Bruegel the Younger
+# BRUEGEL: module importing failed: Python does not allow dots in module specif

[Lldb-commits] [PATCH] D96833: [lldb] Print a useful error message when trying to import modules with dots or dashes

2021-02-16 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 324169.
JDevlieghere edited the summary of this revision.
JDevlieghere added a comment.

module specification -> module names


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

https://reviews.llvm.org/D96833

Files:
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/test/Shell/ScriptInterpreter/Python/command_import.test


Index: lldb/test/Shell/ScriptInterpreter/Python/command_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/command_import.test
@@ -0,0 +1,20 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: echo "print('Rene Magritte')" >> %t/foo.py
+# RUN: echo "print('Jan van Eyck')" >> %t/foo-bar.py
+# RUN: echo "print('Pieter Bruegel the Elder')" >> %t/foo.bar.py
+# RUN: echo "print('Pieter Bruegel the Younger')" >> %t/foo.bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.py' 
2>&1 | FileCheck %s --check-prefix MAGRITTE
+# MAGRITTE: Rene Magritte
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo-bar.py' 
2>&1 | FileCheck %s --check-prefix VANEYCK
+# VANEYCK-NOT: Jan van Eyck
+# VANEYCK: module importing failed: Python discourages dashes in module names: 
foo-bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar.py' 
2>&1 | FileCheck %s --check-prefix BRUEGEL
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar' 
2>&1 | FileCheck %s --check-prefix BRUEGEL
+# BRUEGEL-NOT: Pieter Bruegel the Elder
+# BRUEGEL-NOT: Pieter Bruegel the Younger
+# BRUEGEL: module importing failed: Python does not allow dots in module 
names: foo.bar
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2781,6 +2781,7 @@
   };
 
   std::string module_name(pathname);
+  bool possible_package = false;
 
   if (extra_search_dir) {
 if (llvm::Error e = ExtendSysPath(extra_search_dir.GetPath())) {
@@ -2805,6 +2806,7 @@
 return false;
   }
   // Not a filename, probably a package of some sort, let it go through.
+  possible_package = true;
 } else if (is_directory(st) || is_regular_file(st)) {
   if (module_file.GetDirectory().IsEmpty()) {
 error.SetErrorString("invalid directory name");
@@ -2831,6 +2833,20 @@
   module_name.resize(module_name.length() - 4);
   }
 
+  if (!possible_package && module_name.find('.') != llvm::StringRef::npos) {
+error.SetErrorStringWithFormat(
+"Python does not allow dots in module names: %s",
+module_name.c_str());
+return false;
+  }
+
+  if (module_name.find('-') != llvm::StringRef::npos) {
+error.SetErrorStringWithFormat(
+"Python discourages dashes in module names: %s",
+module_name.c_str());
+return false;
+  }
+
   // check if the module is already import-ed
   StreamString command_stream;
   command_stream.Clear();


Index: lldb/test/Shell/ScriptInterpreter/Python/command_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/command_import.test
@@ -0,0 +1,20 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: echo "print('Rene Magritte')" >> %t/foo.py
+# RUN: echo "print('Jan van Eyck')" >> %t/foo-bar.py
+# RUN: echo "print('Pieter Bruegel the Elder')" >> %t/foo.bar.py
+# RUN: echo "print('Pieter Bruegel the Younger')" >> %t/foo.bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.py' 2>&1 | FileCheck %s --check-prefix MAGRITTE
+# MAGRITTE: Rene Magritte
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo-bar.py' 2>&1 | FileCheck %s --check-prefix VANEYCK
+# VANEYCK-NOT: Jan van Eyck
+# VANEYCK: module importing failed: Python discourages dashes in module names: foo-bar
+
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar.py' 2>&1 | FileCheck %s --check-prefix BRUEGEL
+# RUN: %lldb --script-language python -o 'command script import %t/foo.bar' 2>&1 | FileCheck %s --check-prefix BRUEGEL
+# BRUEGEL-NOT: Pieter Bruegel the Elder
+# BRUEGEL-NOT: Pieter Bruegel the Younger
+# BRUEGEL: module importing failed: Python does not allow dots in module names: foo.bar
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2781,6 +2781,7 @@
   };
 
   std::string module_name(pathname);
+  bool possible_package = false;
 
   if (extra_search_dir) {
 if (llvm:

[Lldb-commits] [PATCH] D96833: [lldb] Print a useful error message when trying to import modules with dots or dashes

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

FWIW I played around with `__import__` and `importlib.import_module` which does 
allow you to import modules with dashes, but unlike `import` it doesn't add 
them to the globals. I'm sure there's a way around that, but it didn't seem 
worth to additional complexity.


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

https://reviews.llvm.org/D96833

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


[Lldb-commits] [PATCH] D96829: Add "Undeclared registers are marked as Undefined" to UnwindPlan, adopt it in arch default unwind plans

2021-02-16 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added a comment.

I marked Pavel as the reviewer for this because he's maybe the most likely to 
have an opinion about this change; I don't mean to sign you up for review work 
if you don't have time right now.  I don't know if the specifics of the patch 
are especially interesting, but the testability problem and the decision to 
update all of the arch default unwind plans seem the most notable/discussable 
to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96829

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


[Lldb-commits] [PATCH] D96829: Add "Undeclared registers are marked as Undefined" to UnwindPlan, adopt it in arch default unwind plans

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

Makes sense, LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96829

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


[Lldb-commits] [PATCH] D96839: Add a callout to the LanguageRuntime to override the normal UnwindPlan used for a frame

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

Swift is gaining asynchronous functions, which may not be executing when a 
function they call is executing.  In the backtrace, we want to show the logical 
caller of this currently-executing function even though it is not present on 
the stack like a real frame.  The LanguageRuntime can provide an UnwindPlan 
that will provide that function.

When the async function is actually executing, we'll use its normal 
UnwindPlans.  But when it is not executing, we'll use the LanguageRuntime's 
UnwindPlan to show it in the stack.

The way this is actually implemented by the swift runtime is that the stack has 
a chain of these async-not-running functions and pointers to a data block with 
saved context for them, and as we walk the chain we will get back to real stack 
functions again.  The swift language runtime uses a flag in the spilled fp 
register to tell when it should provide its special unwind plan.

This patch adds code to LanguageRuntime to see if any LanguageRuntime plugins 
can provide an UnwindPlan given a RegisterContext.  It adds code to 
RegisterContextUnwind to see if the LanguageRuntime can provide an UnwindPlan 
before we start looking at the function's normal UnwindPlans, and uses the 
async unwind plan if it was provided.  Pretty simple hooks out to the 
LanguageRuntime where the details are encapsulated.

Without interjecting a LanguageRuntime plugin in a live debug session, this 
isn't testable in standard lldb; in the swift branch of lldb I can have an API 
test that has some async calls on the stack and do a stack walk.  But I need 
the LanguageRuntimeSwift support for one of these to get that to work.

Open to any comments or suggestions, not sure if anyone is really into the 
unwinder enough to spend time reviewing it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96839

Files:
  lldb/include/lldb/Target/LanguageRuntime.h
  lldb/source/Target/LanguageRuntime.cpp
  lldb/source/Target/RegisterContextUnwind.cpp

Index: lldb/source/Target/RegisterContextUnwind.cpp
===
--- lldb/source/Target/RegisterContextUnwind.cpp
+++ lldb/source/Target/RegisterContextUnwind.cpp
@@ -24,6 +24,7 @@
 #include "lldb/Target/ABI.h"
 #include "lldb/Target/DynamicLoader.h"
 #include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/LanguageRuntime.h"
 #include "lldb/Target/Platform.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -283,6 +284,24 @@
 return;
   }
 
+  ExecutionContext exe_ctx(m_thread.shared_from_this());
+  Process *process = exe_ctx.GetProcessPtr();
+
+  // Some languages may have a logical parent stack frame which is
+  // not a real stack frame, but the programmer would consider it to
+  // be the caller of the frame, e.g. Swift asynchronous frames.
+  //
+  // A Swift async function will have a normal UnwindPlan when it is 
+  // executing, but it may be unscheduled (or on a different thread)
+  // when the function it calls asynchronously, and we need to use an
+  // UnwindPlan from the LanguageRuntime to present this frame to the
+  // user in the backtrace.
+  UnwindPlanSP async_plan_sp =
+  LanguageRuntime::GetAsyncedFrameUnwindPlan(m_thread, this);
+  if (async_plan_sp.get()) {
+UnwindLogMsg("This is an async frame");
+  }
+
   addr_t pc;
   if (!ReadGPRValue(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC, pc)) {
 UnwindLogMsg("could not get pc value");
@@ -290,8 +309,6 @@
 return;
   }
 
-  ExecutionContext exe_ctx(m_thread.shared_from_this());
-  Process *process = exe_ctx.GetProcessPtr();
   // Let ABIs fixup code addresses to make sure they are valid. In ARM ABIs
   // this will strip bit zero in case we read a PC from memory or from the LR.
   ABI *abi = process->GetABI().get();
@@ -522,12 +539,42 @@
 }
   }
 
-  // We've set m_frame_type and m_sym_ctx before this call.
-  m_fast_unwind_plan_sp = GetFastUnwindPlanForFrame();
-
   UnwindPlan::RowSP active_row;
   RegisterKind row_register_kind = eRegisterKindGeneric;
 
+  // If we have an asynchronous unwind plan from the LanguageRuntime,
+  // use those rules to find the caller frame instead of the function's
+  // normal UnwindPlans.  The full unwind plan for this frame will be
+  // the LanguageRuntime-provided unwind plan, and there will not be a
+  // fast unwind plan.
+  if (async_plan_sp.get()) {
+active_row = async_plan_sp->GetRowForFunctionOffset(m_current_offset);
+row_register_kind = async_plan_sp->GetRegisterKind();
+if (!ReadFrameAddress(row_register_kind, active_row->GetCFAValue(),
+  m_cfa)) {
+  UnwindLogMsg("Cannot set cfa");
+} else {
+  m_full_unwind_plan_sp = async_plan_sp;
+  if (active_row.get() && log) {
+Str

[Lldb-commits] [PATCH] D96840: [LLDB] [docs] Update the list of supported architectures on Windows

2021-02-16 Thread Martin Storsjö via Phabricator via lldb-commits
mstorsjo created this revision.
mstorsjo added reviewers: labath, amccarth.
Herald added subscribers: pengfei, arphaman, kristof.beyls.
mstorsjo requested review of this revision.
Herald added a project: LLDB.

It was pointed out to me that the docs previously only said i386 was supported, 
while I'd expect that at least x86_64 is on the same level, and AArch64 should 
work pretty well for basic things at least.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96840

Files:
  lldb/docs/index.rst


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -74,10 +74,11 @@
 * iOS, tvOS, and watchOS device debugging on ARM and AArch64
 * Linux user-space debugging for i386, x86_64 and PPC64le
 * FreeBSD user-space debugging for i386 and x86_64
-* Windows user-space debugging for i386 (*)
+* Windows user-space debugging for i386, x86_64, ARM and AArch64 (*)
 
 (*) Support for Windows is under active development. Basic functionality is
-expected to work, with functionality improving rapidly.
+expected to work, with functionality improving rapidly. ARM support is
+more experimmental, with more known issues than the others.
 
 Get Involved
 


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -74,10 +74,11 @@
 * iOS, tvOS, and watchOS device debugging on ARM and AArch64
 * Linux user-space debugging for i386, x86_64 and PPC64le
 * FreeBSD user-space debugging for i386 and x86_64
-* Windows user-space debugging for i386 (*)
+* Windows user-space debugging for i386, x86_64, ARM and AArch64 (*)
 
 (*) Support for Windows is under active development. Basic functionality is
-expected to work, with functionality improving rapidly.
+expected to work, with functionality improving rapidly. ARM support is
+more experimmental, with more known issues than the others.
 
 Get Involved
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D96807: Modify TypePrinter to differentiate between anonymous struct and unnamed struct

2021-02-16 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment.

LGTM.

Regarding the LLDB example: Given that the LLDB API is in theory not bound to 
the semantics a specific language, I think one can argue that `IsAnonymousType` 
could also return true for unnamed classes. The use case that triggered this 
whole discussion was someone who wanted to know whether the type has a name, so 
calling this function seems logical. Given that we don't really have a valid 
type name for unnamed classes, we might want to change the implementation of 
`IsAnonymousType` to also return true for unnamed classes. But all that is out 
of scope for this patch which is about fixing the type printer in Clang. Just 
bringing this up as it's the example in the patch description.


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

https://reviews.llvm.org/D96807

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