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

[Nitesh Jain via Phabricator via lldb-commits]

nitesh.jain added a comment.

In D96766#2596701 , @labath wrote:

> Hm I'm very tempted to delete the linux mips implementation -- it uses 
> several techniques which are getting in the way of this patch (and also some 
> others in the past), for a lot of those, we now have different/better ways of 
> doing it. On top of that, it's completely unmaintained (last non-nfc change 
> to the file was in 2017, and the author (@nitesh.jain) does not appear to be 
> active anymore.

Hi Labath,

As you notice, we no longer work for MIPS and not sure who is the current 
maintainer for the same.


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

https://reviews.llvm.org/D96766

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

[Lldb-commits] [PATCH] D97721: [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In D97721#2598798 , @kwk wrote:

> @jankratochvil out of curiosity. Can you give a pointer to what the C program 
> looks like that produces the object code?

  int main() {}
  Fedora Rawhide: gcc -o main.s main.c -gdwarf-5 -S -gno-as-loc-support -dA

But it is hand edited, Besides DWARF simplification I removed the .text 
assembly instructions (and put `.long 0` there) to make it arch-independent 
which was my original intention. But then I remember the DWARF assembly is not 
fully arch-independent anyway so to prevent some false failures in buildbots 
again I kept there that `# REQUIRES: x86` anyway. One could try to remove the 
REQUIRES if one really wanted to test the bots. Still I am not sure if it did 
not cause any buildbots failure as the buildbots are down these days, incl. 
Apple Green Bot.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97721

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

[Lldb-commits] [lldb] db8b159 - [lldb] Inline objc_opt->version >= 14 to avoid dealing with bool type

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2021-03-02T16:41:44-08:00
New Revision: db8b1598b7187ff378b7b82c266d1993b0a39191

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

LOG: [lldb] Inline objc_opt->version >= 14 to avoid dealing with bool type

Added: 


Modified: 

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index 90ef5e1c7403..30ee257f2b29 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -247,8 +247,7 @@ __lldb_apple_objc_v2_get_shared_cache_class_info (void 
*objc_opt_ro_ptr,
 {
 const objc_opt_t *objc_opt = (objc_opt_t *)objc_opt_ro_ptr;
 const objc_opt_v14_t* objc_opt_v14 = (objc_opt_v14_t*)objc_opt_ro_ptr;
-const bool is_v14_format = objc_opt->version >= 14;
-if (is_v14_format)
+if (objc_opt->version >= 14)
 {
 DEBUG_PRINTF ("objc_opt->version = %u\n", objc_opt_v14->version);
 DEBUG_PRINTF ("objc_opt->flags = %u\n", objc_opt_v14->flags);
@@ -266,7 +265,7 @@ __lldb_apple_objc_v2_get_shared_cache_class_info (void 
*objc_opt_ro_ptr,
 if (objc_opt->version == 12 || objc_opt->version == 13 || 
objc_opt->version == 14 || objc_opt->version == 15)
 {
 const objc_clsopt_t* clsopt = NULL;
-if (is_v14_format)
+if (objc_opt->version >= 14)
 clsopt = (const objc_clsopt_t*)((uint8_t *)objc_opt_v14 + 
objc_opt_v14->clsopt_offset);
 else
 clsopt = (const objc_clsopt_t*)((uint8_t *)objc_opt + 
objc_opt->clsopt_offset);



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

[Lldb-commits] [lldb] c85d47f - [lldb] Add more logging to __lldb_apple_objc_v2_get_dynamic_class_info

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2021-03-02T16:24:59-08:00
New Revision: c85d47f7b821a5e9030dffa6613f6257c5f39446

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

LOG: [lldb] Add more logging to __lldb_apple_objc_v2_get_dynamic_class_info

Added: 


Modified: 

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
index e3b15f0ae8a8..90ef5e1c7403 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
@@ -121,14 +121,20 @@ __lldb_apple_objc_v2_get_dynamic_class_info (void 
*gdb_objc_realized_classes_ptr
 if (grc)
 {
 const unsigned num_classes = grc->num_classes;
+DEBUG_PRINTF ("num_classes = %u\n", grc->num_classes);
 if (class_infos_ptr)
 {
+const unsigned num_buckets_minus_one = grc->num_buckets_minus_one;
+DEBUG_PRINTF ("num_buckets_minus_one = %u\n", 
num_buckets_minus_one);
+
 const size_t max_class_infos = 
class_infos_byte_size/sizeof(ClassInfo);
+DEBUG_PRINTF ("max_class_infos = %u\n", max_class_infos);
+
 ClassInfo *class_infos = (ClassInfo *)class_infos_ptr;
 BucketInfo *buckets = (BucketInfo *)grc->buckets;
-
+
 uint32_t idx = 0;
-for (unsigned i=0; i<=grc->num_buckets_minus_one; ++i)
+for (unsigned i=0; i<=num_buckets_minus_one; ++i)
 {
 if (buckets[i].name_ptr != NX_MAPNOTAKEY)
 {
@@ -140,6 +146,7 @@ __lldb_apple_objc_v2_get_dynamic_class_info (void 
*gdb_objc_realized_classes_ptr
 h = ((h << 5) + h) + c;
 class_infos[idx].hash = h;
 class_infos[idx].isa = buckets[i].isa;
+DEBUG_PRINTF ("[%u] isa = %8p %s\n", idx, 
class_infos[idx].isa, buckets[i].name_ptr);
 }
 ++idx;
 }



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

[Lldb-commits] [PATCH] D97778: [lldb] Extend Python convenience variable table with equivalent APIs

[Jonas Devlieghere 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 rGf46a441b1c5d: [lldb] Extend Python convenience variable 
table with equivalent APIs (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D97778?vs=327501&id=327616#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97778

Files:
  lldb/docs/use/python-reference.rst

Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -98,39 +98,38 @@
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose **script** command was invoked.  |
-|   | | The **lldb.SBDebugger** object owns the command interpreter |
-|   | | and all the targets in your debug session.  There will always be a  |
-|   | | Debugger in the embedded interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected target - for instance the one made with the |
-|   | | **file** or selected by the **target select ** command.   |
-|   | | The **lldb.SBTarget** manages one running process, and all the executable   |
-|   | | and debug files for the process.|
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the currently selected target.  |
-|   | | The **lldb.SBProcess** object manages the threads and allows access to  |
-|   | | memory for the process. |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected thread. |
-|   | | The **lldb.SBThread** object manages the stack frames in that thread.   |
-|   | | A thread is always selected in the command interpreter when a target stops. |
-|   | | The **thread select ** command can be used to change the  |
-|   | | currently selected thread.  So as long as you have a stopped process, there will be |
-|   | | some selected thread.   |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected stack frame.|
-|   | | The **lldb.SBFrame** object manage the stack locals and the register set for|
-|   | | that stack. |
-|   | | A stack frame is always selected in the command interpreter when a target stops.|
-|   | | The **frame select ** command can be used to change the|
-|   | | currently selected frame.  So as long as you have a stopped process, there will |
-|   | | be some selected frame. |
-+---+-+

[Lldb-commits] [PATCH] D50299: Migrate to llvm::unique_function instead of static member functions for callbacks

[Jonas Devlieghere 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 rG5826aa48f03f: Migrate to llvm::unique_function instead of 
static member functions for… (authored by nealsid, committed by JDevlieghere).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50299

Files:
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Editline.h
  lldb/source/Core/IOHandler.cpp
  lldb/source/Host/common/Editline.cpp
  lldb/unittests/Editline/EditlineTest.cpp

Index: lldb/unittests/Editline/EditlineTest.cpp
===
--- lldb/unittests/Editline/EditlineTest.cpp
+++ lldb/unittests/Editline/EditlineTest.cpp
@@ -81,8 +81,8 @@
   void ConsumeAllOutput();
 
 private:
-  static bool IsInputComplete(lldb_private::Editline *editline,
-  lldb_private::StringList &lines, void *baton);
+  bool IsInputComplete(lldb_private::Editline *editline,
+   lldb_private::StringList &lines);
 
   std::unique_ptr _editline_sp;
 
@@ -122,7 +122,10 @@
   _editline_sp->SetPrompt("> ");
 
   // Hookup our input complete callback.
-  _editline_sp->SetIsInputCompleteCallback(IsInputComplete, this);
+  auto input_complete_cb = [this](Editline *editline, StringList &lines) {
+return this->IsInputComplete(editline, lines);
+  };
+  _editline_sp->SetIsInputCompleteCallback(input_complete_cb);
 }
 
 void EditlineAdapter::CloseInput() {
@@ -183,8 +186,7 @@
 }
 
 bool EditlineAdapter::IsInputComplete(lldb_private::Editline *editline,
-  lldb_private::StringList &lines,
-  void *baton) {
+  lldb_private::StringList &lines) {
   // We'll call ourselves complete if we've received a balanced set of braces.
   int start_block_count = 0;
   int brace_balance = 0;
Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -9,8 +9,9 @@
 #include 
 #include 
 
-#include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/Editline.h"
+
+#include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Utility/CompletionRequest.h"
@@ -641,8 +642,7 @@
   lines.AppendString(new_line_fragment);
 #endif
 
-  int indent_correction = m_fix_indentation_callback(
-  this, lines, 0, m_fix_indentation_callback_baton);
+  int indent_correction = m_fix_indentation_callback(this, lines, 0);
   new_line_fragment = FixIndentation(new_line_fragment, indent_correction);
   m_revert_cursor_index = GetIndentation(new_line_fragment);
 }
@@ -677,8 +677,7 @@
   info->cursor == info->lastchar) {
 if (m_is_input_complete_callback) {
   auto lines = GetInputAsStringList();
-  if (!m_is_input_complete_callback(this, lines,
-m_is_input_complete_callback_baton)) {
+  if (!m_is_input_complete_callback(this, lines)) {
 return BreakLineCommand(ch);
   }
 
@@ -811,8 +810,7 @@
 if (m_fix_indentation_callback) {
   StringList lines = GetInputAsStringList();
   lines.AppendString("");
-  indentation = m_fix_indentation_callback(
-  this, lines, 0, m_fix_indentation_callback_baton);
+  indentation = m_fix_indentation_callback(this, lines, 0);
 }
 m_input_lines.insert(
 m_input_lines.end(),
@@ -857,8 +855,8 @@
   // Save the edits and determine the correct indentation level
   SaveEditedLine();
   StringList lines = GetInputAsStringList(m_current_line_index + 1);
-  int indent_correction = m_fix_indentation_callback(
-  this, lines, cursor_position, m_fix_indentation_callback_baton);
+  int indent_correction =
+  m_fix_indentation_callback(this, lines, cursor_position);
 
   // If it is already correct no special work is needed
   if (indent_correction == 0)
@@ -977,7 +975,7 @@
 }
 
 unsigned char Editline::TabCommand(int ch) {
-  if (m_completion_callback == nullptr)
+  if (!m_completion_callback)
 return CC_ERROR;
 
   const LineInfo *line_info = el_line(m_editline);
@@ -988,7 +986,7 @@
   CompletionResult result;
   CompletionRequest request(line, cursor_index, result);
 
-  m_completion_callback(request, m_completion_callback_baton);
+  m_completion_callback(request);
 
   llvm::ArrayRef results = result.GetResults();
 
@@ -1047,12 +1045,15 @@
 }
 
 unsigned char Editline::ApplyAutosuggestCommand(int ch) {
+  if (!m_suggestion_callback) {
+return CC_REDISPLAY;
+  }
+
   const LineInfo *line_info = el_line(m_editline);
   llvm::StringRef line(line_info->buffer,
line_info->lastchar - line_info->buffer);
 
-  if (llvm::Optional to_a

[Lldb-commits] [lldb] f46a441 - [lldb] Extend Python convenience variable table with equivalent APIs

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2021-03-02T16:13:55-08:00
New Revision: f46a441b1c5dfb0a2580f656e1506fa138f21165

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

LOG: [lldb] Extend Python convenience variable table with equivalent APIs

Add a column to the table of convenience variables with the equivalent
API to get to the current debugger, target, process, etc.

We often get asked to make convenience variables available outside of
the interactive interpreter. After explaining why that's not possible, a
common complaint is that it's hard to find out how to get to these
variables in a non-interactive context, for example how to get to the
current frame when given a thread. This patch aims to alleviate that by
including the APIs to navigate between these instances in the table.

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

Added: 


Modified: 
lldb/docs/use/python-reference.rst

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index 0225d45e1ac8..75d9ea1164ed 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -98,39 +98,38 @@ state. In each case, if there is no currently selected 
entity of the
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description
 |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose 
**script** command was invoked.  |
-|   | | The **lldb.SBDebugger** object 
owns the command interpreter |
-|   | | and all the targets in your debug 
session.  There will always be a  |
-|   | | Debugger in the embedded 
interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected 
target - for instance the one made with the |
-|   | | **file** or selected by the 
**target select ** command.   |
-|   | | The **lldb.SBTarget** manages one 
running process, and all the executable   |
-|   | | and debug files for the process.   
 |
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the 
currently selected target.  |
-|   | | The **lldb.SBProcess** object 
manages the threads and allows access to  |
-|   | | memory for the process.
 |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected 
thread. |
-|   | | The **lldb.SBThread** object 
manages the stack frames in that thread.   |
-|   | | A thread is always selected in the 
command interpreter when a target stops. |
-|   | | The **thread select 
** command can be used to change the  |
-|   | | currently selected thread.  So as 
long as you have a stopped process, there will be |
-|   | | some selected thread.  
 |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected 
stack frame.|
-|   | | The **lldb.SBFrame** object manage 
the stack locals and the register set for|
-|   | | that stack.

[Lldb-commits] [lldb] 5826aa4 - Migrate to llvm::unique_function instead of static member functions for callbacks

[Jonas Devlieghere via lldb-commits]

Author: Neal (nealsid)
Date: 2021-03-02T16:13:54-08:00
New Revision: 5826aa48f03fba215b135f3c21ee52662281134d

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

LOG: Migrate to llvm::unique_function instead of static member functions for 
callbacks

A few cleanups suggested in another patch review's comments:

1. Use llvm:unique_function for storing & invoking callbacks from
   Editline to IOHandler
2. Change return type of one of the callback setters from bool to void,
   since it's return value was never used
3. Moved the callback setters inline & made them nonstatic, since that's
   more consistent with other setter definitions
4. Removed the baton parameter since we no longer need it anymore

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

Added: 


Modified: 
lldb/include/lldb/Core/IOHandler.h
lldb/include/lldb/Host/Editline.h
lldb/source/Core/IOHandler.cpp
lldb/source/Host/common/Editline.cpp
lldb/unittests/Editline/EditlineTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/IOHandler.h 
b/lldb/include/lldb/Core/IOHandler.h
index 2e8f3225fd5f..6cb0e56681e0 100644
--- a/lldb/include/lldb/Core/IOHandler.h
+++ b/lldb/include/lldb/Core/IOHandler.h
@@ -419,16 +419,14 @@ class IOHandlerEditline : public IOHandler {
 
 private:
 #if LLDB_ENABLE_LIBEDIT
-  static bool IsInputCompleteCallback(Editline *editline, StringList &lines,
-  void *baton);
+  bool IsInputCompleteCallback(Editline *editline, StringList &lines);
 
-  static int FixIndentationCallback(Editline *editline, const StringList 
&lines,
-int cursor_position, void *baton);
+  int FixIndentationCallback(Editline *editline, const StringList &lines,
+ int cursor_position);
 
-  static llvm::Optional SuggestionCallback(llvm::StringRef line,
-void *baton);
+  llvm::Optional SuggestionCallback(llvm::StringRef line);
 
-  static void AutoCompleteCallback(CompletionRequest &request, void *baton);
+  void AutoCompleteCallback(CompletionRequest &request);
 #endif
 
 protected:

diff  --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h
index a37ad1b9d106..3295c9a2080a 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -38,7 +38,6 @@
 #include 
 #include 
 
-#include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/lldb-private.h"
 
 #if defined(_WIN32)
@@ -56,6 +55,9 @@
 #include "lldb/Utility/CompletionRequest.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/Predicate.h"
+#include "lldb/Utility/StringList.h"
+
+#include "llvm/ADT/FunctionExtras.h"
 
 namespace lldb_private {
 namespace line_editor {
@@ -81,27 +83,26 @@ using EditLineGetCharType = wchar_t;
 using EditLineGetCharType = char;
 #endif
 
-typedef int (*EditlineGetCharCallbackType)(::EditLine *editline,
-   EditLineGetCharType *c);
-typedef unsigned char (*EditlineCommandCallbackType)(::EditLine *editline,
- int ch);
-typedef const char *(*EditlinePromptCallbackType)(::EditLine *editline);
+using EditlineGetCharCallbackType = int (*)(::EditLine *editline,
+EditLineGetCharType *c);
+using EditlineCommandCallbackType = unsigned char (*)(::EditLine *editline,
+  int ch);
+using EditlinePromptCallbackType = const char *(*)(::EditLine *editline);
 
 class EditlineHistory;
 
-typedef std::shared_ptr EditlineHistorySP;
+using EditlineHistorySP = std::shared_ptr;
 
-typedef bool (*IsInputCompleteCallbackType)(Editline *editline,
-StringList &lines, void *baton);
+using IsInputCompleteCallbackType =
+llvm::unique_function;
 
-typedef int (*FixIndentationCallbackType)(Editline *editline,
-  const StringList &lines,
-  int cursor_position, void *baton);
+using FixIndentationCallbackType =
+llvm::unique_function;
 
-typedef llvm::Optional (*SuggestionCallbackType)(
-llvm::StringRef line, void *baton);
+using SuggestionCallbackType =
+llvm::unique_function(llvm::StringRef)>;
 
-typedef void (*CompleteCallbackType)(CompletionRequest &request, void *baton);
+using CompleteCallbackType = llvm::unique_function;
 
 /// Status used to decide when and how to start editing another line in
 /// multi-line sessions
@@ -188,21 +189,28 @@ class Editline {
   bool Cancel();
 
   /// Register a callback for autosuggestion.
-  void SetSuggestionCallback(SuggestionCallbackType callback, void *baton);
+  

[Lldb-commits] [PATCH] D97739: Add a progress class that can track and report long running operations that happen in LLDB.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: lldb/include/lldb/Core/Progress.h:100
+  /// The title of the progress activity.
+  ConstString m_message;
+  /// How much work ([0...m_total]) that has been completed.

teemperor wrote:
> `std::string`
Agreed, after I added the "m_id" member variable, the ConstString value is no 
longer relied upon to unique the progress.



Comment at: lldb/source/Core/Module.cpp:1075-1076
 lldb::DescriptionLevel level) {
-  std::lock_guard guard(m_mutex);
-
   if (level >= eDescriptionLevelFull) {

This is the main cause for deadlocks with DWARF logging. We have spoken about 
this on the list before where we should drop the mutex from this call to avoid 
deadlocking logging calls, but that also applies to this case where Progress 
objects might be constructed on any thread. The m_arch, m_file and m_object 
variables are setup very early in the Module object's lifetime, so it should be 
fine to not have to lock this mutex. I can submit this as a separate patch so 
we can discuss, but I included it here to avoid deadlocks.



Comment at: lldb/source/Core/Progress.cpp:18
+void *Progress::g_callback_baton = nullptr;
+uint64_t Progress::g_progress_id = 0;
+

teemperor wrote:
> I would really like to avoid the global state that is introduced here, but I 
> assume the idea here is to avoid having to pass around a Debugger object to 
> all parts of LLDB (especially the ones which aren't tied to a Debugger).
> 
> Anyway, a few comments on the current approach:
> * One callback is rather limiting. If I have an IDE with a progress bar that 
> has an embedded LLDB command line, then I guess both want to subscribe to 
> progress events? Right now the one that starts later will steal the progress 
> notifications from whatever client has subscribed earlier.
> * This needs to be made thread-safe (right now I can call 
> `lldb::SBDebugger::SetProgressCallback` and just snitch away `g_callback` in 
> the middle of printing the progress -> crash).
> 
> As we probably end up with some kind of global state object that manages this 
> stuff, I would also suggest we put this into the normal subsystem init/deinit 
> infrastructure (i.e., give it a `Initialize`/`Terminate` call). This way this 
> won't be another "intentional leak" and we can properly use this in unit 
> tests (where we can init/deinit subsystems and cleanup this state 
> automatically).
Yeah, I started off putting stuff in the Debugger as static calls, but then it 
really had nothing to do with the debugger since we don't ever have a debugger 
to pass around, nor does it make sense since the module list is global and all 
debuggers can use it and this is where the bulk of the long running operations 
happen.

I can add multiple callback support and thread safety. The only issue I see 
with multiple callbacks is you would need an extra call to say "remove this 
callback + baton from the list" if we ever want to remove the callback. 
Currently you can set the callback to null.



Comment at: lldb/source/Core/Progress.cpp:39
+
+void Progress::Increment(uint64_t amount) {
+  if (amount > 0) {

teemperor wrote:
> So, just to be clear what's going on here: This is the function we expect 
> several  'working' threads to call? From the current uses in 
> `ManualDWARFIndex` that seems to be the case, but I don't see how this will 
> work out.
> 
> 1. Whoever receives the "progress report" callback needs to be ready to 
> handle receiving multiple events from multiple threads. The VSCode callback 
> isn't thread safe from what I can see and user-callbacks will also not be 
> thread-safe. Either we make it really, really, really clear that the progress 
> callbacks arrive from several threads or we somehow try to make this code 
> handle the multi-threading for the user.
> 2. The logic here isn't thread-safe (`m_completed` is atomic, but that 
> doesn't make the surrounding logic thread-safe).
Yes multiple threads can call this.

1. The callback function must be made thread safe as these callbacks will come 
from one or more threads. I will add logic to make the callback thread safe in 
lldb-vscode.cpp.

2. You are correct, I can add a mutex to allow the math that I recently added 
to be thread safe and switch m_completed to not be atomic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97739

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

[Lldb-commits] [PATCH] D97721: [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

kwk added a comment.

@jankratochvil out of curiosity. Can you give a pointer to what the C program 
looks like that produces the object code? I know GCC might change and no longer 
produce this code so it's better to have the obj code instead. But still I'm 
not nearly close to understanding


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97721

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

[Lldb-commits] [lldb] 14ccba2 - Promote scalars to load addresses when dereferencing them.

[Adrian Prantl via lldb-commits]

Author: Adrian Prantl
Date: 2021-03-02T14:30:39-08:00
New Revision: 14ccba26bd4d4f78cf5ec2ca8bb55c95913a3ec5

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

LOG: Promote scalars to load addresses when dereferencing them.

This is a follow-up to 188b0747c1664d962e94f00b5e3caac529fa1e26. This
is a very narrow fix to a more general problem. LLDB should be better
at distinguishing between implict and memory location descriptions.

rdar://74902042

Added: 


Modified: 
lldb/source/Expression/DWARFExpression.cpp
lldb/unittests/Expression/DWARFExpressionTest.cpp

Removed: 




diff  --git a/lldb/source/Expression/DWARFExpression.cpp 
b/lldb/source/Expression/DWARFExpression.cpp
index 6e78b9aa841a6..a8843ca0543b0 100644
--- a/lldb/source/Expression/DWARFExpression.cpp
+++ b/lldb/source/Expression/DWARFExpression.cpp
@@ -1064,10 +1064,12 @@ bool DWARFExpression::Evaluate(
   return false;
 }
 stack.back().GetScalar() = load_Addr;
-stack.back().SetValueType(Value::ValueType::LoadAddress);
-// Fall through to load address code below...
+// Fall through to load address promotion code below.
   } LLVM_FALLTHROUGH;
   case Value::ValueType::Scalar:
+// Promote Scalar to LoadAddress and fall through.
+stack.back().SetValueType(Value::ValueType::LoadAddress);
+LLVM_FALLTHROUGH;
   case Value::ValueType::LoadAddress:
 if (exe_ctx) {
   if (process) {

diff  --git a/lldb/unittests/Expression/DWARFExpressionTest.cpp 
b/lldb/unittests/Expression/DWARFExpressionTest.cpp
index ad56207659d20..7fcd967990cef 100644
--- a/lldb/unittests/Expression/DWARFExpressionTest.cpp
+++ b/lldb/unittests/Expression/DWARFExpressionTest.cpp
@@ -41,6 +41,8 @@ static llvm::Expected 
Evaluate(llvm::ArrayRef expr,
   switch (result.GetValueType()) {
   case Value::ValueType::Scalar:
 return result.GetScalar();
+  case Value::ValueType::LoadAddress:
+return LLDB_INVALID_ADDRESS;
   case Value::ValueType::HostAddress: {
 // Convert small buffers to scalars to simplify the tests.
 DataBufferHeap &buf = result.GetBuffer();
@@ -344,6 +346,12 @@ TEST_F(DWARFExpressionMockProcessTest, DW_OP_deref) {
   ASSERT_TRUE(process_sp);
 
   ExecutionContext exe_ctx(process_sp);
-  EXPECT_THAT_EXPECTED(Evaluate({DW_OP_lit4, DW_OP_deref}, {}, {}, &exe_ctx),
+  // Implicit location: *0x4.
+  EXPECT_THAT_EXPECTED(Evaluate({DW_OP_lit4, DW_OP_deref, DW_OP_stack_value},
+{}, {}, &exe_ctx),
llvm::HasValue(GetScalar(32, 0x07060504, false)));
+  // Memory location: *(*0x4).
+  // Evaluate returns LLDB_INVALID_ADDRESS for all load addresses.
+  EXPECT_THAT_EXPECTED(Evaluate({DW_OP_lit4, DW_OP_deref}, {}, {}, &exe_ctx),
+   llvm::HasValue(Scalar(LLDB_INVALID_ADDRESS)));
 }



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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

While next to the binary seems like a better guess than the cwd, it does seem 
awkward that if the binary & dwo's aren't in the same place, you have to move 
files to get that heuristic to work, whereas you could just "cd" into wherever 
the dwo's got dumped to make the cwd version work.

I'm don't really have a strong opinion one way or the other.  But this does 
seem like the sort of thing that should be helped out by one of the debug info 
path settings.  That way the user could point lldb at the dwo's no matter where 
they ended up.


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

https://reviews.llvm.org/D97786

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D97786#2598100 , @cmtice wrote:

> re "GDB does it this way" -- I am also writing/submitting a patch to get GDB 
> to change this behavior.

Ah, I see. That changes the picture, I'd say. If gdb folks go along with that, 
then I don't see any problems here. I see just one small issue to nail down -- 
what exactly is the path relative to? The executable file, or the file 
containing the debug info (in the `objcopy --strip-debug/--only-keep-debug` 
scenario)? I think the latter would be /slightly/ more useful, as one can 
imagine shipping the dwos in /usr/lib/debug, next to the `.debug` file (though 
I hope that in reality, everyone will just ship the dwp file). I think this is 
actually what this patch implements.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1646-1652
+  ModuleSpec module_spec;
+  module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
+  module_spec.GetSymbolFileSpec() =
+  FileSpec(m_objfile_sp->GetModule()->GetFileSpec().GetPath());
+  llvm::StringRef exe_dir =
+  module_spec.GetFileSpec().GetDirectory().GetStringRef();
+  dwo_file.PrependPathComponent(exe_dir);

All of this is basically  just 
`dwo_file.PrependPathComponent(m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef())`,
 is it not?


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

https://reviews.llvm.org/D97786

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Caroline Tice via Phabricator via lldb-commits]

cmtice added a comment.

It is true that the compiler will not know where the final executable will be 
placed, and if the executable gets moved then debugging with .dwo files will 
probably not work anyway,  However as it is currently written, LLDB will fail 
to find the .dwo files,  *even when the binary has not been moved*, if the 
debugger is launched from any directory other than the one containing the 
binary.

E.g. we have a team where the standard workflow is  'cd src'; build binary in 
src/out/Debug/.; from src, do 'lldb out/Debug/binary'.  lldb  cannot find the 
.dwo files.

re "GDB does it this way" -- I am also writing/submitting a patch to get GDB to 
change this behavior.


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

https://reviews.llvm.org/D97786

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Pavel Labath via Phabricator via lldb-commits]

labath added a subscriber: thakis.
labath added a comment.

Also, cc @thakis, who floated the idea of using a special path token 
(`$ORIGIN`) to achieve the same thing.


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

https://reviews.llvm.org/D97786

___
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

[Michał Górny via Phabricator via lldb-commits]

mgorny marked an inline comment as done.
mgorny added a comment.

I'm sorry for not replying earlier.




Comment at: 
lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp:141
+  uint64_t f31;
+  uint64_t fcsr;
+  uint64_t fir;

jrtc27 wrote:
> MIPS calls it FCSR, FreeBSD's regnum.h calls it FSR. I don't know which is 
> the right thing to use, but just thought I should point it out if you hadn't 
> noticed.
I have noticed. Others part of LLDB (and LLVM) call it FCSR, so I've figured 
out it's better to be consistent with that.



Comment at: 
lldb/source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp:161-167
+  // Check if RegisterSet is available
+  if (set < k_num_register_sets)
+return &g_reg_sets_mips64[set];
+  return nullptr;
 }
 
+size_t RegisterContextFreeBSD_mips64::GetRegisterSetCount() const {

jrtc27 wrote:
> These diffs should be separated from this commit IMO.
Do you mean reformatting? I suppose I can commit the result of `clang-format` 
earlier. Figured the changes are trivial enough.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h:26
 // Computes the offset of the given FPR in the extended data area.
+#ifdef LINUX_MIPS64
 #define FPR_OFFSET(regname)
\

jrtc27 wrote:
> Should these not live in the respective RegisterContext_mips64.cpp?
I really don't know. I've followed suit with the other macros already here.



Comment at: lldb/source/Plugins/Process/Utility/RegisterInfos_mips64.h:37
 // Computes the offset of the given MSA in the extended data area.
 #define MSA_OFFSET(regname)
\
   (LLVM_EXTENSION offsetof(UserArea, msa) +
\

jrtc27 wrote:
> This and DEFINE_GPR_INFO should not be defined like this on FreeBSD (or at 
> all?).
I suppose we could make them conditional too but I'm not sure if this wouldn't 
just add complexity for no real change.


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

https://reviews.llvm.org/D96766

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In general, a compiler also does not know where the final executable will be 
placed -- this can be only (maybe) be said for a sufficiently strict build 
system (like the one at google). I wouldn't say that searching relative to the 
cwd is really that much better, but at least it is consistent with what gdb 
does.


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

https://reviews.llvm.org/D97786

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Caroline Tice via Phabricator via lldb-commits]

cmtice updated this revision to Diff 327523.
cmtice added a comment.

Upload the correct patch this time. (sorry!)


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

https://reviews.llvm.org/D97786

Files:
  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
@@ -1639,6 +1639,18 @@
   return nullptr;
 
 dwo_file.SetFile(comp_dir, FileSpec::Style::native);
+if (dwo_file.IsRelative()) {
+  // if DW_AT_comp_dir is relative, it should be relative to the location
+  // of the executable, not to the location from which the debugger was
+  // launched.
+  ModuleSpec module_spec;
+  module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
+  module_spec.GetSymbolFileSpec() =
+  FileSpec(m_objfile_sp->GetModule()->GetFileSpec().GetPath());
+  llvm::StringRef exe_dir =
+  module_spec.GetFileSpec().GetDirectory().GetStringRef();
+  dwo_file.PrependPathComponent(exe_dir);
+}
 FileSystem::Instance().Resolve(dwo_file);
 dwo_file.AppendPathComponent(dwo_name);
   }


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1639,6 +1639,18 @@
   return nullptr;
 
 dwo_file.SetFile(comp_dir, FileSpec::Style::native);
+if (dwo_file.IsRelative()) {
+  // if DW_AT_comp_dir is relative, it should be relative to the location
+  // of the executable, not to the location from which the debugger was
+  // launched.
+  ModuleSpec module_spec;
+  module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
+  module_spec.GetSymbolFileSpec() =
+  FileSpec(m_objfile_sp->GetModule()->GetFileSpec().GetPath());
+  llvm::StringRef exe_dir =
+  module_spec.GetFileSpec().GetDirectory().GetStringRef();
+  dwo_file.PrependPathComponent(exe_dir);
+}
 FileSystem::Instance().Resolve(dwo_file);
 dwo_file.AppendPathComponent(dwo_name);
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Shoaib Meenai via Phabricator via lldb-commits]

smeenai added a comment.

Is this rebased on main? The LLD for Mach-O changes look like they belong to a 
different diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97786

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

[Lldb-commits] [PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[Caroline Tice via Phabricator via lldb-commits]

cmtice created this revision.
cmtice added a reviewer: jingham.
Herald added subscribers: cishida, hiraditya.
Herald added a reviewer: int3.
Herald added a project: lld-macho.
Herald added a reviewer: lld-macho.
cmtice requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, lldb-commits, sstefan1.
Herald added projects: LLDB, LLVM.

DWARF allows .dwo file paths to be relative rather than absolute.  When they 
are relative, DWARF uses DW_AT_comp_dir to find the .dwo file.  DW_AT_comp_dir 
can also be relative, making the entire search patch for the .dwo file 
relative.  In this case, LLDB currently searches relative to its current 
working directory, i.e. the directory from which the debugger was launched.  
This is not right, as the compiler, which generated the relative paths, can 
have no idea where the debugger will be launched.  The correct thing is to 
search relative to the location of the executable binary.  That is what this 
patch does.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D97786

Files:
  lld/MachO/Driver.h
  lld/MachO/InputFiles.cpp
  lld/test/MachO/Inputs/iPhoneSimulator.sdk/usr/lib/libReexportSystem.tbd
  lld/test/MachO/Inputs/iPhoneSimulator.sdk/usr/lib/libSystem.tbd
  lld/test/MachO/reexport-nested-lib.s
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  llvm/include/llvm/TextAPI/MachO/InterfaceFile.h
  llvm/lib/TextAPI/MachO/InterfaceFile.cpp

Index: llvm/lib/TextAPI/MachO/InterfaceFile.cpp
===
--- llvm/lib/TextAPI/MachO/InterfaceFile.cpp
+++ llvm/lib/TextAPI/MachO/InterfaceFile.cpp
@@ -124,6 +124,7 @@
   const std::shared_ptr &RHS) {
  return LHS->InstallName < RHS->InstallName;
});
+  Document->Parent = this;
   Documents.insert(Pos, Document);
 }
 
Index: llvm/include/llvm/TextAPI/MachO/InterfaceFile.h
===
--- llvm/include/llvm/TextAPI/MachO/InterfaceFile.h
+++ llvm/include/llvm/TextAPI/MachO/InterfaceFile.h
@@ -338,6 +338,9 @@
   ///\param Document The library to inline with top level library.
   void addDocument(std::shared_ptr &&Document);
 
+  /// Returns the pointer to parent document if exists or nullptr otherwise.
+  InterfaceFile *getParent() const { return Parent; }
+
   /// Get the list of inlined libraries.
   ///
   /// \return Returns a list of the inlined frameworks.
@@ -431,6 +434,7 @@
   std::vector> Documents;
   std::vector> UUIDs;
   SymbolMapType Symbols;
+  InterfaceFile *Parent = nullptr;
 };
 
 template 
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1639,6 +1639,18 @@
   return nullptr;
 
 dwo_file.SetFile(comp_dir, FileSpec::Style::native);
+if (dwo_file.IsRelative()) {
+  // if DW_AT_comp_dir is relative, it should be relative to the location
+  // of the executable, not to the location from which the debugger was
+  // launched.
+  ModuleSpec module_spec;
+  module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
+  module_spec.GetSymbolFileSpec() =
+  FileSpec(m_objfile_sp->GetModule()->GetFileSpec().GetPath());
+  llvm::StringRef exe_dir =
+  module_spec.GetFileSpec().GetDirectory().GetStringRef();
+  dwo_file.PrependPathComponent(exe_dir);
+}
 FileSystem::Instance().Resolve(dwo_file);
 dwo_file.AppendPathComponent(dwo_name);
   }
Index: lld/test/MachO/reexport-nested-lib.s
===
--- /dev/null
+++ lld/test/MachO/reexport-nested-lib.s
@@ -0,0 +1,28 @@
+# REQUIRES: x86
+#
+# This tests that we can reference symbols from a dylib,
+# re-exported by a top-level tapi document, which itself is
+# re-exported by another top-level tapi document.
+#
+# RUN: rm -rf %t; mkdir -p %t
+# RUN: llvm-mc -filetype obj -triple x86_64-apple-darwin %s -o %t/test.o
+# RUN: %lld -o %t/test -syslibroot %S/Inputs/iPhoneSimulator.sdk -lReexportSystem %t/test.o
+# RUN: llvm-objdump %t/test --macho --bind %t/test | FileCheck %s
+
+# CHECK: segment  section   addresstypeaddend  dylib   symbol
+# CHECK: __DATA   __data0x{{[0-9a-f]*}}pointer 0   libReexportSystem __crashreporter_info__
+# CHECK: __DATA   __data0x{{[0-9a-f]*}}pointer 0   libReexportSystem _cache_create
+
+.text
+.globl _main
+
+_main:
+  ret
+
+.data
+// This symbol is from libSystem, which is re-exported by libReexportSystem.
+// Reference it here to verify that it is visible.
+.quad __crashreporter_info__
+
+// This symbol is from /usr/lib/system/libcache.dylib, which is re-exported in libSystem.
+.quad _cach

[Lldb-commits] [PATCH] D97769: [lldb] Apply gdb-remote timeout to platform connections as well

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97769

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

[Lldb-commits] [PATCH] D97778: [lldb] Extend Python convenience variable table with equivalent APIs

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 327501.
JDevlieghere added a comment.

Use single backtick so Sphinx automatically links the API docs.


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

https://reviews.llvm.org/D97778

Files:
  lldb/docs/use/python-reference.rst

Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -98,39 +98,38 @@
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose **script** command was invoked.  |
-|   | | The **lldb.SBDebugger** object owns the command interpreter |
-|   | | and all the targets in your debug session.  There will always be a  |
-|   | | Debugger in the embedded interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected target - for instance the one made with the |
-|   | | **file** or selected by the **target select ** command.   |
-|   | | The **lldb.SBTarget** manages one running process, and all the executable   |
-|   | | and debug files for the process.|
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the currently selected target.  |
-|   | | The **lldb.SBProcess** object manages the threads and allows access to  |
-|   | | memory for the process. |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected thread. |
-|   | | The **lldb.SBThread** object manages the stack frames in that thread.   |
-|   | | A thread is always selected in the command interpreter when a target stops. |
-|   | | The **thread select ** command can be used to change the  |
-|   | | currently selected thread.  So as long as you have a stopped process, there will be |
-|   | | some selected thread.   |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected stack frame.|
-|   | | The **lldb.SBFrame** object manage the stack locals and the register set for|
-|   | | that stack. |
-|   | | A stack frame is always selected in the command interpreter when a target stops.|
-|   | | The **frame select ** command can be used to change the|
-|   | | currently selected frame.  So as long as you have a stopped process, there will |
-|   | | be some selected frame. |
-+---+-+-+
-
++---+-+-+-+
+| Variable  | Type| Equivalent  | De

[Lldb-commits] [PATCH] D97778: [lldb] Extend Python convenience variable table with equivalent APIs

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 327489.
JDevlieghere added a comment.

Use backticks (everywhere)


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

https://reviews.llvm.org/D97778

Files:
  lldb/docs/use/python-reference.rst

Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -98,39 +98,38 @@
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose **script** command was invoked.  |
-|   | | The **lldb.SBDebugger** object owns the command interpreter |
-|   | | and all the targets in your debug session.  There will always be a  |
-|   | | Debugger in the embedded interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected target - for instance the one made with the |
-|   | | **file** or selected by the **target select ** command.   |
-|   | | The **lldb.SBTarget** manages one running process, and all the executable   |
-|   | | and debug files for the process.|
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the currently selected target.  |
-|   | | The **lldb.SBProcess** object manages the threads and allows access to  |
-|   | | memory for the process. |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected thread. |
-|   | | The **lldb.SBThread** object manages the stack frames in that thread.   |
-|   | | A thread is always selected in the command interpreter when a target stops. |
-|   | | The **thread select ** command can be used to change the  |
-|   | | currently selected thread.  So as long as you have a stopped process, there will be |
-|   | | some selected thread.   |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected stack frame.|
-|   | | The **lldb.SBFrame** object manage the stack locals and the register set for|
-|   | | that stack. |
-|   | | A stack frame is always selected in the command interpreter when a target stops.|
-|   | | The **frame select ** command can be used to change the|
-|   | | currently selected frame.  So as long as you have a stopped process, there will |
-|   | | be some selected frame. |
-+---+-+-+
-
++---+-+-+-+
+| Variable  | Type| Equivalent  | Description

[Lldb-commits] [PATCH] D97778: [lldb] Extend Python convenience variable table with equivalent APIs

[Med Ismail Bennani via Phabricator via lldb-commits]

mib accepted this revision.
mib added a comment.
This revision is now accepted and ready to land.

Cool! LGTM!


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

https://reviews.llvm.org/D97778

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

[Lldb-commits] [PATCH] D97778: [lldb] Extend Python convenience variable table with equivalent APIs

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added a reviewer: LLDB.
JDevlieghere requested review of this revision.

Add a column to the table of convenience variables with the equivalent API to 
get to the current debugger, target, process, etc. We often get asked to make 
convenience variables available outside of the interactive interpreter. After 
explaining why that's not possible, a common complaint is that it's hard to 
find out how to get to these variables in a non-interactive context, for 
example how to get to the current frame when given a thread.. This patch aims 
to alleviate that by including the APIs to navigate between these instances in 
the table.


https://reviews.llvm.org/D97778

Files:
  lldb/docs/use/python-reference.rst


Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -98,39 +98,38 @@
 appropriate type, the variable's IsValid method will return false. These
 variables are:
 
-+---+-+-+
-| Variable  | Type| Description
 |
-+---+-+-+
-| **lldb.debugger** | **lldb.SBDebugger** | Contains the debugger object whose 
**script** command was invoked.  |
-|   | | The **lldb.SBDebugger** object 
owns the command interpreter |
-|   | | and all the targets in your debug 
session.  There will always be a  |
-|   | | Debugger in the embedded 
interpreter.   |
-+---+-+-+
-| **lldb.target**   | **lldb.SBTarget**   | Contains the currently selected 
target - for instance the one made with the |
-|   | | **file** or selected by the 
**target select ** command.   |
-|   | | The **lldb.SBTarget** manages one 
running process, and all the executable   |
-|   | | and debug files for the process.   
 |
-+---+-+-+
-| **lldb.process**  | **lldb.SBProcess**  | Contains the process of the 
currently selected target.  |
-|   | | The **lldb.SBProcess** object 
manages the threads and allows access to  |
-|   | | memory for the process.
 |
-+---+-+-+
-| **lldb.thread**   | **lldb.SBThread**   | Contains the currently selected 
thread. |
-|   | | The **lldb.SBThread** object 
manages the stack frames in that thread.   |
-|   | | A thread is always selected in the 
command interpreter when a target stops. |
-|   | | The **thread select 
** command can be used to change the  |
-|   | | currently selected thread.  So as 
long as you have a stopped process, there will be |
-|   | | some selected thread.  
 |
-+---+-+-+
-| **lldb.frame**| **lldb.SBFrame**| Contains the currently selected 
stack frame.|
-|   | | The **lldb.SBFrame** object manage 
the stack locals and the register set for|
-|   | | that stack.
 |
-|   | | A stack frame is always selected 
in the command interpreter when a target stops.|
-|   | | The **frame select ** 
command can be used to change the|
-|   | | currently selected frame.  So as 
long as you have a stopped process, there will |
-|   |   

[Lldb-commits] [PATCH] D97760: [lldb][NFC] Delete unused AddressResolverName

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision as: JDevlieghere.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D97760

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

[Lldb-commits] [PATCH] D97765: [lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)

[Andy Yankovsky via Phabricator via lldb-commits]

werat updated this revision to Diff 327469.
werat added a comment.

Use `clang_host` instead of `clang`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97765

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  
lldb/test/Shell/SymbolFile/DWARF/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu1.s
  
lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s

Index: lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s
@@ -0,0 +1,160 @@
+	.text
+	.file	"inlinevar2.c"
+	.globl	other   # -- Begin function other
+	.type	other,@function
+other:  # @other
+.Lfunc_begin0:
+	.file	1 "" "inlinevar2.c"
+	.loc	1 3 0   # inlinevar2.c:3:0
+.Ltmp0:
+	.file	2 "" "./inlinevar.h"
+	.loc	2 2 16 prologue_end # ./inlinevar.h:2:16
+	movl	$42, %eax
+	.loc	2 3 10  # ./inlinevar.h:3:10
+	.loc	1 3 41  # inlinevar2.c:3:41
+	retq
+.Ltmp1:
+.Ltmp2:
+.Lfunc_end0:
+	.size	other, .Lfunc_end0-other
+# -- End function
+	.section	.debug_abbrev,"",@progbits
+	.byte	1   # Abbreviation Code
+	.byte	17  # DW_TAG_compile_unit
+	.byte	1   # DW_CHILDREN_yes
+	.byte	37  # DW_AT_producer
+	.byte	14  # DW_FORM_strp
+	.byte	19  # DW_AT_language
+	.byte	5   # DW_FORM_data2
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	16  # DW_AT_stmt_list
+	.byte	23  # DW_FORM_sec_offset
+	.byte	27  # DW_AT_comp_dir
+	.byte	14  # DW_FORM_strp
+	.byte	17  # DW_AT_low_pc
+	.byte	1   # DW_FORM_addr
+	.byte	18  # DW_AT_high_pc
+	.byte	6   # DW_FORM_data4
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	4   # Abbreviation Code
+	.byte	36  # DW_TAG_base_type
+	.byte	0   # DW_CHILDREN_no
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	62  # DW_AT_encoding
+	.byte	11  # DW_FORM_data1
+	.byte	11  # DW_AT_byte_size
+	.byte	11  # DW_FORM_data1
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	6   # Abbreviation Code
+	.byte	46  # DW_TAG_subprogram
+	.byte	1   # DW_CHILDREN_yes
+	.byte	17  # DW_AT_low_pc
+	.byte	1   # DW_FORM_addr
+	.byte	18  # DW_AT_high_pc
+	.byte	6   # DW_FORM_data4
+	.byte	64  # DW_AT_frame_base
+	.byte	24  # DW_FORM_exprloc
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	58  # DW_AT_decl_file
+	.byte	11  # DW_FORM_data1
+	.byte	59  # DW_AT_decl_line
+	.byte	11  # DW_FORM_data1
+	.byte	73  # DW_AT_type
+	.byte	19  # DW_FORM_ref4
+	.byte	63  # DW_AT_external
+	.byte	25  # DW_FORM_flag_present
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	7   # Abbreviation Code
+	.byte	29  # DW_TAG_inlined_subroutine
+	.byte	1   # DW_CHILDREN_yes
+	.byte	49  # DW_AT_abstract_origin
+	.byte	0x10# DW_FORM_ref_addr
+	.byte	17  # DW_AT_low_pc
+	.byte	1   # DW_FORM_addr
+	.byte	18  # DW_AT_high_pc
+	.byte	6   # DW_FORM_data4
+	.byte	88  # D

[Lldb-commits] [lldb] 1b8fdaa - [nfc] [lldb] DWARFDebugInfoEntry::Extract(): reindent

[Jan Kratochvil via lldb-commits]

Author: Jan Kratochvil
Date: 2021-03-02T16:44:07+01:00
New Revision: 1b8fdaacf49442dccacfe6e942b894150b287143

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

LOG: [nfc] [lldb] DWARFDebugInfoEntry::Extract(): reindent

Added: 


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

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
index 7227ded823a2..29f60367999d 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -49,161 +49,159 @@ bool DWARFDebugInfoEntry::Extract(const 
DWARFDataExtractor &data,
   // assert (fixed_form_sizes);  // For best performance this should be
   // specified!
 
-  if (m_abbr_idx) {
-lldb::offset_t offset = *offset_ptr;
-const auto *abbrevDecl = GetAbbreviationDeclarationPtr(cu);
-if (abbrevDecl == nullptr) {
-  cu->GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
-  "{0x%8.8x}: invalid abbreviation code %u, please file a bug and "
-  "attach the file at the start of this error message",
-  m_offset, (unsigned)abbr_idx);
-  // WE can't parse anymore if the DWARF is borked...
-  *offset_ptr = UINT32_MAX;
-  return false;
-}
-m_tag = abbrevDecl->Tag();
-m_has_children = abbrevDecl->HasChildren();
-// Skip all data in the .debug_info or .debug_types for the attributes
-const uint32_t numAttributes = abbrevDecl->NumAttributes();
-uint32_t i;
-dw_form_t form;
-for (i = 0; i < numAttributes; ++i) {
-  form = abbrevDecl->GetFormByIndexUnchecked(i);
-  llvm::Optional fixed_skip_size =
-  DWARFFormValue::GetFixedSize(form, cu);
-  if (fixed_skip_size)
-offset += *fixed_skip_size;
-  else {
-bool form_is_indirect = false;
-do {
-  form_is_indirect = false;
-  uint32_t form_size = 0;
-  switch (form) {
-  // Blocks if inlined data that have a length field and the data bytes
-  // inlined in the .debug_info/.debug_types
-  case DW_FORM_exprloc:
-  case DW_FORM_block:
-form_size = data.GetULEB128(&offset);
-break;
-  case DW_FORM_block1:
-form_size = data.GetU8_unchecked(&offset);
-break;
-  case DW_FORM_block2:
-form_size = data.GetU16_unchecked(&offset);
-break;
-  case DW_FORM_block4:
-form_size = data.GetU32_unchecked(&offset);
-break;
-
-  // Inlined NULL terminated C-strings
-  case DW_FORM_string:
-data.GetCStr(&offset);
-break;
-
-  // Compile unit address sized values
-  case DW_FORM_addr:
-form_size = cu->GetAddressByteSize();
-break;
-  case DW_FORM_ref_addr:
-if (cu->GetVersion() <= 2)
-  form_size = cu->GetAddressByteSize();
-else
-  form_size = 4;
-break;
-
-  // 0 sized form
-  case DW_FORM_flag_present:
-form_size = 0;
-break;
-
-  // 1 byte values
-  case DW_FORM_addrx1:
-  case DW_FORM_data1:
-  case DW_FORM_flag:
-  case DW_FORM_ref1:
-  case DW_FORM_strx1:
-form_size = 1;
-break;
-
-  // 2 byte values
-  case DW_FORM_addrx2:
-  case DW_FORM_data2:
-  case DW_FORM_ref2:
-  case DW_FORM_strx2:
-form_size = 2;
-break;
-
-  // 3 byte values
-  case DW_FORM_addrx3:
-  case DW_FORM_strx3:
-form_size = 3;
-break;
-
-  // 4 byte values
-  case DW_FORM_addrx4:
-  case DW_FORM_data4:
-  case DW_FORM_ref4:
-  case DW_FORM_strx4:
-form_size = 4;
-break;
-
-  // 8 byte values
-  case DW_FORM_data8:
-  case DW_FORM_ref8:
-  case DW_FORM_ref_sig8:
-form_size = 8;
-break;
-
-  // signed or unsigned LEB 128 values
-  case DW_FORM_addrx:
-  case DW_FORM_loclistx:
-  case DW_FORM_rnglistx:
-  case DW_FORM_sdata:
-  case DW_FORM_udata:
-  case DW_FORM_ref_udata:
-  case DW_FORM_GNU_addr_index:
-  case DW_FORM_GNU_str_index:
-  case DW_FORM_strx:
-data.Skip_LEB128(&offset);
-break;
-
-  case DW_FORM_indirect:
-form_is_indirect = true;
-form = data.GetULEB128(&offset);
-break;
-
-  case DW_FORM_strp:
- 

[Lldb-commits] [lldb] 61c2932 - [lldb] DWARFDebugInfoEntry::Extract(): Print an error for unsupported DW_FORM_*

[Jan Kratochvil via lldb-commits]

Author: Jan Kratochvil
Date: 2021-03-02T16:39:04+01:00
New Revision: 61c29321b3dffa3ae45483dd7678faedaef535a7

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

LOG: [lldb] DWARFDebugInfoEntry::Extract(): Print an error for unsupported 
DW_FORM_*

Added: 


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

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
index bce25297c4c7..7227ded823a2 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -183,6 +183,10 @@ bool DWARFDebugInfoEntry::Extract(const DWARFDataExtractor 
&data,
 break;
 
   default:
+cu->GetSymbolFileDWARF().GetObjectFile()->GetModule()->ReportError(
+"{0x%8.8x}: Unsupported DW_FORM_0x%x, please file a bug and "
+"attach the file at the start of this error message",
+m_offset, (unsigned)form);
 *offset_ptr = m_offset;
 return false;
   }



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

[Lldb-commits] [PATCH] D97769: [lldb] Apply gdb-remote timeout to platform connections as well

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: JDevlieghere, clayborg.
Herald added a subscriber: kristof.beyls.
labath requested review of this revision.
Herald added a project: LLDB.

We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.

After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca 
, it 
immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.

This patch makes the platform connections also respect the value of this
setting. This does create a slightly weird dependency, where one plugin
depends on the setting value from another plugin (of a completely
different kind). However, it seemed to me that creating a separate
setting for platform connections would be even more confusing. I'm open
to other ideas, though.

I also add a test which checks that the timeout value is being honored.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D97769

Files:
  lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/test/API/commands/platform/connect/TestPlatformConnect.py
  lldb/test/API/functionalities/gdb_remote_client/TestPlatformClient.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestPlatformClient.py
===
--- lldb/test/API/functionalities/gdb_remote_client/TestPlatformClient.py
+++ lldb/test/API/functionalities/gdb_remote_client/TestPlatformClient.py
@@ -1,6 +1,7 @@
 import lldb
 import binascii
 import os
+import time
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
 from gdbclientutils import *
@@ -64,3 +65,41 @@
 substrs=["error: no processes were found on the \"remote-linux\" platform"])
 finally:
 self.dbg.GetSelectedPlatform().DisconnectRemote()
+
+class TimeoutResponder(MockGDBServerResponder):
+"""A mock server, which takes a very long time to compute the working
+directory."""
+def __init__(self):
+MockGDBServerResponder.__init__(self)
+
+def qGetWorkingDir(self):
+time.sleep(10)
+return hexlify("/foo/bar")
+
+def test_no_timeout(self):
+"""Test that we honor the timeout setting. With a large enough timeout,
+we should get the CWD successfully."""
+
+self.server.responder = TestPlatformClient.TimeoutResponder()
+self.runCmd("settings set plugin.process.gdb-remote.packet-timeout 30")
+plat = lldb.SBPlatform("remote-linux")
+try:
+self.assertSuccess(plat.ConnectRemote(lldb.SBPlatformConnectOptions("connect://"
++ self.server.get_connect_address(
+self.assertEqual(plat.GetWorkingDirectory(), "/foo/bar")
+finally:
+plat.DisconnectRemote()
+
+def test_timeout(self):
+"""Test that we honor the timeout setting. With a small timeout, CWD
+retrieval should fail."""
+
+self.server.responder = TestPlatformClient.TimeoutResponder()
+self.runCmd("settings set plugin.process.gdb-remote.packet-timeout 3")
+plat = lldb.SBPlatform("remote-linux")
+try:
+self.assertSuccess(plat.ConnectRemote(lldb.SBPlatformConnectOptions("connect://"
++ self.server.get_connect_address(
+self.assertIsNone(plat.GetWorkingDirectory())
+finally:
+plat.DisconnectRemote()
Index: lldb/test/API/commands/platform/connect/TestPlatformConnect.py
===
--- lldb/test/API/commands/platform/connect/TestPlatformConnect.py
+++ lldb/test/API/commands/platform/connect/TestPlatformConnect.py
@@ -13,7 +13,6 @@
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 @skipIfWindows # lldb-server does not terminate correctly
 @skipIfDarwin # lldb-server not found correctly
-@skipIf(oslist=["linux"], archs=["arm", "aarch64"])  # Fails randomly
 @add_test_categories(["lldb-server"])
 def test_platform_process_connect(self):
 self.build()
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -68,6 +68,8 @@
 
   static const char *GetPluginDes

[Lldb-commits] [PATCH] D97230: [lldb] [test] Workaround symlink-related test failures

[Michał Górny via Phabricator via lldb-commits]

mgorny added a comment.
Herald added a subscriber: JDevlieghere.

I've edited both bugs (https://bugs.llvm.org/show_bug.cgi?id=48421 and 
https://bugs.llvm.org/show_bug.cgi?id=48376) to cover the generic problem. I 
can't promise I'll have time to work on them in the next ~2 months but if you 
have any suggestion how to solve them, I can try looking at them as time 
permits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97230

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

[Lldb-commits] [PATCH] D97721: [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

[Jan Kratochvil 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 rG4096ae06f47a: [lldb] Support DWARF-5 DW_FORM_line_strp (used 
by GCC) (authored by jankratochvil).

Changed prior to commit:
  https://reviews.llvm.org/D97721?vs=327364&id=327431#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97721

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
  lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s

Index: lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s
@@ -0,0 +1,181 @@
+# Test handling of DWARF5 DW_FORM_line_strp from .debug_info as used by GCC.
+
+# UNSUPPORTED: system-darwin, system-windows
+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -o %t -triple x86_64-pc-linux %s
+# RUN: %lldb %t -o "p main" \
+# RUN:   -o exit | FileCheck %s
+
+# CHECK: (void (*)()) $0 = 0x
+
+	.text
+.Ltext0:
+	.globl	main
+	.type	main, @function
+main:
+.LFB0:
+.LM1:
+.long	0
+.LM2:
+.long	0
+.LFE0:
+	.size	main, .-main
+.Letext0:
+	.section	.debug_info,"",@progbits
+.Ldebug_info0:
+	.long	.Ldebug_info0_end - .Ldebug_info0_start	# Length of Compilation Unit Info
+.Ldebug_info0_start:
+	.value	0x5	# DWARF version number
+	.byte	0x1	# DW_UT_compile
+	.byte	0x8	# Pointer Size (in bytes)
+	.long	.Ldebug_abbrev0	# Offset Into Abbrev. Section
+	.uleb128 0x1	# (DIE (0xc) DW_TAG_compile_unit)
+	.long	.LASF2	# DW_AT_producer: "GNU C17 11.0.0 20210210 (Red Hat 11.0.0-0) -mtune=generic -march=x86-64 -gdwarf-5 -gno-as-loc-support"
+	.byte	0x1d	# DW_AT_language
+	.long	.LASF0	# DW_AT_name: "main.c"
+	.long	.LASF1	# DW_AT_comp_dir: ""
+	.quad	.Ltext0	# DW_AT_low_pc
+	.quad	.Letext0-.Ltext0	# DW_AT_high_pc
+	.long	.Ldebug_line0	# DW_AT_stmt_list
+	.uleb128 0x2	# (DIE (0x2e) DW_TAG_subprogram)
+			# DW_AT_external
+	.long	.LASF3	# DW_AT_name: "main"
+	.byte	0x1	# DW_AT_decl_file (main.c)
+	.byte	0x1	# DW_AT_decl_line
+	.quad	.LFB0	# DW_AT_low_pc
+	.quad	.LFE0-.LFB0	# DW_AT_high_pc
+	.byte	0	# end of children of DIE 0xc
+.Ldebug_info0_end:
+	.section	.debug_abbrev,"",@progbits
+.Ldebug_abbrev0:
+	.uleb128 0x1	# (abbrev code)
+	.uleb128 0x11	# (TAG: DW_TAG_compile_unit)
+	.byte	0x1	# DW_children_yes
+	.uleb128 0x25	# (DW_AT_producer)
+	.uleb128 0xe	# (DW_FORM_strp)
+	.uleb128 0x13	# (DW_AT_language)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x1f	# (DW_FORM_line_strp)
+	.uleb128 0x1b	# (DW_AT_comp_dir)
+	.uleb128 0x1f	# (DW_FORM_line_strp)
+	.uleb128 0x11	# (DW_AT_low_pc)
+	.uleb128 0x1	# (DW_FORM_addr)
+	.uleb128 0x12	# (DW_AT_high_pc)
+	.uleb128 0x7	# (DW_FORM_data8)
+	.uleb128 0x10	# (DW_AT_stmt_list)
+	.uleb128 0x17	# (DW_FORM_sec_offset)
+	.byte	0
+	.byte	0
+	.uleb128 0x2	# (abbrev code)
+	.uleb128 0x2e	# (TAG: DW_TAG_subprogram)
+	.byte	0	# DW_children_no
+	.uleb128 0x3f	# (DW_AT_external)
+	.uleb128 0x19	# (DW_FORM_flag_present)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0xe	# (DW_FORM_strp)
+	.uleb128 0x3a	# (DW_AT_decl_file)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3b	# (DW_AT_decl_line)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x11	# (DW_AT_low_pc)
+	.uleb128 0x1	# (DW_FORM_addr)
+	.uleb128 0x12	# (DW_AT_high_pc)
+	.uleb128 0x7	# (DW_FORM_data8)
+	.byte	0
+	.byte	0
+	.uleb128 0x3	# (abbrev code)
+	.uleb128 0x24	# (TAG: DW_TAG_base_type)
+	.byte	0	# DW_children_no
+	.uleb128 0xb	# (DW_AT_byte_size)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3e	# (DW_AT_encoding)
+	.uleb128 0xb	# (DW_FORM_data1)
+	.uleb128 0x3	# (DW_AT_name)
+	.uleb128 0x8	# (DW_FORM_string)
+	.byte	0
+	.byte	0
+	.byte	0
+	.section	.debug_line,"",@progbits
+.Ldebug_line0:
+	.long	.LELT0-.LSLT0	# Length of Source Line Info
+.LSLT0:
+	.value	0x5	# DWARF version number
+	.byte	0x8	# Address Size
+	.byte	0	# Segment Size
+	.long	.LELTP0-.LASLTP0	# Prolog Length
+.LASLTP0:
+	.byte	0x1	# Minimum Instruction Length
+	.byte	0x1	# Maximum Operations Per Instruction
+	.byte	0x1	# Default is_stmt_start flag
+	.byte	0xf6	# Line Base Value (Special Opcodes)
+	.byte	0xf2	# Line Range Value (Special Opcodes)
+	.byte	0xd	# Special Opcode Base
+	.byte	0	# opcode: 0x1 has 0 args
+	.byte	0x1	# opcode: 0x2 has 1 args
+	.byte	0x1	# opcode: 0x3 has 1 args
+	.byte	0x1	# opcode: 0x4 has 1 args
+	.byte	0x1	# opcode: 0x5 has 1 args
+	.byte	0	# opcode: 0x6 has 0 args
+	.byte	0	# opcode: 0x7 has 0 args
+	.byte	0	# opcode: 0x8 has 0 args
+	.byte	0x1	# opcode: 0x9 has 1 args
+	.byte	0	# opcode: 0xa has 0 args
+	.byte	0	# opcode: 0xb has 0 args
+	.byte	0x1	# opcode: 0xc has 1 args
+	.byte	0x1	# Directory entry format count
+	.uleb128 0x1	# DW_LNCT_path
+	.uleb128 0x1f	# DW_FORM_line_strp
+	.uleb128 0x2	# Directories count
+	.long	.LASF1	# Dir

[Lldb-commits] [lldb] 4096ae0 - [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

[Jan Kratochvil via lldb-commits]

Author: Jan Kratochvil
Date: 2021-03-02T15:17:23+01:00
New Revision: 4096ae06f47af9db2c2550a2c34979edfbd91b8d

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

LOG: [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

LLDB has been failing on binaries produced by new GCC 11.0 with -gdwarf-5.

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

Added: 
lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s

Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
index 421298802645..bce25297c4c7 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -173,6 +173,7 @@ bool DWARFDebugInfoEntry::Extract(const DWARFDataExtractor 
&data,
 break;
 
   case DW_FORM_strp:
+  case DW_FORM_line_strp:
   case DW_FORM_sec_offset:
 data.GetU32(&offset);
 break;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
index 305f1cbd2826..ec78c5bbc9f4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -150,40 +150,40 @@ struct FormSize {
   uint8_t valid:1, size:7;
 };
 static FormSize g_form_sizes[] = {
-  {0,0}, // 0x00 unused
-  {0,0}, // 0x01 DW_FORM_addr
-  {0,0}, // 0x02 unused
-  {0,0}, // 0x03 DW_FORM_block2
-  {0,0}, // 0x04 DW_FORM_block4
-  {1,2}, // 0x05 DW_FORM_data2
-  {1,4}, // 0x06 DW_FORM_data4
-  {1,8}, // 0x07 DW_FORM_data8
-  {0,0}, // 0x08 DW_FORM_string
-  {0,0}, // 0x09 DW_FORM_block
-  {0,0}, // 0x0a DW_FORM_block1
-  {1,1}, // 0x0b DW_FORM_data1
-  {1,1}, // 0x0c DW_FORM_flag
-  {0,0}, // 0x0d DW_FORM_sdata
-  {1,4}, // 0x0e DW_FORM_strp
-  {0,0}, // 0x0f DW_FORM_udata
-  {0,0}, // 0x10 DW_FORM_ref_addr (addr size for DWARF2 and earlier, 4 bytes 
for
- // DWARF32, 8 bytes for DWARF32 in DWARF 3 and later
-  {1,1}, // 0x11 DW_FORM_ref1
-  {1,2}, // 0x12 DW_FORM_ref2
-  {1,4}, // 0x13 DW_FORM_ref4
-  {1,8}, // 0x14 DW_FORM_ref8
-  {0,0}, // 0x15 DW_FORM_ref_udata
-  {0,0}, // 0x16 DW_FORM_indirect
-  {1,4}, // 0x17 DW_FORM_sec_offset
-  {0,0}, // 0x18 DW_FORM_exprloc
-  {1,0}, // 0x19 DW_FORM_flag_present
-  {0,0}, // 0x1a
-  {0,0}, // 0x1b
-  {0,0}, // 0x1c
-  {0,0}, // 0x1d
-  {0,0}, // 0x1e
-  {0,0}, // 0x1f
-  {1,8}, // 0x20 DW_FORM_ref_sig8
+{0, 0}, // 0x00 unused
+{0, 0}, // 0x01 DW_FORM_addr
+{0, 0}, // 0x02 unused
+{0, 0}, // 0x03 DW_FORM_block2
+{0, 0}, // 0x04 DW_FORM_block4
+{1, 2}, // 0x05 DW_FORM_data2
+{1, 4}, // 0x06 DW_FORM_data4
+{1, 8}, // 0x07 DW_FORM_data8
+{0, 0}, // 0x08 DW_FORM_string
+{0, 0}, // 0x09 DW_FORM_block
+{0, 0}, // 0x0a DW_FORM_block1
+{1, 1}, // 0x0b DW_FORM_data1
+{1, 1}, // 0x0c DW_FORM_flag
+{0, 0}, // 0x0d DW_FORM_sdata
+{1, 4}, // 0x0e DW_FORM_strp
+{0, 0}, // 0x0f DW_FORM_udata
+{0, 0}, // 0x10 DW_FORM_ref_addr (addr size for DWARF2 and earlier, 4 bytes
+// for DWARF32, 8 bytes for DWARF32 in DWARF 3 and later
+{1, 1},  // 0x11 DW_FORM_ref1
+{1, 2},  // 0x12 DW_FORM_ref2
+{1, 4},  // 0x13 DW_FORM_ref4
+{1, 8},  // 0x14 DW_FORM_ref8
+{0, 0},  // 0x15 DW_FORM_ref_udata
+{0, 0},  // 0x16 DW_FORM_indirect
+{1, 4},  // 0x17 DW_FORM_sec_offset
+{0, 0},  // 0x18 DW_FORM_exprloc
+{1, 0},  // 0x19 DW_FORM_flag_present
+{0, 0},  // 0x1a DW_FORM_strx (ULEB128)
+{0, 0},  // 0x1b DW_FORM_addrx (ULEB128)
+{1, 4},  // 0x1c DW_FORM_ref_sup4
+{0, 0},  // 0x1d DW_FORM_strp_sup (4 bytes for DWARF32, 8 bytes for 
DWARF64)
+{1, 16}, // 0x1e DW_FORM_data16
+{1, 4},  // 0x1f DW_FORM_line_strp
+{1, 8},  // 0x20 DW_FORM_ref_sig8
 };
 
 llvm::Optional
@@ -286,6 +286,7 @@ bool DWARFFormValue::SkipValue(dw_form_t form,
 // 32 bit for DWARF 32, 64 for DWARF 64
 case DW_FORM_sec_offset:
 case DW_FORM_strp:
+case DW_FORM_line_strp:
   *offset_ptr += 4;
   return true;
 
@@ -398,7 +399,8 @@ void DWARFFormValue::Dump(Stream &s) const {
   case DW_FORM_udata:
 s.PutULEB128(uvalue);
 break;
-  case DW_FORM_strp: {
+  case DW_FORM_strp:
+  case DW_FORM_line_strp: {
 const char *dbg_str = AsCString();
 if (dbg_str) {
   s.QuotedCString(dbg_str);
@@ -606,6 +608,7 @@ bool DWARFFormValue::FormIsSupported(dw_form_t form) {
 case DW_FORM_flag:
 case DW_FORM_sdata:
 case DW_FORM_strp:
+case DW_FORM_line_strp:
 case DW_FORM_strx:

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

This looks good apart from minor nits inline




Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1357
+
+  if (error.Fail())
+return error;

ptrace request is a success if number of tags requested is not equal to no of 
tags read? If not then this and following condition may be redundant.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1157
+llvm::Expected
+NativeRegisterContextLinux_arm64::GetMemoryTaggingDetails(int32_t type) {
+  if (type == MemoryTagManagerAArch64MTE::eMTE_allocation) {

this piece needs to run clang-format



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3578
+
+  response.PutChar('m');
+  response.PutBytesAsRawHex8(tags.data(), tags.size());

Just curious response starts with 'm'. Whats the design need for using m in 
qMemTags response?



Comment at: 
lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py:19
+@skipUnlessPlatform(["linux"])
+@skipUnlessAArch64MTELinuxCompiler
+def test_qmemtags_packets(self):

If skipUnlessAArch64MTELinuxCompiler can check for AArch64 and Linux then we 
wont need above two decorators.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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

[Lldb-commits] [PATCH] D97765: [lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil accepted this revision.
jankratochvil added inline comments.
This revision is now accepted and ready to land.



Comment at: 
lldb/test/Shell/SymbolFile/DWARF/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu1.s:17
+
+// RUN: %clang -o %t --target=x86_64-pc-linux %s \
+// RUN:   
%S/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97765

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

[Lldb-commits] [PATCH] D97281: [lldb][AArch64] Add class for managing memory tags

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/Process/Utility/MemoryTagManagerAArch64MTE.cpp:43
+
+ptrdiff_t MemoryTagManagerAArch64MTE::AddressDiff(lldb::addr_t addr1,
+  lldb::addr_t addr2) const {

omjavaid wrote:
> DavidSpickett wrote:
> > omjavaid wrote:
> > > I am a little apprehensive about this AddressDiff function. AArch64 
> > > virtual address is either 48 bits or 52 bits. MTE start from 56th bit and 
> > > I believe bits (48 - 55) will be either set zero (for user address) and 
> > > set to one for kernel addresses. 
> > > I am not sure if there is an interface available for us to know if VA is 
> > > 48 or 52 bits. What do you think how should we manage this here.
> > I looked at this a while back and there is no user space way to tell what 
> > size virtual address you have. You can assume at least 48 but then the rest 
> > I think is handled by some backwards compatibility stuff that means you 
> > don't have to care.
> > 
> > What is an issue is this only ignores the tag bits, not the whole top byte. 
> > This is the instruction the ptrdiff intrinsic emits:
> > ```
> > C6.2.317 SUBPS
> > Subtract Pointer, setting Flags subtracts the 56-bit address held in the 
> > second source register from the 56-bit address
> > held in the first source register, sign-extends the result to 64-bits, and 
> > writes the result to the destination register. It
> > updates the condition flags based on the result of the subtraction.
> > ```
> > 
> > That assumes top byte ignore, so I should be doing the same here along with 
> > the sign extension to handle the 0/1 fill.
> > (this might apply to a lot more than just this diff call too)
> hmm .. yes GDB also assumes 52 bit address for AArch64. Did you try reading 
> kenel space address during testing and see what you get in that case may be 
> stepping into a syscall (never tried it with LLDB) not sure if this is a must 
> have for LLDB as its currently a user application debugger as far as AArch64 
> is concerned. 
> 
> Even if this is 52 bits VA this function assumes bit 52-55 set to zero? This 
> can also mean that by the time we get this address TBI interface would have 
> cleaned it up for us? 
> 
> I think we should have a way to figure out significant address bits and clean 
> up the rest. For now this needs no change but I guess I ll have to manage 
> this in TBI support and provided and interface for significant address bit 
> for a process.
> 
> 
I wasn't aware stepping into a syscall was a thing for lldb but I'll see what I 
can find.

General TBI handling would solve some of this, still need to sign extend based 
on bit 55 I think.

I'm going to change this to ignore the top byte always, so it'll work on a 
PAC+MTE system. Then later we can make it use the "proper" TBI hooks.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97281

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

[Lldb-commits] [PATCH] D97696: [lldb] Enable cross CU decl file test only for x64 Linux

[Andy Yankovsky via Phabricator via lldb-commits]

werat abandoned this revision.
werat added a comment.

The original commit was reverted, abandon in favor of 
https://reviews.llvm.org/D97765


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97696

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

[Lldb-commits] [PATCH] D97765: [lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)

[Andy Yankovsky via Phabricator via lldb-commits]

werat created this revision.
werat added reviewers: JDevlieghere, labath, 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.

Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because 
the assembly is not OS-independent.

(First attempt https://reviews.llvm.org/D96778 broke the build bots)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D97765

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  
lldb/test/Shell/SymbolFile/DWARF/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu1.s
  
lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s

Index: lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/Inputs/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu2.s
@@ -0,0 +1,160 @@
+	.text
+	.file	"inlinevar2.c"
+	.globl	other   # -- Begin function other
+	.type	other,@function
+other:  # @other
+.Lfunc_begin0:
+	.file	1 "" "inlinevar2.c"
+	.loc	1 3 0   # inlinevar2.c:3:0
+.Ltmp0:
+	.file	2 "" "./inlinevar.h"
+	.loc	2 2 16 prologue_end # ./inlinevar.h:2:16
+	movl	$42, %eax
+	.loc	2 3 10  # ./inlinevar.h:3:10
+	.loc	1 3 41  # inlinevar2.c:3:41
+	retq
+.Ltmp1:
+.Ltmp2:
+.Lfunc_end0:
+	.size	other, .Lfunc_end0-other
+# -- End function
+	.section	.debug_abbrev,"",@progbits
+	.byte	1   # Abbreviation Code
+	.byte	17  # DW_TAG_compile_unit
+	.byte	1   # DW_CHILDREN_yes
+	.byte	37  # DW_AT_producer
+	.byte	14  # DW_FORM_strp
+	.byte	19  # DW_AT_language
+	.byte	5   # DW_FORM_data2
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	16  # DW_AT_stmt_list
+	.byte	23  # DW_FORM_sec_offset
+	.byte	27  # DW_AT_comp_dir
+	.byte	14  # DW_FORM_strp
+	.byte	17  # DW_AT_low_pc
+	.byte	1   # DW_FORM_addr
+	.byte	18  # DW_AT_high_pc
+	.byte	6   # DW_FORM_data4
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	4   # Abbreviation Code
+	.byte	36  # DW_TAG_base_type
+	.byte	0   # DW_CHILDREN_no
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	62  # DW_AT_encoding
+	.byte	11  # DW_FORM_data1
+	.byte	11  # DW_AT_byte_size
+	.byte	11  # DW_FORM_data1
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	6   # Abbreviation Code
+	.byte	46  # DW_TAG_subprogram
+	.byte	1   # DW_CHILDREN_yes
+	.byte	17  # DW_AT_low_pc
+	.byte	1   # DW_FORM_addr
+	.byte	18  # DW_AT_high_pc
+	.byte	6   # DW_FORM_data4
+	.byte	64  # DW_AT_frame_base
+	.byte	24  # DW_FORM_exprloc
+	.byte	3   # DW_AT_name
+	.byte	14  # DW_FORM_strp
+	.byte	58  # DW_AT_decl_file
+	.byte	11  # DW_FORM_data1
+	.byte	59  # DW_AT_decl_line
+	.byte	11  # DW_FORM_data1
+	.byte	73  # DW_AT_type
+	.byte	19  # DW_FORM_ref4
+	.byte	63  # DW_AT_external
+	.byte	25  # DW_FORM_flag_present
+	.byte	0   # EOM(1)
+	.byte	0   # EOM(2)
+	.byte	7   # Abbreviation Code
+	.byte	29  # DW_TAG_inlined_subroutine

[Lldb-commits] [PATCH] D97281: [lldb][AArch64] Add class for managing memory tags

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added inline comments.



Comment at: 
lldb/source/Plugins/Process/Utility/MemoryTagManagerAArch64MTE.cpp:43
+
+ptrdiff_t MemoryTagManagerAArch64MTE::AddressDiff(lldb::addr_t addr1,
+  lldb::addr_t addr2) const {

DavidSpickett wrote:
> omjavaid wrote:
> > I am a little apprehensive about this AddressDiff function. AArch64 virtual 
> > address is either 48 bits or 52 bits. MTE start from 56th bit and I believe 
> > bits (48 - 55) will be either set zero (for user address) and set to one 
> > for kernel addresses. 
> > I am not sure if there is an interface available for us to know if VA is 48 
> > or 52 bits. What do you think how should we manage this here.
> I looked at this a while back and there is no user space way to tell what 
> size virtual address you have. You can assume at least 48 but then the rest I 
> think is handled by some backwards compatibility stuff that means you don't 
> have to care.
> 
> What is an issue is this only ignores the tag bits, not the whole top byte. 
> This is the instruction the ptrdiff intrinsic emits:
> ```
> C6.2.317 SUBPS
> Subtract Pointer, setting Flags subtracts the 56-bit address held in the 
> second source register from the 56-bit address
> held in the first source register, sign-extends the result to 64-bits, and 
> writes the result to the destination register. It
> updates the condition flags based on the result of the subtraction.
> ```
> 
> That assumes top byte ignore, so I should be doing the same here along with 
> the sign extension to handle the 0/1 fill.
> (this might apply to a lot more than just this diff call too)
hmm .. yes GDB also assumes 52 bit address for AArch64. Did you try reading 
kenel space address during testing and see what you get in that case may be 
stepping into a syscall (never tried it with LLDB) not sure if this is a must 
have for LLDB as its currently a user application debugger as far as AArch64 is 
concerned. 

Even if this is 52 bits VA this function assumes bit 52-55 set to zero? This 
can also mean that by the time we get this address TBI interface would have 
cleaned it up for us? 

I think we should have a way to figure out significant address bits and clean 
up the rest. For now this needs no change but I guess I ll have to manage this 
in TBI support and provided and interface for significant address bit for a 
process.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97281

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

[Lldb-commits] [PATCH] D97498: [LLDB] Support GDB remote g packet partial read

[Muhammad Omair Javaid 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 rG536783170f08: Support GDB remote g packet partial read 
(authored by omjavaid).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97498

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
  lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py
===
--- /dev/null
+++ lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py
@@ -0,0 +1,106 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+class TestPartialGPacket(GDBRemoteTestBase):
+
+@skipIfXmlSupportMissing
+@skipIfRemote
+def test(self):
+"""
+Test GDB remote fallback to 'p' packet when 'g' packet does not include all registers.
+"""
+class MyResponder(MockGDBServerResponder):
+
+def qXferRead(self, obj, annex, offset, length):
+if annex == "target.xml":
+return """
+
+
+arm
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+""", False
+else:
+return None, False
+
+def readRegister(self, regnum):
+if regnum == 31:
+return "cdcc8c3f"
+return "E01"
+
+def readRegisters(self):
+return "2000f836002000102fcb0008f8360020a0360020200c0020b87f0120b7d100082ed200080001"
+
+def haltReason(self):
+return "S05"
+
+def qfThreadInfo(self):
+return "mdead"
+
+def qC(self):
+return ""
+
+def qSupported(self, client_supported):
+return "PacketSize=4000;qXfer:memory-map:read-;QStartNoAckMode+;qXfer:threads:read+;hwbreak+;qXfer:features:read+"
+
+def QThreadSuffixSupported(self):
+return "OK"
+
+def QListThreadsInStopReply(self):
+return "OK"
+
+self.server.responder = MyResponder()
+if self.TraceOn():
+self.runCmd("log enable gdb-remote packets")
+self.addTearDownHook(
+lambda: self.runCmd("log disable gdb-remote packets"))
+
+self.dbg.SetDefaultArchitecture("armv7em")
+target = self.dbg.CreateTargetWithFileAndArch(None, None)
+
+process = self.connect(target)
+
+if self.TraceOn():
+interp = self.dbg.GetCommandInterpreter()
+result = lldb.SBCommandReturnObject()
+interp.HandleCommand("target list", result)
+print(result.GetOutput())
+
+r0_valobj = process.GetThreadAtIndex(
+0).GetFrameAtIndex(0).FindRegister("r0")
+self.assertEqual(r0_valobj.GetValueAsUnsigned(), 0x20)
+
+pc_valobj = process.GetThreadAtIndex(
+0).GetFrameAtIndex(0).FindRegister("pc")
+self.assertEqual(pc_valobj.GetValueAsUnsigned(), 0x0800d22e)
+
+pc_valobj = process.GetThreadAtIndex(
+0).GetFrameAtIndex(0).FindRegister("CONTROL")
+self.assertEqual(pc_valobj.GetValueAsUnsigned(), 0x3f8d)
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -118,6 +118,7 @@
   DataExtractor m_reg_data;
   bool m_read_all_at_once;
   bool m_write_all_at_once;
+  bool m_gpacket_cached;
 
 private:
   // Helper function for ReadRegisterBytes().
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
===
--- lldb/source/Plugins/Process/gdb-

[Lldb-commits] [lldb] 5367831 - Support GDB remote g packet partial read

[Muhammad Omair Javaid via lldb-commits]

Author: Muhammad Omair Javaid
Date: 2021-03-02T17:21:48+05:00
New Revision: 536783170f0843838b2d521f8a0331f174f60e3c

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

LOG: Support GDB remote g packet partial read

GDB remote protocol does not specify length of g packet for register read. It 
depends on remote to include all or exclude certain registers from g packet. In 
case a register or set of registers is not included as part of g packet then we 
should fall back to p packet for reading all registers excluded from g packet 
by remote. This patch adds support for above feature and adds a test-case for 
the same.

Reviewed By: labath

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

Added: 
lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py

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

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index b607b156d7b4..1f50194e82f4 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -36,7 +36,7 @@ GDBRemoteRegisterContext::GDBRemoteRegisterContext(
 : RegisterContext(thread, concrete_frame_idx),
   m_reg_info_sp(std::move(reg_info_sp)), m_reg_valid(), m_reg_data(),
   m_read_all_at_once(read_all_at_once),
-  m_write_all_at_once(write_all_at_once) {
+  m_write_all_at_once(write_all_at_once), m_gpacket_cached(false) {
   // Resize our vector of bools to contain one bool for every register. We will
   // use these boolean values to know when a register value is valid in
   // m_reg_data.
@@ -57,6 +57,7 @@ void GDBRemoteRegisterContext::InvalidateAllRegisters() {
 }
 
 void GDBRemoteRegisterContext::SetAllRegisterValid(bool b) {
+  m_gpacket_cached = b;
   std::vector::iterator pos, end = m_reg_valid.end();
   for (pos = m_reg_valid.begin(); pos != end; ++pos)
 *pos = b;
@@ -200,7 +201,7 @@ bool GDBRemoteRegisterContext::ReadRegisterBytes(const 
RegisterInfo *reg_info,
   const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
 
   if (!GetRegisterIsValid(reg)) {
-if (m_read_all_at_once) {
+if (m_read_all_at_once && !m_gpacket_cached) {
   if (DataBufferSP buffer_sp =
   gdb_comm.ReadAllRegisters(m_thread.GetProtocolID())) {
 memcpy(const_cast(m_reg_data.GetDataStart()),
@@ -221,7 +222,10 @@ bool GDBRemoteRegisterContext::ReadRegisterBytes(const 
RegisterInfo *reg_info,
   m_reg_valid[i] = false;
 }
   }
-  return true;
+
+  m_gpacket_cached = true;
+  if (GetRegisterIsValid(reg))
+return true;
 } else {
   Log 
*log(ProcessGDBRemoteLog::GetLogIfAnyCategoryIsSet(GDBR_LOG_THREAD |
 
GDBR_LOG_PACKETS));
@@ -233,9 +237,9 @@ bool GDBRemoteRegisterContext::ReadRegisterBytes(const 
RegisterInfo *reg_info,
   " bytes "
   "but only got %" PRId64 " bytes.",
   m_reg_data.GetByteSize(), buffer_sp->GetByteSize());
+  return false;
 }
   }
-  return false;
 }
 if (reg_info->value_regs) {
   // Process this composite register request by delegating to the

diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
index 252d7b359ee8..18fcb73b9815 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.h
@@ -118,6 +118,7 @@ class GDBRemoteRegisterContext : public RegisterContext {
   DataExtractor m_reg_data;
   bool m_read_all_at_once;
   bool m_write_all_at_once;
+  bool m_gpacket_cached;
 
 private:
   // Helper function for ReadRegisterBytes().

diff  --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py
new file mode 100644
index ..14614875811d
--- /dev/null
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestPartialGPacket.py
@@ -0,0 +1,106 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+class TestPartialGPacket(GDBRemoteTestBase):
+
+@skipIfXmlSupportMissing
+@skipIfRemote
+def test(self):
+"""
+Test GDB remote fallback to 'p' packet when 'g' packet does not 
include all registers.
+

[Lldb-commits] [PATCH] D97696: [lldb] Enable cross CU decl file test only for x64 Linux

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

You can just directly land these bot fixes (or you revert the original aptch). 
Not sure if I'm the right person to review this as I rarely touch the shell 
tests, but Jonas or Pavel probably know for sure what's the proper way to 
restrict the test environment for this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97696

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

[Lldb-commits] [PATCH] D97760: [lldb][NFC] Delete unused AddressResolverName

[Raphael Isemann via Phabricator via lldb-commits]

teemperor created this revision.
teemperor added a reviewer: LLDB.
teemperor added a project: LLDB.
Herald added subscribers: JDevlieghere, mgorny.
teemperor requested review of this revision.

That's all just dead code that hasn't been changed in years.


https://reviews.llvm.org/D97760

Files:
  lldb/include/lldb/Core/AddressResolverName.h
  lldb/source/API/SBTarget.cpp
  lldb/source/Core/AddressResolverName.cpp
  lldb/source/Core/CMakeLists.txt

Index: lldb/source/Core/CMakeLists.txt
===
--- lldb/source/Core/CMakeLists.txt
+++ lldb/source/Core/CMakeLists.txt
@@ -24,7 +24,6 @@
   AddressRange.cpp
   AddressResolver.cpp
   AddressResolverFileLine.cpp
-  AddressResolverName.cpp
   Communication.cpp
   Debugger.cpp
   Disassembler.cpp
Index: lldb/source/Core/AddressResolverName.cpp
===
--- lldb/source/Core/AddressResolverName.cpp
+++ /dev/null
@@ -1,198 +0,0 @@
-//===-- AddressResolverName.cpp ---===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#include "lldb/Core/AddressResolverName.h"
-
-#include "lldb/Core/Address.h"
-#include "lldb/Core/AddressRange.h"
-#include "lldb/Core/Module.h"
-#include "lldb/Symbol/Function.h"
-#include "lldb/Symbol/Symbol.h"
-#include "lldb/Symbol/SymbolContext.h"
-#include "lldb/Utility/Log.h"
-#include "lldb/Utility/Logging.h"
-#include "lldb/Utility/Stream.h"
-#include "lldb/lldb-enumerations.h"
-#include "lldb/lldb-forward.h"
-#include "lldb/lldb-types.h"
-#include "llvm/ADT/StringRef.h"
-
-#include 
-#include 
-#include 
-
-#include 
-
-using namespace lldb;
-using namespace lldb_private;
-
-AddressResolverName::AddressResolverName(const char *func_name,
- AddressResolver::MatchType type)
-: AddressResolver(), m_func_name(func_name), m_class_name(nullptr),
-  m_regex(), m_match_type(type) {
-  if (m_match_type == AddressResolver::Regexp) {
-m_regex = RegularExpression(m_func_name.GetStringRef());
-if (!m_regex.IsValid()) {
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_BREAKPOINTS));
-
-  if (log)
-log->Warning("function name regexp: \"%s\" did not compile.",
- m_func_name.AsCString());
-}
-  }
-}
-
-AddressResolverName::AddressResolverName(RegularExpression func_regex)
-: AddressResolver(), m_func_name(nullptr), m_class_name(nullptr),
-  m_regex(std::move(func_regex)), m_match_type(AddressResolver::Regexp) {}
-
-AddressResolverName::AddressResolverName(const char *class_name,
- const char *method,
- AddressResolver::MatchType type)
-: AddressResolver(), m_func_name(method), m_class_name(class_name),
-  m_regex(), m_match_type(type) {}
-
-AddressResolverName::~AddressResolverName() = default;
-
-// FIXME: Right now we look at the module level, and call the module's
-// "FindFunctions".
-// Greg says he will add function tables, maybe at the CompileUnit level to
-// accelerate function lookup.  At that point, we should switch the depth to
-// CompileUnit, and look in these tables.
-
-Searcher::CallbackReturn
-AddressResolverName::SearchCallback(SearchFilter &filter,
-SymbolContext &context, Address *addr) {
-  SymbolContextList func_list;
-  SymbolContextList sym_list;
-
-  bool skip_prologue = true;
-  uint32_t i;
-  SymbolContext sc;
-  Address func_addr;
-
-  Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_BREAKPOINTS));
-
-  if (m_class_name) {
-if (log)
-  log->Warning("Class/method function specification not supported yet.\n");
-return Searcher::eCallbackReturnStop;
-  }
-
-  const bool include_symbols = false;
-  const bool include_inlines = true;
-  switch (m_match_type) {
-  case AddressResolver::Exact:
-if (context.module_sp) {
-  context.module_sp->FindSymbolsWithNameAndType(m_func_name,
-eSymbolTypeCode, sym_list);
-  context.module_sp->FindFunctions(m_func_name, CompilerDeclContext(),
-   eFunctionNameTypeAuto, include_symbols,
-   include_inlines, func_list);
-}
-break;
-
-  case AddressResolver::Regexp:
-if (context.module_sp) {
-  context.module_sp->FindSymbolsMatchingRegExAndType(
-  m_regex, eSymbolTypeCode, sym_list);
-  context.module_sp->FindFunctions(m_regex, include_symbols,
-   include_inlines, func_list);
-}
-break;
-
-  case AddressResolver::Glob:
-if (log)
-  

[Lldb-commits] [lldb] 1432ab1 - [lldb] Add missing include to Cloneable.h

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2021-03-02T11:01:08+01:00
New Revision: 1432ab171f9dece77b141d6c11da895275de14be

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

LOG: [lldb] Add missing include to Cloneable.h

This header is using make_shared so it needs to include .

Added: 


Modified: 
lldb/include/lldb/Utility/Cloneable.h

Removed: 




diff  --git a/lldb/include/lldb/Utility/Cloneable.h 
b/lldb/include/lldb/Utility/Cloneable.h
index 7082f3a59ce5..4c9b7ae340dc 100644
--- a/lldb/include/lldb/Utility/Cloneable.h
+++ b/lldb/include/lldb/Utility/Cloneable.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_UTILITY_CLONEABLE_H
 #define LLDB_UTILITY_CLONEABLE_H
 
+#include 
 #include 
 
 namespace lldb_private {



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

[Lldb-commits] [lldb] a63daf6 - [lldb] Remote leftover _llgs from TestGdbRemoteConnection.py

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2021-03-02T10:59:25+01:00
New Revision: a63daf693ca4b67d8fae8546024d954fb2659c24

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

LOG: [lldb] Remote leftover _llgs from TestGdbRemoteConnection.py

the suffix will be added when the test is instantiated for llgs and
debugserver.

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 c9799d1976cb..a82f4a8279b3 100644
--- a/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
+++ b/lldb/test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py
@@ -128,14 +128,14 @@ class 
TestGdbRemoteConnection(gdbremote_testcase.GdbRemoteTestCaseBase):
 mydir = TestBase.compute_mydir(__file__)
 
 @skipIfRemote  # reverse connect is not a supported use case for now
-def test_reverse_connect_llgs(self):
+def test_reverse_connect(self):
 # Reverse connect is the default connection method.
 self.connect_to_debug_monitor()
 # Verify we can do the handshake.  If that works, we'll call it good.
 self.do_handshake(self.sock)
 
 @skipIfRemote
-def test_named_pipe_llgs(self):
+def test_named_pipe(self):
 family, type, proto, _, addr = socket.getaddrinfo(
 self.stub_hostname, 0, proto=socket.IPPROTO_TCP)[0]
 self.sock = socket.socket(family, type, proto)



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

[Lldb-commits] [PATCH] D97586: [mlir][lldb] Fix several gcc warnings in mlir and lldb

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added inline comments.



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:119
   lldb::TraceSP trace_sp = traceOrErr.get();
-  if (m_options.m_verbose)
+  if (m_options.m_verbose && trace_sp)
 result.AppendMessageWithFormat("loading trace with plugin %s\n",

stella.stamenova wrote:
> teemperor wrote:
> > Do you still have that GCC warning around (or the GCC version that produced 
> > that warning)? I'm kinda curious what GCC is assuming here. The interface 
> > never returns a "null" shared_ptr, the shared_ptr either contains a valid 
> > object or llvm::Error is returned. IIRC the Expected return is the 
> > "new" version of how the Plugin interface should work (the old was just a 
> > ptr with `nullptr` being an error), so if some GCC version doesn't 
> > understand the Expected pattern then we should maybe have some more 
> > centralized workaround instead of adding all the unnecessary nullptr checks.
> > 
> > But that shouldn't block this patch, so feel free to land.
> The gcc version is:
> 
> `gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0`
> 
> The warning is:
> 
> ```
> /mnt/_work/9/s/llvm-project/lldb/source/Commands/CommandObjectTrace.cpp: In 
> member function ‘virtual bool 
> CommandObjectTraceLoad::DoExecute(lldb_private::Args&, 
> lldb_private::CommandReturnObject&)’:
> /mnt/_work/9/s/llvm-project/lldb/source/Commands/CommandObjectTrace.cpp:120:39:
>  error: ‘%s’ directive argument is null [-Werror=format-overflow=]
>   120 | result.AppendMessageWithFormat("loading trace with plugin 
> %s\n",
>   | 
> ~~^~
>   121 |
> trace_sp->GetPluginName().AsCString());
>   |
> ~~
> /mnt/_work/9/s/llvm-project/lldb/source/Commands/CommandObjectTrace.cpp:120:39:
>  error: ‘%s’ directive argument is null [-Werror=format-overflow=]
> ```
> 
> Interestingly, this is the only place in all of llvm (well, llvm, lld, clang 
> and lldb) that produces this warning.
> 
Ah, the problem is that we call `AsCString` and because ConstString's API was 
literally developed in hell this function returns `nullptr` if the ConstString 
is empty (or the weird null state). I'm gonna make a patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97586

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

[Lldb-commits] [PATCH] D97449: [Diagnose] Unify MCContext and LLVMContext diagnosing

[Yuanfang Chen 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 rG5de2d189e6ad: [Diagnose] Unify MCContext and LLVMContext 
diagnosing (authored by ychen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97449

Files:
  clang/include/clang/Basic/DiagnosticCategories.td
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/CodeGen/CodeGenAction.cpp
  lldb/source/Expression/IRExecutionUnit.cpp
  llvm/include/llvm/CodeGen/AsmPrinter.h
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/LLVMContext.h
  llvm/include/llvm/MC/MCContext.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
  llvm/lib/CodeGen/MachineModuleInfo.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/LLVMContext.cpp
  llvm/lib/IR/LLVMContextImpl.h
  llvm/lib/MC/MCContext.cpp
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/test/CodeGen/AMDGPU/lds-initializer.ll
  llvm/test/CodeGen/AMDGPU/lds-zero-initializer.ll
  llvm/test/CodeGen/XCore/section-name.ll
  llvm/tools/llc/llc.cpp

Index: llvm/tools/llc/llc.cpp
===
--- llvm/tools/llc/llc.cpp
+++ llvm/tools/llc/llc.cpp
@@ -290,6 +290,22 @@
   bool *HasError;
   LLCDiagnosticHandler(bool *HasErrorPtr) : HasError(HasErrorPtr) {}
   bool handleDiagnostics(const DiagnosticInfo &DI) override {
+if (DI.getKind() == llvm::DK_SrcMgr) {
+  const auto &DISM = cast(DI);
+  const SMDiagnostic &SMD = DISM.getSMDiag();
+
+  if (SMD.getKind() == SourceMgr::DK_Error)
+*HasError = true;
+
+  SMD.print(nullptr, errs());
+
+  // For testing purposes, we print the LocCookie here.
+  if (DISM.isInlineAsmDiag() && DISM.getLocCookie())
+WithColor::note() << "!srcloc = " << DISM.getLocCookie() << "\n";
+
+  return true;
+}
+
 if (DI.getSeverity() == DS_Error)
   *HasError = true;
 
@@ -305,19 +321,6 @@
   }
 };
 
-static void InlineAsmDiagHandler(const SMDiagnostic &SMD, void *Context,
- unsigned LocCookie) {
-  bool *HasError = static_cast(Context);
-  if (SMD.getKind() == SourceMgr::DK_Error)
-*HasError = true;
-
-  SMD.print(nullptr, errs());
-
-  // For testing purposes, we print the LocCookie here.
-  if (LocCookie)
-WithColor::note() << "!srcloc = " << LocCookie << "\n";
-}
-
 // main - Entry point for the llc compiler.
 //
 int main(int argc, char **argv) {
@@ -367,7 +370,6 @@
   bool HasError = false;
   Context.setDiagnosticHandler(
   std::make_unique(&HasError));
-  Context.setInlineAsmDiagnosticHandler(InlineAsmDiagHandler, &HasError);
 
   Expected> RemarksFileOrErr =
   setupLLVMOptimizationRemarks(Context, RemarksFilename, RemarksPasses,
Index: llvm/test/CodeGen/XCore/section-name.ll
===
--- llvm/test/CodeGen/XCore/section-name.ll
+++ llvm/test/CodeGen/XCore/section-name.ll
@@ -1,4 +1,4 @@
-; RUN: llc < %s -march=xcore -o /dev/null 2>&1 | FileCheck %s
+; RUN: not llc < %s -march=xcore -o /dev/null 2>&1 | FileCheck %s
 
 @bar = internal global i32 zeroinitializer
 
Index: llvm/test/CodeGen/AMDGPU/lds-zero-initializer.ll
===
--- llvm/test/CodeGen/AMDGPU/lds-zero-initializer.ll
+++ llvm/test/CodeGen/AMDGPU/lds-zero-initializer.ll
@@ -1,7 +1,7 @@
-; RUN: llc -march=amdgcn -mcpu=tahiti < %s -o /dev/null 2>&1 | FileCheck %s
-; RUN: llc -march=amdgcn -mcpu=tonga < %s -o /dev/null 2>&1 | FileCheck %s
+; RUN: not llc -march=amdgcn -mcpu=tahiti -filetype=null < %s 2>&1 | FileCheck %s
+; RUN: not llc -march=amdgcn -mcpu=tonga -filetype=null < %s 2>&1 | FileCheck %s
 
-; CHECK: lds: unsupported initializer for address space
+; CHECK: error: lds: unsupported initializer for address space
 
 @lds = addrspace(3) global [256 x i32] zeroinitializer
 
Index: llvm/test/CodeGen/AMDGPU/lds-initializer.ll
===
--- llvm/test/CodeGen/AMDGPU/lds-initializer.ll
+++ llvm/test/CodeGen/AMDGPU/lds-initializer.ll
@@ -1,5 +1,5 @@
-; RUN: llc -march=amdgcn -mcpu=tahiti < %s -o /dev/null 2>&1 | FileCheck %s
-; RUN: llc -march=amdgcn -mcpu=tonga < %s -o /dev/null 2>&1 | FileCheck %s
+; RUN: not llc -march=amdgcn -mcpu=tahiti < %s -o /dev/null 2>&1 | FileCheck %s
+; RUN: not llc -march=amdgcn -mcpu=tonga < %s -o /dev/null 2>&1 | FileCheck %s
 
 ; CHECK: lds: unsupported initializer for address space
 
Index: llvm/lib/MC/MCParser/AsmParser.cpp
===
--- llvm/lib/MC/MCParser/AsmParser.cpp
+++ llvm/lib/MC/MCParser/AsmParser.cpp
@@ -2348,7 +2348,7 @@
 /// will use the last parsed cpp hash line filename comment
 /// for the Filename and LineNo if any in the diagnostic.
 void AsmParser::DiagHand

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

[Pavel Labath via Phabricator via lldb-commits]

labath added a subscriber: nitesh.jain.
labath added a comment.

Hm I'm very tempted to delete the linux mips implementation -- it uses 
several techniques which are getting in the way of this patch (and also some 
others in the past), for a lot of those, we now have different/better ways of 
doing it. On top of that, it's completely unmaintained (last non-nfc change to 
the file was in 2017, and the author (@nitesh.jain) does not appear to be 
active anymore.


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

https://reviews.llvm.org/D96766

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

[Lldb-commits] [PATCH] D97486: [lldb/Core] Change large function threshold variable into a setting.

[Med Ismail Bennani via Phabricator via lldb-commits]

mib added a comment.

In D97486#2596523 , @labath wrote:

> As the author of this logic, I want to note that the original limit I chose 
> was very arbitrary, and 32k (or any other small-ish number would work equally 
> well). The main objective was to disable accidental multi-megabyte 
> disassemblies (which can happen when the object file has no symbol 
> information).
>
> I'm not actually opposed to the, just wanting to make sure you're not adding 
> it on my account.

I made that change after being requested to increase the limit. I thought 
turning it into a setting gives the user more flexibility.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97486

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

[Lldb-commits] [PATCH] D97739: Add a progress class that can track and report long running operations that happen in LLDB.

[Raphael Isemann via Phabricator via lldb-commits]

teemperor requested changes to this revision.
teemperor added a comment.
This revision now requires changes to proceed.

Thanks for working on this. I really like the idea and I think this would be 
really cool to have. I do have some concerns about the way this is implemented 
though (see inline comments).




Comment at: lldb/include/lldb/Core/Progress.h:100
+  /// The title of the progress activity.
+  ConstString m_message;
+  /// How much work ([0...m_total]) that has been completed.

`std::string`



Comment at: lldb/include/lldb/Core/Progress.h:19
+public:
+  Progress(uint64_t total, const char *format, ...)
+  __attribute__((format(printf, 3, 4)));

clayborg wrote:
> clayborg wrote:
> > JDevlieghere wrote:
> > > I'm not a fan of how we'rere-implementing printf across different utility 
> > > classes. Can we have this take  `std::string` (that we move into the 
> > > member) and have the caller use `formatv` or something to construct the 
> > > string? 
> > Were are not implementing printf, just forwarding to a var args. If we 
> > switch over to anything we should switch to ConstString since we report the 
> > same ConstString on each callback.
> If we do switch to "ConstString message" can you add inline code suggestions 
> for using formatv for one of the Progress constructors to see how it would 
> look?
I don't see why we even need formatv for the current examples which just 
concatenate two strings. I also don't see why the constructor needs to do any 
formatting in the first place.

FWIW, with formatv this could be done like this:

```Progress bla(3423, llvm::formatv("Indexing file {0}", path))```

Or, as this is also just concatenating two strings:
```Progress bla(3423, "Indexing file " + path)```

What's even better about this though is that we can move the `total` parameter 
to the end where we can just make it optional (and even better, a real 
`llvm::Optional` that defaults to `llvm::None` instead of a magic `UINT64_MAX` 
value).



Comment at: lldb/source/Core/Module.cpp:1076
-  std::lock_guard guard(m_mutex);
-
   if (level >= eDescriptionLevelFull) {

I want to ask why but I fear the answer.



Comment at: lldb/source/Core/Progress.cpp:18
+void *Progress::g_callback_baton = nullptr;
+uint64_t Progress::g_progress_id = 0;
+

I would really like to avoid the global state that is introduced here, but I 
assume the idea here is to avoid having to pass around a Debugger object to all 
parts of LLDB (especially the ones which aren't tied to a Debugger).

Anyway, a few comments on the current approach:
* One callback is rather limiting. If I have an IDE with a progress bar that 
has an embedded LLDB command line, then I guess both want to subscribe to 
progress events? Right now the one that starts later will steal the progress 
notifications from whatever client has subscribed earlier.
* This needs to be made thread-safe (right now I can call 
`lldb::SBDebugger::SetProgressCallback` and just snitch away `g_callback` in 
the middle of printing the progress -> crash).

As we probably end up with some kind of global state object that manages this 
stuff, I would also suggest we put this into the normal subsystem init/deinit 
infrastructure (i.e., give it a `Initialize`/`Terminate` call). This way this 
won't be another "intentional leak" and we can properly use this in unit tests 
(where we can init/deinit subsystems and cleanup this state automatically).



Comment at: lldb/source/Core/Progress.cpp:39
+
+void Progress::Increment(uint64_t amount) {
+  if (amount > 0) {

So, just to be clear what's going on here: This is the function we expect 
several  'working' threads to call? From the current uses in `ManualDWARFIndex` 
that seems to be the case, but I don't see how this will work out.

1. Whoever receives the "progress report" callback needs to be ready to handle 
receiving multiple events from multiple threads. The VSCode callback isn't 
thread safe from what I can see and user-callbacks will also not be 
thread-safe. Either we make it really, really, really clear that the progress 
callbacks arrive from several threads or we somehow try to make this code 
handle the multi-threading for the user.
2. The logic here isn't thread-safe (`m_completed` is atomic, but that doesn't 
make the surrounding logic thread-safe).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97739

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

[Lldb-commits] [PATCH] D97498: [LLDB] Support GDB remote g packet partial read

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Seems reasonable. I think the names like `m_read_all_at_once` and 
`ReadAllRegisters` will now be somewhat confusing. Maybe it would be worth (in 
a separate patch) renaming them to something which does not include "all" in 
the name.
Maybe we could use `m_use_g_packet_for_reading/writing` instead of 
`m_read/write_all_at_once`. I'm not sure what would be a good name for 
`ReadAllRegisters`... Gdb docs describe the `g` packet as "Read general 
registers" so maybe just `ReadGeneralRegisters` with some comment that this may 
in fact include all of them?


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

https://reviews.llvm.org/D97498

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

[Lldb-commits] [PATCH] D97486: [lldb/Core] Change large function threshold variable into a setting.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D97486#2596523 , @labath wrote:

> I'm not actually opposed to the, just wanting to make sure you're not adding 
> it on my account.

to the **setting**


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97486

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

[Lldb-commits] [PATCH] D97486: [lldb/Core] Change large function threshold variable into a setting.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

As the author of this logic, I want to note that the original limit I chose was 
very arbitrary, and 32k (or any other small-ish number would work equally 
well). The main objective was to disable accidental multi-megabyte 
disassemblies (which can happen when the object file has no symbol information).

I'm not actually opposed to the, just wanting to make sure you're not adding it 
on my account.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97486

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

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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D95712#2566203 , @JDevlieghere 
wrote:

> 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?

Making the api flexible alleviates a lot of my concerns. Thanks.


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] D97721: [lldb] Support DWARF-5 DW_FORM_line_strp (used by GCC)

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks good.




Comment at: lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s:51-54
+   .uleb128 0x3# (DIE (0x4c) DW_TAG_base_type)
+   .byte   0x4 # DW_AT_byte_size
+   .byte   0x5 # DW_AT_encoding
+   .ascii "int\0"  # DW_AT_name

If you make the function return type `void`, this will go away.



Comment at: lldb/test/Shell/SymbolFile/DWARF/dwarf5-line-strp.s:114-125
+   .section.debug_aranges,"",@progbits
+   .long   0x2c# Length of Address Ranges Info
+   .value  0x2 # DWARF aranges version
+   .long   .Ldebug_info0   # Offset of Compilation Unit Info
+   .byte   0x8 # Size of Address
+   .byte   0   # Size of Segment Descriptor
+   .value  0   # Pad to 16 byte boundary

You can delete this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97721

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