[Lldb-commits] [PATCH] D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added inline comments.



Comment at: lldb/source/Core/SearchFilter.cpp:722
+  return false;
+  }
+

jankratochvil wrote:
> This `IsSourceImplementationFile()` should be checking the filename requested 
> by user, not filename found in DWARF. It should be in 
> `SearchFilterByModuleListAndCU::GetFilterRequiredItems()` where it should 
> check the filename in `m_cu_spec_list`. The whole `GetInlineStrategy()` is 
> there only for performance, if it was fast enough it would be always best to 
> use `eInlineBreakpointsAlways`. So here when you already have fully parsed 
> DIE for the function+type it no longer makes sense to check for any 
> performance optimization possibility. If `eInlineBreakpointsNever` or 
> `eInlineBreakpointsHeaders` shows more breakpoint locations than expected 
> (and still not more than `eInlineBreakpointsAlways`) then it is not a bug but 
> just a missed performance optimization.
> And after you fully move this 
> `GetInlineStrategy()+IsSourceImplementationFile()` into 
> `SearchFilterByModuleListAndCU::GetFilterRequiredItems()` then you can drop 
> it from `Target::CreateBreakpoint` at `lldb/source/Target/Target.cpp:330` as 
> it no longer has any effect there.
> IMO one should implement the `DW_AT_decl_file` check also into 
> `SymbolFileDWARF::ResolveSymbolContext` at 
> `lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp`:1977 and other 
> non-DWARF formats. As otherwise properly found candidates can be discarded at 
> the end.
That last `SymbolFileDWARF::ResolveSymbolContext` needs no change, it is 
already checking `GetSupportFiles()`, discard my last paragraph.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74136



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

[Lldb-commits] [PATCH] D82522: [lldb/IOHandlerCursesGUI] Make the menu bar clickable

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added reviewers: clayborg, teemperor, labath.
JDevlieghere added a project: LLDB.

Add mouse support to the `IOHandlerCursesGUI` and make it possible to select 
items in the top menu bar by clicking on them. This patch only makes the top 
level items clickable and does not (yet) make it possible to click on items in 
the submenu.

This patch is mostly me being curious about the `IOHandlerCursesGUI` and trying 
to understand how it works.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D82522

Files:
  lldb/source/Core/IOHandlerCursesGUI.cpp


Index: lldb/source/Core/IOHandlerCursesGUI.cpp
===
--- lldb/source/Core/IOHandlerCursesGUI.cpp
+++ lldb/source/Core/IOHandlerCursesGUI.cpp
@@ -830,6 +830,14 @@
 return m_max_submenu_name_length + m_max_submenu_key_name_length + 8;
   }
 
+  int GetTitleDrawWidth() const {
+const int key_width = m_key_name.empty() ? 1 : m_key_name.size();
+return m_name.size() + key_width + 2 /* padding */ + 1 /* space */ +
+   2 /* braces */;
+  }
+
+  int GetSubmenuForPosition(int x, int y);
+
   uint64_t GetIdentifier() const { return m_identifier; }
 
   void SetIdentifier(uint64_t identifier) { m_identifier = identifier; }
@@ -1010,12 +1018,31 @@
   return true; // Drawing handled...
 }
 
+int Menu::GetSubmenuForPosition(int x, int y) {
+  if (y != 0)
+return INT32_MAX;
+
+  int begin = 0;
+  int end = 0;
+  int i = 0;
+  for (const MenuSP &menu : m_submenus) {
+begin = end + 1 /* separator */;
+end = begin + menu->GetTitleDrawWidth();
+if (x >= begin && x < end)
+  return i;
+++i;
+  }
+
+  return INT32_MAX;
+}
+
 HandleCharResult Menu::WindowDelegateHandleChar(Window &window, int key) {
   HandleCharResult result = eKeyNotHandled;
 
   Menus &submenus = GetSubmenus();
   const size_t num_submenus = submenus.size();
   const int selected_idx = GetSelectedSubmenuIndex();
+  MEVENT event;
   Menu::Type menu_type = GetType();
   if (menu_type == Menu::Type::Bar) {
 MenuSP run_menu_sp;
@@ -1052,6 +1079,19 @@
   result = eKeyHandled;
   break;
 
+case KEY_MOUSE:
+  if (getmouse(&event) == OK) {
+if (event.bstate & BUTTON1_PRESSED) {
+  int selected = GetSubmenuForPosition(event.x, event.y);
+  if (selected < static_cast(num_submenus)) {
+m_selected = selected;
+run_menu_sp = submenus[m_selected];
+  }
+  result = eKeyHandled;
+}
+  }
+  break;
+
 default:
   for (size_t i = 0; i < num_submenus; ++i) {
 if (submenus[i]->GetKeyValue() == key) {
@@ -1187,6 +1227,11 @@
 // of seconds seconds when calling
 // Window::GetChar()
 
+// Enable mouse support.
+keypad(stdscr, true);
+mouseinterval(0);
+mousemask(BUTTON1_PRESSED, NULL);
+
 ListenerSP listener_sp(
 Listener::MakeListener("lldb.IOHandler.curses.Application"));
 ConstString broadcaster_class_target(Target::GetStaticBroadcasterClass());


Index: lldb/source/Core/IOHandlerCursesGUI.cpp
===
--- lldb/source/Core/IOHandlerCursesGUI.cpp
+++ lldb/source/Core/IOHandlerCursesGUI.cpp
@@ -830,6 +830,14 @@
 return m_max_submenu_name_length + m_max_submenu_key_name_length + 8;
   }
 
+  int GetTitleDrawWidth() const {
+const int key_width = m_key_name.empty() ? 1 : m_key_name.size();
+return m_name.size() + key_width + 2 /* padding */ + 1 /* space */ +
+   2 /* braces */;
+  }
+
+  int GetSubmenuForPosition(int x, int y);
+
   uint64_t GetIdentifier() const { return m_identifier; }
 
   void SetIdentifier(uint64_t identifier) { m_identifier = identifier; }
@@ -1010,12 +1018,31 @@
   return true; // Drawing handled...
 }
 
+int Menu::GetSubmenuForPosition(int x, int y) {
+  if (y != 0)
+return INT32_MAX;
+
+  int begin = 0;
+  int end = 0;
+  int i = 0;
+  for (const MenuSP &menu : m_submenus) {
+begin = end + 1 /* separator */;
+end = begin + menu->GetTitleDrawWidth();
+if (x >= begin && x < end)
+  return i;
+++i;
+  }
+
+  return INT32_MAX;
+}
+
 HandleCharResult Menu::WindowDelegateHandleChar(Window &window, int key) {
   HandleCharResult result = eKeyNotHandled;
 
   Menus &submenus = GetSubmenus();
   const size_t num_submenus = submenus.size();
   const int selected_idx = GetSelectedSubmenuIndex();
+  MEVENT event;
   Menu::Type menu_type = GetType();
   if (menu_type == Menu::Type::Bar) {
 MenuSP run_menu_sp;
@@ -1052,6 +1079,19 @@
   result = eKeyHandled;
   break;
 
+case KEY_MOUSE:
+  if (getmouse(&event) == OK) {
+if (event.bstate & BUTTON1_PRESSED) {
+  int selected = GetSubmenuForPosition(event.x, event.y);
+  if (selected < static_cast(num_submenus)) {
+m_selected = selected;
+   

[Lldb-commits] [PATCH] D82378: [lldb/Unwind] Use eh_frame plan directly when it doesn't need to be augmented

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

Hi Pavel, sorry I've been doing a bunch of random things today and haven't 
really had a chance to look at this yet. eh_frame is so problematic for lldb, 
we never know what we're getting.  I keep thinking we should take over a few 
augmentation string characters so that the producer can definitively indicate 
one of:

Synchronous unwind only - at throwable locations, or when unwinding up the 
stack for a throw.

Fully describes prologue setup.

Fully describes epilogue(s) teardown.

Fully asynchronous - unwind information is correct at all instructions.

When we set up a stack frame (and base things off of the frame pointer), that 
can cover up a multitude of eh_frame issues as long as we get the 
prologue/epilogue.  All the bugs tend to come out when we start using 
-fomit-frame-pointer, or look at leaf frames. ;)  I don't know if gcc still 
does this, but I remember ages ago if you had i386 32-bit PIC code and needed 
to refer to pc-relative data it would do a CALLQ next-instruction and then pop 
the saved pc off the stack, without any unwind information at that point.  
Maybe it does that now.

With x86_64, I know gcc emits prologue & epilogue, and clang probably does too 
now (we rarely use eh_frame on macOS systems so it's been a while since I've 
seen it). I don't know what icc does.  Given how rarely people bother with 
omit-frame-pointer codegen on x86_64 (it was more important on 32-bit i386), 
and prologue+epilogue were often present, I was fine with living on eh_frame as 
the primary unwind mechanism.  It still makes me nervous in general, though.

(having augmentation strings would also allow us to remove a special-case in 
macOS support -- we have a couple of solibs with hand-written assembly and 
hand-written eh_frame for it, and we special case those libraries to say "trust 
the eh_frame from this one, it's cool".)

I've never pushed hard for the idea of adding augmentation strings from the 
producers because it seemed easier to depend primarily on the instruction 
analysis methods.  But maybe it is something we should pursue.

None of this really comments specifically on the proposed patch, just talking 
out loud about my feelings on all of this.  One thing you mentioned is that the 
x86 instruction analysis doesn't handle multiple epilogues -- it should do 
that?  I fixed a bug in it three weeks ago where it didn't understand an 
epilogue-ending tail-call JMPQ as the final instruction in the epilogue (to a 
noreturn function).  UnwindAssemblyInstEmulation takes a much better approach 
where it forwards the unwind state to branches in the function and doesn't 
bother trying to recognize the instructions in an epilogue; that's definitely 
superior and what the x86 unwinder should do (or just fold it into the 
InstEmulation system).  But in general, multiple epilogues should be handled I 
believe..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82378



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

[Lldb-commits] [lldb] 895529c - [lldb][PDB] Constexpr static member values as AST literals

[Aleksandr Urakov via lldb-commits]

Author: Aleksandr Urakov
Date: 2020-06-25T11:27:16+03:00
New Revision: 895529cfd8756e2b4dc609f5af92e0d8ae280ed8

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

LOG: [lldb][PDB] Constexpr static member values as AST literals

Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.

Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.

This change applies to DIA and native PDB loaders.

Patch By: jackoalan

Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor

Reviewed By: aleksandr.urakov

Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb

Tags: #lldb, #llvm

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

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
lldb/test/Shell/SymbolFile/PDB/Inputs/AstRestoreTest.cpp
lldb/test/Shell/SymbolFile/PDB/ast-restore.test
llvm/include/llvm/DebugInfo/PDB/PDBTypes.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
index b88f87527d8c..0acc77d7c67f 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
@@ -681,7 +681,7 @@ bool PdbAstBuilder::CompleteTagDecl(clang::TagDecl &tag) {
   // Visit all members of this class, then perform any finalization necessary
   // to complete the class.
   CompilerType ct = ToCompilerType(tag_qt);
-  UdtRecordCompleter completer(best_ti, ct, tag, *this, m_index.tpi());
+  UdtRecordCompleter completer(best_ti, ct, tag, *this, m_index);
   auto error =
   llvm::codeview::visitMemberRecordStream(field_list_cvt.data(), 
completer);
   completer.complete();

diff  --git a/lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
index 308ba9e3dec0..c8fb46c75034 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
@@ -6,14 +6,17 @@
 #include "PdbUtil.h"
 
 #include "Plugins/ExpressionParser/Clang/ClangASTImporter.h"
+#include "Plugins/ExpressionParser/Clang/ClangUtil.h"
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
 #include "lldb/Symbol/Type.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/lldb-enumerations.h"
 #include "lldb/lldb-forward.h"
 
+#include "llvm/DebugInfo/CodeView/SymbolDeserializer.h"
 #include "llvm/DebugInfo/CodeView/TypeDeserializer.h"
 #include "llvm/DebugInfo/CodeView/TypeIndex.h"
+#include "llvm/DebugInfo/PDB/Native/GlobalsStream.h"
 #include "llvm/DebugInfo/PDB/Native/TpiStream.h"
 #include "llvm/DebugInfo/PDB/PDBTypes.h"
 
@@ -29,10 +32,10 @@ UdtRecordCompleter::UdtRecordCompleter(PdbTypeSymId id,
CompilerType &derived_ct,
clang::TagDecl &tag_decl,
PdbAstBuilder &ast_builder,
-   TpiStream &tpi)
+   PdbIndex &index)
 : m_id(id), m_derived_ct(derived_ct), m_tag_decl(tag_decl),
-  m_ast_builder(ast_builder), m_tpi(tpi) {
-  CVType cvt = m_tpi.getType(m_id.index);
+  m_ast_builder(ast_builder), m_index(index) {
+  CVType cvt = m_index.tpi().getType(m_id.index);
   switch (cvt.kind()) {
   case LF_ENUM:
 llvm::cantFail(TypeDeserializer::deserializeAs(cvt, m_cvr.er));
@@ -55,7 +58,7 @@ clang::QualType UdtRecordCompleter::AddBaseClassForTypeIndex(
   PdbTypeSymId type_id(ti);
   clang::QualType qt = m_ast_builder.GetOrCreateType(type_id);
 
-  CVType udt_cvt = m_tpi.getType(ti);
+  CVType udt_cvt = m_index.tpi().getType(ti);
 
   std::unique_ptr base_spec =
   m_ast_builder.clang().CreateBaseClassSpecifier(
@@ -128,9 +131,70 @@ Error UdtRecordCompleter::visitKnownMember(
 
   lldb::AccessType access =
   TranslateMemberAccess(static_data_member.getAccess());
-  TypeSystemClang::AddVariableToRecordType(
+  auto decl = TypeSystemClang::AddVariableToRecordType(
   m_derived_ct, static_data_member.Name, member_ct, access);
 
+  // Static const

[Lldb-commits] [PATCH] D82412: [lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObject

[Pavel Labath via Phabricator via lldb-commits]

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



Comment at: 
lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp:77
+  io_redirect_or_error =
+  options.GetEnableIO()
+  ? ScriptInterpreterIORedirect::Create(m_debugger, result)

I wonder if we should just pass `options.GetEnableIO()` to the factory 
function, and let it figure out the details...


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

https://reviews.llvm.org/D82412



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

[Lldb-commits] [PATCH] D82160: [lldb][PDB] Constexpr static member values as AST literals

[Aleksandr Urakov via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG895529cfd875: [lldb][PDB] Constexpr static member values as 
AST literals (authored by aleksandr.urakov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82160

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/UdtRecordCompleter.h
  lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
  lldb/test/Shell/SymbolFile/PDB/Inputs/AstRestoreTest.cpp
  lldb/test/Shell/SymbolFile/PDB/ast-restore.test
  llvm/include/llvm/DebugInfo/PDB/PDBTypes.h

Index: llvm/include/llvm/DebugInfo/PDB/PDBTypes.h
===
--- llvm/include/llvm/DebugInfo/PDB/PDBTypes.h
+++ llvm/include/llvm/DebugInfo/PDB/PDBTypes.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_DEBUGINFO_PDB_PDBTYPES_H
 #define LLVM_DEBUGINFO_PDB_PDBTYPES_H
 
+#include "llvm/ADT/APFloat.h"
 #include "llvm/DebugInfo/CodeView/CodeView.h"
 #include "llvm/DebugInfo/PDB/IPDBEnumChildren.h"
 #include "llvm/DebugInfo/PDB/IPDBFrameData.h"
@@ -464,6 +465,88 @@
 char *String;
   } Value;
 
+  bool isIntegralType() const {
+switch (Type) {
+case Bool:
+case Int8:
+case Int16:
+case Int32:
+case Int64:
+case UInt8:
+case UInt16:
+case UInt32:
+case UInt64:
+  return true;
+default:
+  return false;
+}
+  }
+
+#define VARIANT_WIDTH(Enum, NumBits)   \
+  case PDB_VariantType::Enum:  \
+return NumBits;
+
+  unsigned getBitWidth() const {
+switch (Type) {
+  VARIANT_WIDTH(Bool, 1u)
+  VARIANT_WIDTH(Int8, 8u)
+  VARIANT_WIDTH(Int16, 16u)
+  VARIANT_WIDTH(Int32, 32u)
+  VARIANT_WIDTH(Int64, 64u)
+  VARIANT_WIDTH(Single, 32u)
+  VARIANT_WIDTH(Double, 64u)
+  VARIANT_WIDTH(UInt8, 8u)
+  VARIANT_WIDTH(UInt16, 16u)
+  VARIANT_WIDTH(UInt32, 32u)
+  VARIANT_WIDTH(UInt64, 64u)
+default:
+  assert(false && "Variant::toAPSInt called on non-numeric type");
+  return 0u;
+}
+  }
+
+#undef VARIANT_WIDTH
+
+#define VARIANT_APSINT(Enum, NumBits, IsUnsigned)  \
+  case PDB_VariantType::Enum:  \
+return APSInt(APInt(NumBits, Value.Enum), IsUnsigned);
+
+  APSInt toAPSInt() const {
+switch (Type) {
+  VARIANT_APSINT(Bool, 1u, true)
+  VARIANT_APSINT(Int8, 8u, false)
+  VARIANT_APSINT(Int16, 16u, false)
+  VARIANT_APSINT(Int32, 32u, false)
+  VARIANT_APSINT(Int64, 64u, false)
+  VARIANT_APSINT(UInt8, 8u, true)
+  VARIANT_APSINT(UInt16, 16u, true)
+  VARIANT_APSINT(UInt32, 32u, true)
+  VARIANT_APSINT(UInt64, 64u, true)
+default:
+  assert(false && "Variant::toAPSInt called on non-integral type");
+  return APSInt();
+}
+  }
+
+#undef VARIANT_APSINT
+
+  APFloat toAPFloat() const {
+// Float constants may be tagged as integers.
+switch (Type) {
+case PDB_VariantType::Single:
+case PDB_VariantType::UInt32:
+case PDB_VariantType::Int32:
+  return APFloat(Value.Single);
+case PDB_VariantType::Double:
+case PDB_VariantType::UInt64:
+case PDB_VariantType::Int64:
+  return APFloat(Value.Double);
+default:
+  assert(false && "Variant::toAPFloat called on non-floating-point type");
+  return APFloat::getZero(APFloat::IEEEsingle());
+}
+  }
+
 #define VARIANT_EQUAL_CASE(Enum)   \
   case PDB_VariantType::Enum:  \
 return Value.Enum == Other.Value.Enum;
Index: lldb/test/Shell/SymbolFile/PDB/ast-restore.test
===
--- lldb/test/Shell/SymbolFile/PDB/ast-restore.test
+++ lldb/test/Shell/SymbolFile/PDB/ast-restore.test
@@ -4,7 +4,8 @@
 RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=ENUM %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=GLOBAL %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=BASE %s
-RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=CLASS %s
+RUN: env LLDB_USE_NATIVE_PDB_READER=0 lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=CLASS %s
+RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=CLASS %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=INNER %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=TEMPLATE %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=FOO %

[Lldb-commits] [PATCH] D82396: [lldb/ScriptInterpreter] Extract IO redirection logic and move it out of ScriptInterpreterPython (NFC)

[Pavel Labath via Phabricator via lldb-commits]

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

I think this looks good, though it looks like you have uploaded an partial 
patch...




Comment at: lldb/include/lldb/Interpreter/ScriptInterpreter.h:57-58
 private:
+  friend std::unique_ptr
+  std::make_unique();
+

If that works, I suppose it's fine. But I wouldn't be surprised if this trick 
backfires on some STL implementations.

I think that making an exception for make_unique on classes with private 
constructors is fine (we already have a bunch of classes like that)...



Comment at: lldb/source/Interpreter/ScriptInterpreter.cpp:128-168
   if (result) {
-m_input_file_sp = debugger.GetInputFileSP();
+redirect->m_input_file_sp = debugger.GetInputFileSP();
 
 Pipe pipe;
 Status pipe_result = pipe.CreateNew(false);
 #if defined(_WIN32)
 lldb::file_t read_file = pipe.GetReadNativeHandle();

Given that none of this fails (though maybe it should), I think it would be 
cleaner to keep it in the constructor. You can still keep the static factory 
thing as a wrapper if you want symmetry.



Comment at: lldb/source/Interpreter/ScriptInterpreter.cpp:184-190
+  std::unique_ptr redirect =
+  std::make_unique();
+  redirect->m_input_file_sp = std::move(nullin.get());
+  redirect->m_error_file_sp = redirect->m_output_file_sp =
   std::make_shared(std::move(nullout.get()));
+
+  return redirect;

Similarly, I would find this better as `return 
std::make_unique(std::move(nullin.get()), 
std::move(nullout.get()))` (with an appropriate constructor. Mainly because 
then I don't need to worry about what will the destructor of 
ScriptInterpreterIORedirect do if we return with the object in an partially 
initialized state.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D82396



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

[Lldb-commits] [PATCH] D82477: [lldb-vscode] Add Support for Module Event

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py:27-29
+self.assertTrue('a.out' in self.vscode.get_active_modules(), 
+'Module: a.out is loaded')
+self.assertTrue('symbolFilePath' in 
self.vscode.get_active_modules()['a.out'],

replace `assertTrue(needle in haystack)` with `assertIn(needle, haystack)`



Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:336
+  object.try_emplace("name", std::string(module.GetFileSpec().GetFilename())); 
// Path in remote
+  std::string module_path = std::string(module.GetFileSpec().GetDirectory()) + 
"/" + std::string(module.GetFileSpec().GetFilename());
+  object.try_emplace("path", module_path);

You should use `SBFileSpec::GetPath` to get the file and dir components 
separated by the correct directory separator. (It's usage is somewhat clunky 
due to the SB API restrictions).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82477



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

[Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

The code looks fine to me, though it sounds like there are still issues to be 
sorted out w.r.t commands run from inside data formatters, through sb apis, 
etc. And it needs tests, of course.




Comment at: lldb/source/Commands/CommandObjectSession.h:22-26
+  ~CommandObjectSession() override;
+
+private:
+  CommandObjectSession(const CommandObjectSession &) = delete;
+  const CommandObjectSession &operator=(const CommandObjectSession &) = delete;

You don't have to do this, but personally I'd delete all of this stuff -- the 
copy operations are implicitly deleted due to them being deleted in the base 
class, and the destructor will be implicitly overridden anyway.



Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2945
+  auto string_stream =
+  std::static_pointer_cast(m_session_transcripts);
+  size_t stream_size = string_stream->GetSize();

labath wrote:
> Why not make `m_session_transcripts` a `shared_ptr` (or even a 
> plain `StreamString`) in the first place?
Much better, though a plain `StreamString` would be even nicer (and AFAICT 
there is nothing preventing that).



Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2928
+  if (!opened_file)
+return error_out("Unable to create file");
+

It would be nice if this error message actually contained the reason why the 
open operation failed (similar to what we did with the core file patch a while 
back).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82155



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

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

In D81001#2107102 , @gedatsu217 wrote:

> Change the name and return of the function( bool UseAutosuggestion() -> void 
> SetShowAutosuggestion (bool) ) (ll. 1447 in Editline.cpp and ll.194 in 
> Editline.h).
>  int -> size_t (ll. 1009 in Editline.cpp).
>  Fix for normal setter (ll. 269 in IOHandler.cpp).
>
> > The Editline instance isn't recreated when you change the settings, so you 
> > need to restart LLDB for this to work. However, settings aren't 
> > automatically saved, so I think the right way to do this by putting the 
> > settings set show-autosuggestion true into the ~/.lldbinit file (which will 
> > be automatically executed before LLDB's command line frontend starts). It 
> > probably requires a bunch of work to get that working without a restart, so 
> > I think this can be fixed as a follow-up.
>
> There is no ~/.lldbinit in my environment (I do not why). Instead, there is 
> ~/.lldb directory (but there are just command history file there.).


You need to create that file :) It's just a text file with LLDB commands in 
each line (and you just put the settings command in there to change the setting 
before LLDB starts). Doing `lldb -o "settings set show-autosuggestion true"` 
should also work.

>> On a more general note: I'm not sure why we need m_current_autosuggestion. 
>> There is a bunch of code that tries to keep that variable up-to-date with 
>> what is typed, but unless I'm missing something this is just the text the 
>> user has entered so far? If yes, then you can also just get the current user 
>> input from Editline (see the first few lines of the Editline::TabCommand 
>> function for how to do that).
> 
> I think "m_current_autosuggestion" is needed. That is because it keeps the 
> characters for the suggestion, not just user input. For example, when "b" is 
> typed, "reakpoint" is saved in m_current_autosuggestion (when "breakpoint" is 
> typed before).
> 
> When a character is typed, Editline::TypedCharacter is called and 
> m_current_autosuggestion is renewed every time. On the other hand, 
> Editline::ApplyCompleteCommand, which execute suggestion actually, is not 
> called unless C^f is typed. Therefore I think the suggestion parts should be 
> saved until it is called. Indeed, I can get current user input by the first 
> few lines of the Editline::TabCommand function, but it cannot save the 
> suggestion parts probably.
> 
> However, I noticed that "to_add" in Editline::TypedCharacter is unnecessary, 
> so removeed it.

My worry is that if we rely on always keeping this variable up-to-date during 
the life-time of Editline that this might lead to weird bugs due to the 
variable getting out-of-sync (e.g., someone changes some input logic but 
forgets to update the autosuggestion code). I tried moving some parts in this 
patch around in this commit 

 and it does seem to work in the same way as this patch, but without the need 
to keep m_current_autosuggestion up-to-date. What do you think?




Comment at: lldb/source/Host/common/Editline.cpp:1451
+  else
+m_use_autosuggestion = false;
+}

This can all be `m_use_autosuggestion = autosuggestion;`.



Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:1875-1878
+if (entry.startswith(line)) {
+  llvm::StringRef res = entry.substr(line.size());
+  result = res.str();
+  return result;

gedatsu217 wrote:
> labath wrote:
> > ```
> > if (entry.consume_front(line)) {
> >   result = entry.str();
> >   return result; // Why is this returning the result both as a proper 
> > return value and a by-ref argument?
> > }
> > ```
> That is because using the llvm::Optional as a return value instead of void 
> would make it more obvious what the function returns in case there is no 
> suggestion.
> 
> We've discussed this issue before, so please see the comments above.
Pavel's point is that the function is returning >both<. You can just remove the 
`result` parameter and do `result = ... GetAutoSuggestionForCommand(line);` 
when you call it is his point.


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

https://reviews.llvm.org/D81001



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

[Lldb-commits] [PATCH] D82522: [lldb/IOHandlerCursesGUI] Make the menu bar clickable

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Being curious is nice, but it would be even nicer if we figured out a way to 
test all of this stuff. Currently we have some very basic pexpect tests for 
this, but it's not clear how that will scale to more complex interactions (such 
as mouse clicking).

My idea for a test strategy (which is looking for someone to implement it) is 
to write (or resuse an existing -- pyte 
 looks interesting) a simple 
"terminal emulator" in python. The idea is that this would process the raw 
escape sequences and produce an in-memory view of what the resulting screen 
should look like. Then we just connect the pexpect output to this terminal 
emulator.

This would allow us to write assertions based on that the virtual terminal 
view, so that we check *what* actually gets printed on the screen, and ignore 
the exact details about *how* it gets printed. (e.g. `self.assertIn("Process 
(F3)", screen[0])`...

(All this assumes that we're able to inject mouse clicks via pexpect, which I 
haven't checked whether it's possible, but I presume pexpect is low-level 
enough to be able to do something like that.)


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D82522



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

[Lldb-commits] [PATCH] D82537: [lldb] Deduplicate copy-pasted TypeSystemMap::GetTypeSystemForLanguage

[Raphael Isemann via Phabricator via lldb-commits]

teemperor created this revision.
teemperor added a reviewer: LLDB.
Herald added a subscriber: JDevlieghere.

There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage` 
which are both
identical beside one taking a `Module` and one taking a `Target` (and then 
passing that argument
to the `TypeSystem::CreateInstance` function).

This merges both implementations into one function with a lambda that wraps the 
different calls
to `TypeSystem::CreateInstance`.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D82537

Files:
  lldb/include/lldb/Symbol/TypeSystem.h
  lldb/source/Symbol/TypeSystem.cpp

Index: lldb/source/Symbol/TypeSystem.cpp
===
--- lldb/source/Symbol/TypeSystem.cpp
+++ lldb/source/Symbol/TypeSystem.cpp
@@ -224,9 +224,9 @@
   }
 }
 
-llvm::Expected
-TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType language,
-Module *module, bool can_create) {
+llvm::Expected TypeSystemMap::GetTypeSystemForLanguage(
+lldb::LanguageType language,
+llvm::Optional create_callback) {
   llvm::Error error = llvm::Error::success();
   assert(!error); // Check the success value when assertions are enabled
   std::lock_guard guard(m_mutex);
@@ -268,7 +268,7 @@
   }
 }
 
-if (!can_create) {
+if (!create_callback) {
   error = llvm::make_error(
   "Unable to find type system for language " +
   llvm::StringRef(Language::GetNameForLanguageType(language)),
@@ -276,7 +276,7 @@
 } else {
   // Cache even if we get a shared pointer that contains a null type system
   // back
-  auto type_system_sp = TypeSystem::CreateInstance(language, module);
+  TypeSystemSP type_system_sp = (*create_callback)();
   m_map[language] = type_system_sp;
   if (type_system_sp.get()) {
 llvm::consumeError(std::move(error));
@@ -295,69 +295,24 @@
 
 llvm::Expected
 TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType language,
-Target *target, bool can_create) {
-  llvm::Error error = llvm::Error::success();
-  assert(!error); // Check the success value when assertions are enabled
-  std::lock_guard guard(m_mutex);
-  if (m_clear_in_progress) {
-error = llvm::make_error(
-"Unable to get TypeSystem because TypeSystemMap is being cleared",
-llvm::inconvertibleErrorCode());
-  } else {
-collection::iterator pos = m_map.find(language);
-if (pos != m_map.end()) {
-  auto *type_system = pos->second.get();
-  if (type_system) {
-llvm::consumeError(std::move(error));
-return *type_system;
-  }
-  error = llvm::make_error(
-  "TypeSystem for language " +
-  llvm::StringRef(Language::GetNameForLanguageType(language)) +
-  " doesn't exist",
-  llvm::inconvertibleErrorCode());
-  return std::move(error);
-}
-
-for (const auto &pair : m_map) {
-  if (pair.second && pair.second->SupportsLanguage(language)) {
-// Add a new mapping for "language" to point to an already existing
-// TypeSystem that supports this language
-m_map[language] = pair.second;
-if (pair.second.get()) {
-  llvm::consumeError(std::move(error));
-  return *pair.second.get();
-}
-error = llvm::make_error(
-"TypeSystem for language " +
-llvm::StringRef(Language::GetNameForLanguageType(language)) +
-" doesn't exist",
-llvm::inconvertibleErrorCode());
-return std::move(error);
-  }
-}
-
-if (!can_create) {
-  error = llvm::make_error(
-  "Unable to find type system for language " +
-  llvm::StringRef(Language::GetNameForLanguageType(language)),
-  llvm::inconvertibleErrorCode());
-} else {
-  // Cache even if we get a shared pointer that contains a null type system
-  // back
-  auto type_system_sp = TypeSystem::CreateInstance(language, target);
-  m_map[language] = type_system_sp;
-  if (type_system_sp.get()) {
-llvm::consumeError(std::move(error));
-return *type_system_sp.get();
-  }
-  error = llvm::make_error(
-  "TypeSystem for language " +
-  llvm::StringRef(Language::GetNameForLanguageType(language)) +
-  " doesn't exist",
-  llvm::inconvertibleErrorCode());
-}
+Module *module, bool can_create) {
+  if (can_create) {
+return GetTypeSystemForLanguage(
+language, llvm::Optional([language, module]() {
+  return TypeSystem::CreateInstance(language, module);
+}));
   }
+  return GetTypeSystemForLanguage(language);
+}
 
-  return std::move(error);
+llvm::Expected
+TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType language,
+Target *target, bool can_cr

[Lldb-commits] [PATCH] D82378: [lldb/Unwind] Use eh_frame plan directly when it doesn't need to be augmented

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Thanks for replying Jason.

I think having the augmentation string specify its validity would be great, 
though I am somewhat sceptical of being able to push that idea through -- given 
that eh_frame needs to be understood by a lot of consumers and is actually 
critical for the correctness of some applications (those using exceptions), 
making changes to it seems to be hard -- that's why it's still stuck at version 
1 of debug_frame.

That said, given that current compilers do emit prologue/epilogue unwind info 
correctly, I'm not sure that we need the epilogue augmentation code, without 
additional header information. Given all of this discussion I'll try to find 
some time to do a detailed investigation of the prologue/epilogue state in 
various compiler versions (similar to the DW_AT_low_pc analysis in D78489 
), and see what comes out of it.

You're right that the instruction emulation not handling multiple epilogues is 
a bug. It's probably not about _all_ epilogues, only some special ones -- for 
example, the function where we ran into this was so simple it did not have any 
traditional prologue instructions and I suspect this is what threw the code off.

I was planning to look into that separately. My flow of thought which led to 
starting off with this patch was:

- I knew that instruction emulation is broken, but the very first plan we try 
is the "eh_frame augmented" plan.
- It seemed like the augmenter should also be able to handle this function (and 
it's job should be even easier). So I tried to find why that doesn't kick in.
- While stepping through the code, I found this comment 
(UnwindAssembly-x86.cpp:127), which seems to imply that we don't need to 
augment it at all. It stop short of expliticly saying that we should actually 
use that plan, but that's seems implied to me. (it also makes sense -- the 
augmenter is there to add the epilogue instructions, and we already have them, 
so there's nothing to add..)
- So, I figured I'd first fix it so that it actually does what it says it does.

From your comment, it's not clear to me whether you are ok with this patch, or 
if you want to do something differently.

BTW, the call-next-instruction trick is still used, but not by any gcc version 
available on godbolt.org -- clang uses this sequence on i386 PIC. However, 
since clang-3.8, the cfi instruction properly describe how to unwind out of 
that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82378



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

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:1875-1878
+if (entry.startswith(line)) {
+  llvm::StringRef res = entry.substr(line.size());
+  result = res.str();
+  return result;

teemperor wrote:
> gedatsu217 wrote:
> > labath wrote:
> > > ```
> > > if (entry.consume_front(line)) {
> > >   result = entry.str();
> > >   return result; // Why is this returning the result both as a proper 
> > > return value and a by-ref argument?
> > > }
> > > ```
> > That is because using the llvm::Optional as a return value instead of void 
> > would make it more obvious what the function returns in case there is no 
> > suggestion.
> > 
> > We've discussed this issue before, so please see the comments above.
> Pavel's point is that the function is returning >both<. You can just remove 
> the `result` parameter and do `result = ... 
> GetAutoSuggestionForCommand(line);` when you call it is his point.
Yes that was one of my points. Thank you, Raphael.

My other point was that using `consume_front` is better than a 
`startswith`+`substr` combo.


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

https://reviews.llvm.org/D81001



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

[Lldb-commits] [PATCH] D82064: [ARM64] Add QEMU testing environment setup guide for SVE testing

[Diana Picus via Phabricator via lldb-commits]

rovka added a comment.

Hi Omair,

If this is intended to be more generally useful, I wonder if we should rename 
it to something else (e.g. lldb-qemu-howto.txt) and only use AArch64 SVE as a 
case study.

In any case, thanks for writing this up!




Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:5
+
+QEMU can be used to test LLDB in emulation environment in absence of actual
+hardware. This write up will help setup an QEMU environment for testing LLDB

Nitpick: "in **an** emulation environment in **the** absence of actual [...]



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:7
+hardware. This write up will help setup an QEMU environment for testing LLDB
+patches supporting AArch64 features like SVE, MTE, Pointer Authentication etc.
+

Isn't this guide still useful after the patches are merged?



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:9
+
+Ubuntu Bionic/Focal x86_64 host machine was used to test all instruction in 
this
+document. Please update it according to your host distribution/architecture.

Typo: all the instructions



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:19
+
+#!/bin/bash
+

Would it be better for this to be an actual script in lldb/utils or somewhere 
similar?



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:78
+#
+# Build QEMU from source for AArch64 system-mode emulation
+

Is this difficult to infer from QEMU's own docs? If not, maybe just add a link 
and mention only what's specific to this guide (I'm guessing the target-list).



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:96
+#
+# Cross compile Linux kernel
+

Same as above, could this be just a link to the official docs?



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:124
+
+#!/bin/bash
+

Same as step 1: can this live in utils?



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:176
+# Your default username will be the one with whom you created RootFS image.
+# Internet access inside your emulation environment run: sudo dhclient enp0s2.
+

Nitpick: **For** Internet access [...]



Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:217
+
+# Cross compile LLDB server for AArch64 Linux
+# Transfer LLDB server executable to emulation environment

For consistency, maybe there should be some commands here, or a link to the 
docs for cross-compiling.


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

https://reviews.llvm.org/D82064



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

Re: [Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Pavel Labath via lldb-commits]

On 24/06/2020 18:55, Jim Ingham wrote:
> 
>> On Jun 22, 2020, at 5:52 AM, Pavel Labath via Phabricator via lldb-commits 
>>  wrote:
>>
>> labath added a comment.
>>
>> This seems like it could be useful in some circumstances, though for the use 
>> cases I am imagining (bug reporting) it would be easier to just copy-paste 
>> the terminal contents.
>>
>> As for the implementation, if the intention is for this to eventually 
>> capture all debugger output, then I am not sure if this is the right design. 
>> I think it would be fine for python/lua interpreters as those are invoked 
>> from the lldb command interpreter, but I have a feeling that routing the 
>> output printed via `Debugger::PrintAsync` back to the command interpreter 
>> would look pretty weird. It may make sense for the core logic of this to 
>> live in the Debugger or the IOHandler(Stack) classes -- though I am not 
>> exactly sure about that either as the Debugger and CommandIntepreter classes 
>> are fairly tightly coupled. However, I think that would be consistent with 
>> the long term goal of reimplementing the command interpreter on top of the 
>> SB API (in which case the `Debugger` object should not know anything about 
>> the command interpreter (but it would still need to to "something" with the 
>> PrintAsync output).
> This isn’t directly related to how much and how we should capture lldb 
> session output, and maybe I’m misunderstanding your meaning, but I wasn’t 
> expecting that moving the command interpreter to use SB API’s would mean the 
> Debugger Object would know nothing about the Command interpreter.  It would 
> know as much about the command interpreter as it does about the script 
> interpreter, namely the Debugger holds these objects and is the one to hand 
> them out.  For instance when the breakpoint has a bunch of commands in its 
> command action, it would go to the debugger to evaluate those commands.  I 
> think that’s the reasonable place from which to vend the command and script 
> interpreters.  So it’s okay IMO for the Debugger to know a little bit about 
> these entities.  It shouldn’t know anything about the command syntax, etc.  
> But since it is still the vendor of these objects, it seems okay for it to 
> have an affordance to be notified of command results.
> 

Well, the way I was thinking about this the "Debugger" would not know
anything about Command *or* script interpreters. It would just know how
to "debug" -- offer a programming API without any sort of textual
interaction with a human.

However, this may be just a naming issue. There obviously needs to be
some object which ties all of these together the thing which "debugs"
and the thing which interfaces this with the user -- and it's not
unreasonable to call this thing "the Debugger".

Nevertheless I think having this separation between "core debugger
functionality" and a "particular way of interacting with the user" can
be very useful:
- it can enable someone to write a fully gdb-compatible (or some other
debugger emulation) CLI experience on top of the "debugger core". This
CLI would not need anything from the lldb CLI, but it could make use of
all the "core" functionality (targets, breakpoints, threads, etc.)
- someone wanting to build a lean-and-mean debugger for some specialized
task could just make use of the "core" debugger functionality without
pulling in the entire CLI

I don't expect either of these things to happen in the near future (or
at all), but I like that this design would enable that sort of thing.
Additionally (and this is the reason why I said (lldb_private::)Debugger
in my first comment) this organization would avoid some problematic
circular dependencies: If lldb_private::Debugger knows about the
"command interpreter" and the "command interpreter" uses the SB api,
then which side of the SB boundary does the command interpreter lie? It
can't be "inside" the API, because it needs to access it to drive the
debugging. But it also cannot be "outside" of the SB API, because then
lldb_private::Debugger could not know about it.

That's why I figured that lldb::SBDebugger could be the "one debugger to
rule them all", and lldb_private::Debugger could be "demoted" to just
the "core" debugging facilities.

But now we're getting way ahead of ourselves...

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

Re: [Lldb-commits] [lldb] d4ef569 - Disable a flaky lldb-vscode test on aarch64

[Pavel Labath via lldb-commits]

These tests are also flaky on GreenDragon:
(http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/21850/testReport/,
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/21848/testReport/,
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/21847/testReport/).

So, it sounds like this is a general problem and not limited to aarch64
linux (actually, the fact that they are not flaky on x86 may be more
interesting), and so disabling the tests does not seem like the right
solution.

On 24/06/2020 20:09, Walter Erquinigo via lldb-commits wrote:
> 
> Author: Walter Erquinigo
> Date: 2020-06-24T11:09:21-07:00
> New Revision: d4ef569577625d50dfe01ab54c7b9995db3e013f
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/d4ef569577625d50dfe01ab54c7b9995db3e013f
> DIFF: 
> https://github.com/llvm/llvm-project/commit/d4ef569577625d50dfe01ab54c7b9995db3e013f.diff
> 
> LOG: Disable a flaky lldb-vscode test on aarch64
> 
> Summary:
> These tests isflaky only on this arch for some reason. It's testing important 
> features and is not flaky on x86_64, so I'll investigate this arm issue 
> separatedly.
> 
> A flaky run:
> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio
> 
> Diff that created those tests:
> https://reviews.llvm.org/D81978
> 
> Added: 
> 
> 
> Modified: 
> lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py 
> b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
> index c9d99daf9bc6..fb7d71872a16 100644
> --- a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
> +++ b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
> @@ -430,6 +430,8 @@ def test_extra_launch_commands(self):
>  
>  @skipIfWindows
>  @skipIfNetBSD # Hangs on NetBSD as well
> +@skipIfDarwin
> +@skipIf(archs="aarch64") # Example of a flaky run 
> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio
>  def test_terminate_commands(self):
>  '''
>  Tests that the "terminateCommands", that can be passed during
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 

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

[Lldb-commits] [PATCH] D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

kwk marked an inline comment as done.
kwk added inline comments.



Comment at: 
lldb/test/API/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py:124
-file_list.Append(lldb.SBFileSpec("noFileOfThisName.xxx"))
-wrong.append(target.BreakpointCreateFromScript("resolver.Resolver", 
extra_args, module_list, file_list))
-

@jingham can you please let me know if this test serves any purpose with my 
patch? I mentioned in my last change log 
(https://reviews.llvm.org/D74136#2113899) that it calls `AddressPasses` and 
checked for the CU before. But since we're no longer doing this, this test no 
longer can pass. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74136



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

[Lldb-commits] [PATCH] D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

kwk updated this revision to Diff 273307.
kwk added a comment.

- bring back logic to keep a symbol context when a function passes and add a 
comment as Jan suggested
- remove test from scripted resolver that calls 
SearchFilterByModulesAndSupportFiles::AddressPasses
  - before the test checked that a non existing file doesn't cause setting a 
breakpoint location
  - the logic in AddressPasses before was to identify the CU of a symbol 
context and check if it's file is in the list of files that are allowed to 
pass. We agreed to change this logic so that not only CU's are checked but also 
files in which a function is declared. 
SearchFilterByModulesAndSupportFiles::FunctionPasses now does exactly that but 
it is not called from the BreakPointResolverScripted class, only from 
BreakpointResolverName.
  - It is an open question how to deal with this and I hope Jim can help here.
  - Shall we maybe take another file from the SymbolContext to see if we can 
filter by that in AddressPasses? Here's a dump of the filter context for the 
removed test:

  0x7ffda14d94a0: SymbolContext
  Module   = 0x563169c60780 
/opt/notnfs/kkleine/llvm/build/lldb-test-build.noindex/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.test_scripted_resolver/a.out
  CompileUnit  = 0x56316a04c310 {} 
/opt/notnfs/kkleine/llvm/lldb/test/API/functionalities/breakpoint/scripted_bkpt/main.c
  Function = 0x56316a048c40 {7fff0043} break_on_me, 
address-range = a.out[0x00401150-0x00401167)
  Type = 0x56316a0220d0: Type{0x7fff0043} , name = 
"break_on_me", decl = main.c:10, compiler_type = 0x56316a0cbe80 void (void)
  
  Block= 0x56316a048c78 {7fff0043}
  LineEntry= a.out[0x00401150-0x00401154), file = 
/opt/notnfs/kkleine/llvm/lldb/test/API/functionalities/breakpoint/scripted_bkpt/main.c,
 line = 11, is_start_of_statement = TRUE
  Symbol   = 0x56316a037248
  Variable = 0x



- rename var


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74136

Files:
  lldb/include/lldb/Core/SearchFilter.h
  lldb/include/lldb/Target/Target.h
  lldb/source/Breakpoint/BreakpointResolverName.cpp
  lldb/source/Core/SearchFilter.cpp
  lldb/source/Target/Target.cpp
  lldb/test/API/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
  lldb/test/Shell/Breakpoint/Inputs/search-support-files-func.cpp
  lldb/test/Shell/Breakpoint/Inputs/search-support-files.cpp
  lldb/test/Shell/Breakpoint/Inputs/search-support-files.h
  lldb/test/Shell/Breakpoint/search-support-files.test

Index: lldb/test/Shell/Breakpoint/search-support-files.test
===
--- /dev/null
+++ lldb/test/Shell/Breakpoint/search-support-files.test
@@ -0,0 +1,123 @@
+# In these tests we will set breakpoints on a function by name with the
+# target.inline-breakpoint-strategy setting alternating between set "always" and
+# "headers".
+
+# RUN: %build %p/Inputs/search-support-files.cpp -o %t.out
+# RUN: %lldb -b -s %s %t.out | FileCheck %s 
+
+
+#Set breakpoint by function name.
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n function_in_header
+# CHECK: (lldb) breakpoint set -n function_in_header
+# CHECK-NEXT: Breakpoint 1: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n function_in_header
+# CHECK: (lldb) breakpoint set -n function_in_header
+# CHECK-NEXT: Breakpoint 2: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n main
+# CHECK: (lldb) breakpoint set -n main
+# CHECK-NEXT: Breakpoint 3: where = {{.*}}.out`main{{.*}} at search-support-files.cpp
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n main
+# CHECK: (lldb) breakpoint set -n main
+# CHECK-NEXT: Breakpoint 4: where = {{.*}}.out`main{{.*}} at search-support-files.cpp
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n func
+# CHECK: (lldb) breakpoint set -n func
+# CHECK-NEXT: Breakpoint 5: where = {{.*}}.out`func{{.*}} at search-support-files-func.cpp
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n func
+# CHECK: (lldb) breakpoint set -n func
+# CHECK-NEXT: Breakpoint 6: where = {{.*}}.out`func{{.*}} at search-support-files-func.cpp
+
+
+
+#   Set breakpoint by function name and filename (here: the compilation unit).
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK: (lldb) breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK-NEXT: Breakpoint 7: no locations (pending).
+
+settings s

[Lldb-commits] [PATCH] D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint

[Konrad Wilhelm Kleine via Phabricator via lldb-commits]

kwk updated this revision to Diff 273309.
kwk added a comment.

- Add newlines


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74136

Files:
  lldb/include/lldb/Core/SearchFilter.h
  lldb/include/lldb/Target/Target.h
  lldb/source/Breakpoint/BreakpointResolverName.cpp
  lldb/source/Core/SearchFilter.cpp
  lldb/source/Target/Target.cpp
  lldb/test/API/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
  lldb/test/Shell/Breakpoint/Inputs/search-support-files-func.cpp
  lldb/test/Shell/Breakpoint/Inputs/search-support-files.cpp
  lldb/test/Shell/Breakpoint/Inputs/search-support-files.h
  lldb/test/Shell/Breakpoint/search-support-files.test

Index: lldb/test/Shell/Breakpoint/search-support-files.test
===
--- /dev/null
+++ lldb/test/Shell/Breakpoint/search-support-files.test
@@ -0,0 +1,123 @@
+# In these tests we will set breakpoints on a function by name with the
+# target.inline-breakpoint-strategy setting alternating between set "always" and
+# "headers".
+
+# RUN: %build %p/Inputs/search-support-files.cpp -o %t.out
+# RUN: %lldb -b -s %s %t.out | FileCheck %s 
+
+
+#Set breakpoint by function name.
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n function_in_header
+# CHECK: (lldb) breakpoint set -n function_in_header
+# CHECK-NEXT: Breakpoint 1: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n function_in_header
+# CHECK: (lldb) breakpoint set -n function_in_header
+# CHECK-NEXT: Breakpoint 2: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n main
+# CHECK: (lldb) breakpoint set -n main
+# CHECK-NEXT: Breakpoint 3: where = {{.*}}.out`main{{.*}} at search-support-files.cpp
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n main
+# CHECK: (lldb) breakpoint set -n main
+# CHECK-NEXT: Breakpoint 4: where = {{.*}}.out`main{{.*}} at search-support-files.cpp
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n func
+# CHECK: (lldb) breakpoint set -n func
+# CHECK-NEXT: Breakpoint 5: where = {{.*}}.out`func{{.*}} at search-support-files-func.cpp
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n func
+# CHECK: (lldb) breakpoint set -n func
+# CHECK-NEXT: Breakpoint 6: where = {{.*}}.out`func{{.*}} at search-support-files-func.cpp
+
+
+
+#   Set breakpoint by function name and filename (here: the compilation unit).
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK: (lldb) breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK-NEXT: Breakpoint 7: no locations (pending).
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK: (lldb) breakpoint set -n function_in_header -f search-support-files.cpp
+# CHECK-NEXT: Breakpoint 8: no locations (pending).
+
+
+
+#   Set breakpoint by function name and source filename (the file in which the
+#   function is defined).
+#
+#   NOTE: This test is the really interesting one as it shows that we can
+# search by source files that are themselves no compilation units.
+
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n function_in_header -f search-support-files.h
+# CHECK: (lldb) breakpoint set -n function_in_header -f search-support-files.h
+# CHECK-NEXT: Breakpoint 9: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n function_in_header -f search-support-files.h
+# CHECK: (lldb) breakpoint set -n function_in_header -f search-support-files.h
+# CHECK-NEXT: Breakpoint 10: where = {{.*}}.out`function_in_header(){{.*}} at search-support-files.h
+
+
+settings set target.inline-breakpoint-strategy always
+breakpoint set -n func -f search-support-files-func.cpp
+# CHECK: (lldb) breakpoint set -n func -f search-support-files-func.cpp
+# CHECK-NEXT: Breakpoint 11: where = {{.*}}.out`func(){{.*}} at search-support-files-func.cpp
+
+settings set target.inline-breakpoint-strategy headers
+breakpoint set -n func -f search-support-files-func.cpp
+# CHECK: (lldb) breakpoint set -n func -f search-support-files-func.cpp
+# CHECK-NEXT: Breakpoint 12: no locations (pending).
+
+
+
+#   Set breakpoint by function name and source filename. This time the file
+#   doesn't exist or is not the file in which the function is declared or
+#   defined. This is to prove that we haven't widen the search space too much.
+#   When we search for a function in a file that doesn't exist, we should get no
+#   results.
+
+
+
+settings se

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Shu Anzai via Phabricator via lldb-commits]

gedatsu217 added a comment.

I understood what you said. Sorry, I misunderstood it. Indeed, 
m_current_autosuggestion is not good for the future. 
I will get the current user input every time calling ApplyCompleteCommand 
instead of using m_current_autosuggestion.

By the way, when I use llvm::Optional as a return, how do I 
receive it? I want to receive the result in 
IOHandlerDelegate::IOHandlerSuggestion. If I write "result = 
...GetAutoSuggestionForCommand(line)", an error, "no viable overloaded '='", 
occurs.


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

https://reviews.llvm.org/D81001



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

[Lldb-commits] [lldb] d0fa52c - [lldb] Rewrite Scalar::GetBytes

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-06-25T15:31:48+02:00
New Revision: d0fa52cc3797fd8805d24a04e6b8198154cd7b53

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

LOG: [lldb] Rewrite Scalar::GetBytes

This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending on which types the objects were storing and
the host endianness).

In the new version the user is responsible for providing a buffer into
which this method will store its binary representation. The main caller
(RegisterValue::GetBytes) already has one such buffer handy, so this did
not require any major rewrites.

To make that work, I've needed to mark the RegisterValue value buffer
mutable -- not an ideal solution, but definitely better than modifying
global storage. This could be further improved by changing
RegisterValue::GetBytes to take a buffer too.

Added: 


Modified: 
lldb/include/lldb/Utility/RegisterValue.h
lldb/include/lldb/Utility/Scalar.h
lldb/source/Utility/RegisterValue.cpp
lldb/source/Utility/Scalar.cpp
lldb/unittests/Utility/ScalarTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/RegisterValue.h 
b/lldb/include/lldb/Utility/RegisterValue.h
index 494f8be5391c..c9f295a8d95a 100644
--- a/lldb/include/lldb/Utility/RegisterValue.h
+++ b/lldb/include/lldb/Utility/RegisterValue.h
@@ -260,8 +260,9 @@ class RegisterValue {
   Scalar m_scalar;
 
   struct {
-uint8_t bytes[kMaxRegisterByteSize]; // This must be big enough to hold any
- // register for any supported target.
+mutable uint8_t
+bytes[kMaxRegisterByteSize]; // This must be big enough to hold any
+ // register for any supported target.
 uint16_t length;
 lldb::ByteOrder byte_order;
   } buffer;

diff  --git a/lldb/include/lldb/Utility/Scalar.h 
b/lldb/include/lldb/Utility/Scalar.h
index 203ba565b223..eda7528a9212 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -106,7 +106,10 @@ class Scalar {
 
   bool ClearBit(uint32_t bit);
 
-  const void *GetBytes() const;
+  /// Store the binary representation of this value into the given storage.
+  /// Exactly GetByteSize() bytes will be stored, and the buffer must be large
+  /// enough to hold this data.
+  void GetBytes(llvm::MutableArrayRef storage) const;
 
   size_t GetByteSize() const;
 

diff  --git a/lldb/source/Utility/RegisterValue.cpp 
b/lldb/source/Utility/RegisterValue.cpp
index 91f4025c923c..7f545c214a4c 100644
--- a/lldb/source/Utility/RegisterValue.cpp
+++ b/lldb/source/Utility/RegisterValue.cpp
@@ -728,7 +728,8 @@ const void *RegisterValue::GetBytes() const {
   case eTypeFloat:
   case eTypeDouble:
   case eTypeLongDouble:
-return m_scalar.GetBytes();
+m_scalar.GetBytes(buffer.bytes);
+return buffer.bytes;
   case eTypeBytes:
 return buffer.bytes;
   }

diff  --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 748dd5541908..b34311b5ef3e 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -7,7 +7,7 @@
 
//===--===//
 
 #include "lldb/Utility/Scalar.h"
-
+#include "lldb/Utility/DataBufferHeap.h"
 #include "lldb/Utility/DataExtractor.h"
 #include "lldb/Utility/Endian.h"
 #include "lldb/Utility/Status.h"
@@ -73,36 +73,36 @@ Scalar::Scalar() : m_type(e_void), 
m_float(static_cast(0)) {}
 
 bool Scalar::GetData(DataExtractor &data, size_t limit_byte_size) const {
   size_t byte_size = GetByteSize();
-  if (byte_size > 0) {
-const uint8_t *bytes = static_cast(GetBytes());
-
-if (limit_byte_size < byte_size) {
-  if (endian::InlHostByteOrder() == eByteOrderLittle) {
-// On little endian systems if we want fewer bytes from the current
-// type we just specify fewer bytes since the LSByte is first...
-byte_size = limit_byte_size;
-  } else if (endian::InlHostByteOrder() == eByteOrderBig) {
-// On big endian systems if we want fewer bytes from the current type
-// have to advance our initial byte pointer and trim down the number of
-// bytes since the MSByte is first
-bytes += byte_size - limit_byte_size;
-byte_size = limit_byte_size;
-  }
+  if (byte_size == 0) {
+data.Clear();
+return false;
+  }
+  auto buffer_up = std::make_unique(byte_size, 0);
+  GetBytes(buffer_up->GetData());
+  lldb::offset_t offset = 0;
+
+  if (limit_byte_size < byte_size) {
+if (endian::InlHostByteOrder() == eByteOrderLittle) {
+  // On little endian systems if we want fewer bytes from the current
+  // type we just 

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Shu Anzai via Phabricator via lldb-commits]

gedatsu217 updated this revision to Diff 273349.
gedatsu217 added a comment.

I revised the code according to your advice.

In addition, llvm::Optional was originally returned in 
CommandInterpreter::GetAutoSuggestionForCommand, but it seems to useless that 
converting llvm::Optional to std::string in the function, so I changed return 
value.

> By the way, when I use llvm::Optional as a return, how do I 
> receive it? I want to receive the result in 
> IOHandlerDelegate::IOHandlerSuggestion. If I write "result = 
> ...GetAutoSuggestionForCommand(line)", an error, "no viable overloaded '='", 
> occurs.

This problem was solved. (I forgot about llvm::None, sorry.)


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

https://reviews.llvm.org/D81001

Files:
  lldb/include/lldb/Core/Debugger.h
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Host/Editline.h
  lldb/include/lldb/Interpreter/CommandInterpreter.h
  lldb/source/Core/CoreProperties.td
  lldb/source/Core/Debugger.cpp
  lldb/source/Core/IOHandler.cpp
  lldb/source/Host/common/Editline.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp

Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -1866,6 +1866,17 @@
   HandleCompletionMatches(request);
 }
 
+llvm::Optional
+CommandInterpreter::GetAutoSuggestionForCommand(llvm::StringRef line) {
+  const size_t s = m_command_history.GetSize();
+  for (size_t i = 0; i < s; ++i) {
+llvm::StringRef entry = m_command_history.GetStringAtIndex(i);
+if (entry.consume_front(line))
+  return entry;
+  }
+  return llvm::None;
+}
+
 CommandInterpreter::~CommandInterpreter() {}
 
 void CommandInterpreter::UpdatePrompt(llvm::StringRef new_prompt) {
Index: lldb/source/Host/common/Editline.cpp
===
--- lldb/source/Host/common/Editline.cpp
+++ lldb/source/Host/common/Editline.cpp
@@ -14,6 +14,7 @@
 #include "lldb/Host/Editline.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/Host.h"
+#include "lldb/Utility/AnsiTerminal.h"
 #include "lldb/Utility/CompletionRequest.h"
 #include "lldb/Utility/FileSpec.h"
 #include "lldb/Utility/LLDBAssert.h"
@@ -1002,8 +1003,20 @@
 case CompletionMode::Normal: {
   std::string to_add = completion.GetCompletion();
   to_add = to_add.substr(request.GetCursorArgumentPrefix().size());
+  std::string to_add_autosuggestion = "";
+  m_suggestion_callback(line, to_add_autosuggestion,
+m_suggestion_callback_baton);
   if (request.GetParsedArg().IsQuoted())
 to_add.push_back(request.GetParsedArg().GetQuoteChar());
+  if (!to_add_autosuggestion.empty() && !to_add.empty()) {
+size_t length = to_add.length();
+if (to_add_autosuggestion.length() > length &&
+to_add == to_add_autosuggestion.substr(0, length)) {
+  to_add.push_back(' ');
+  el_insertstr(m_editline, to_add.c_str());
+  return CC_REFRESH;
+}
+  }
   to_add.push_back(' ');
   el_insertstr(m_editline, to_add.c_str());
   break;
@@ -1040,6 +1053,43 @@
   return CC_REDISPLAY;
 }
 
+unsigned char Editline::ApplyCompleteCommand(int ch) {
+  const LineInfo *line_info = el_line(m_editline);
+  llvm::StringRef line(line_info->buffer,
+   line_info->lastchar - line_info->buffer);
+  std::string to_add = "";
+  m_suggestion_callback(line, to_add, m_suggestion_callback_baton);
+
+  if (to_add.empty())
+return CC_REFRESH;
+
+  el_insertstr(m_editline, to_add.c_str());
+  return CC_REDISPLAY;
+}
+
+unsigned char Editline::TypedCharacter(int ch) {
+  std::string typed = std::string(1, ch);
+  el_insertstr(m_editline, typed.c_str());
+  const LineInfo *line_info = el_line(m_editline);
+  llvm::StringRef line(line_info->buffer,
+   line_info->lastchar - line_info->buffer);
+
+  std::string to_add = "";
+  m_suggestion_callback(line, to_add, m_suggestion_callback_baton);
+
+  if (to_add.empty())
+return CC_REDISPLAY;
+
+  std::string to_add_color = ansi::FormatAnsiTerminalCodes("${ansi.faint}") +
+ to_add +
+ ansi::FormatAnsiTerminalCodes("${ansi.normal}");
+  fputs(typed.c_str(), m_output_file);
+  fputs(to_add_color.c_str(), m_output_file);
+  MoveCursor(CursorLocation::BlockEnd, CursorLocation::EditingPrompt);
+
+  return CC_REFRESH;
+}
+
 void Editline::ConfigureEditor(bool multiline) {
   if (m_editline && m_multiline_enabled == multiline)
 return;
@@ -1153,7 +1203,38 @@
   if (!multiline) {
 el_set(m_editline, EL_BIND, "^r", "em-inc-search-prev",
NULL); // Cycle through backwards search, entering string
+
+if (m_use_autosuggestion) {
+  el_wset(m_editline, EL_ADDFN, EditLineConstString("lldb-apply-complete"),
+   

[Lldb-commits] [PATCH] D82558: [LLDB][NFC] Remove redundant condition

[Balogh , Ádám via Phabricator via lldb-commits]

baloghadamsoftware created this revision.
baloghadamsoftware added a reviewer: clayborg.
baloghadamsoftware added a project: LLDB.
Herald added subscribers: martong, gamesh411, Szelethus, dkrupp, rnkovacs, 
kbarton, kristof.beyls, nemanjai.

Condition `auto_advance_pc` is checked both in an outer and in an inner `if` 
statement in `EmulateInstructionARM::EvaluateInstruction()`, 
`EmulateInstructionARM64::EvaluateInstruction()` and 
`EmulateInstructionPPC64::EvaluateInstruction()`. This patch removes the 
redundant inner check.

The issue was found using `clang-tidy` check under review 
`misc-redundant-condition`. See https://reviews.llvm.org/D81272.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D82558

Files:
  lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
  lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
  lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp


Index: lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
===
--- lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
+++ lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
@@ -198,7 +198,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (new_pc_value == orig_pc_value)) {
+if (new_pc_value == orig_pc_value) {
   EmulateInstruction::Context context;
   context.type = eContextAdvancePC;
   context.SetNoArgs();
Index: lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
===
--- lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -433,7 +433,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (new_pc_value == orig_pc_value)) {
+if (new_pc_value == orig_pc_value) {
   EmulateInstruction::Context context;
   context.type = eContextAdvancePC;
   context.SetNoArgs();
Index: lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
===
--- lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
+++ lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
@@ -14361,7 +14361,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (after_pc_value == orig_pc_value)) {
+if (after_pc_value == orig_pc_value) {
   after_pc_value += m_opcode.GetByteSize();
 
   EmulateInstruction::Context context;


Index: lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
===
--- lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
+++ lldb/source/Plugins/Instruction/PPC64/EmulateInstructionPPC64.cpp
@@ -198,7 +198,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (new_pc_value == orig_pc_value)) {
+if (new_pc_value == orig_pc_value) {
   EmulateInstruction::Context context;
   context.type = eContextAdvancePC;
   context.SetNoArgs();
Index: lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
===
--- lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -433,7 +433,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (new_pc_value == orig_pc_value)) {
+if (new_pc_value == orig_pc_value) {
   EmulateInstruction::Context context;
   context.type = eContextAdvancePC;
   context.SetNoArgs();
Index: lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
===
--- lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
+++ lldb/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
@@ -14361,7 +14361,7 @@
 if (!success)
   return false;
 
-if (auto_advance_pc && (after_pc_value == orig_pc_value)) {
+if (after_pc_value == orig_pc_value) {
   after_pc_value += m_opcode.GetByteSize();
 
   EmulateInstruction::Context context;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D82559: [LLDB][Clang Integration][NFC] Remove redundant condition

[Balogh , Ádám via Phabricator via lldb-commits]

baloghadamsoftware created this revision.
baloghadamsoftware added a reviewer: jingham.
baloghadamsoftware added a project: LLDB.
Herald added subscribers: martong, gamesh411, Szelethus, dkrupp, rnkovacs.

Condition `omit_empty_base_classes` is checked both in an outer and in an inner 
`if` statement in `TypeSystemClang::GetNumBaseClasses()`. This patch removes 
the redundant inner check.

The issue was found using `clang-tidy` check under review 
`misc-redundant-condition`. See https://reviews.llvm.org/D81272.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D82559

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp


Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1729,10 +1729,8 @@
   base_class_end = cxx_record_decl->bases_end();
base_class != base_class_end; ++base_class) {
 // Skip empty base classes
-if (omit_empty_base_classes) {
-  if (BaseSpecifierIsEmpty(base_class))
-continue;
-}
+if (BaseSpecifierIsEmpty(base_class))
+  continue;
 ++num_bases;
   }
 } else


Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -1729,10 +1729,8 @@
   base_class_end = cxx_record_decl->bases_end();
base_class != base_class_end; ++base_class) {
 // Skip empty base classes
-if (omit_empty_base_classes) {
-  if (BaseSpecifierIsEmpty(base_class))
-continue;
-}
+if (BaseSpecifierIsEmpty(base_class))
+  continue;
 ++num_bases;
   }
 } else
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D82477: [lldb-vscode] Add Support for Module Event

[Yifan Shen via Phabricator via lldb-commits]

aelitashen updated this revision to Diff 273378.
aelitashen added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Formatting the codes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82477

Files:
  clang/tools/clang-format/git-clang-format
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/test/API/tools/lldb-vscode/module/Makefile
  lldb/test/API/tools/lldb-vscode/module/TestVSCode_module.py
  lldb/test/API/tools/lldb-vscode/module/main.cpp
  lldb/tools/lldb-vscode/JSONUtils.cpp
  lldb/tools/lldb-vscode/JSONUtils.h
  lldb/tools/lldb-vscode/VSCode.cpp
  lldb/tools/lldb-vscode/lldb-vscode.cpp

Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/Option/Arg.h"
@@ -433,6 +434,30 @@
 g_vsc.SendJSON(llvm::json::Value(std::move(bp_event)));
   }
 }
+  } else if (lldb::SBTarget::EventIsTargetEvent(event)) {
+if (event_mask & lldb::SBTarget::eBroadcastBitModulesLoaded ||
+event_mask & lldb::SBTarget::eBroadcastBitModulesUnloaded ||
+event_mask & lldb::SBTarget::eBroadcastBitSymbolsLoaded) {
+  int num_modules = lldb::SBTarget::GetNumModulesFromEvent(event);
+  for (int i = 0; i < num_modules; i++) {
+auto module = lldb::SBTarget::GetModuleAtIndexFromEvent(i, event);
+auto module_event = CreateEventObject("module");
+llvm::json::Value module_value = CreateModule(module);
+llvm::json::Object body;
+if (event_mask & lldb::SBTarget::eBroadcastBitModulesLoaded) {
+  body.try_emplace("reason", "new");
+} else if (event_mask &
+lldb::SBTarget::eBroadcastBitModulesUnloaded) {
+  body.try_emplace("reason", "removed");
+} else if (event_mask &
+lldb::SBTarget::eBroadcastBitSymbolsLoaded) {
+  body.try_emplace("reason", "changed");
+}
+body.try_emplace("module", module_value);
+module_event.try_emplace("body", std::move(body));
+g_vsc.SendJSON(llvm::json::Value(std::move(module_event)));
+  }
+}
   } else if (event.BroadcasterMatchesRef(g_vsc.broadcaster)) {
 if (event_mask & eBroadcastBitStopEventThread) {
   done = true;
Index: lldb/tools/lldb-vscode/VSCode.cpp
===
--- lldb/tools/lldb-vscode/VSCode.cpp
+++ lldb/tools/lldb-vscode/VSCode.cpp
@@ -354,6 +354,11 @@
 lldb::SBTarget::eBroadcastBitBreakpointChanged);
 listener.StartListeningForEvents(this->broadcaster,
  eBroadcastBitStopEventThread);
+listener.StartListeningForEvents(
+  this->target.GetBroadcaster(),
+  lldb::SBTarget::eBroadcastBitModulesLoaded |
+  lldb::SBTarget::eBroadcastBitModulesUnloaded |
+  lldb::SBTarget::eBroadcastBitSymbolsLoaded);
   }
 }
 
Index: lldb/tools/lldb-vscode/JSONUtils.h
===
--- lldb/tools/lldb-vscode/JSONUtils.h
+++ lldb/tools/lldb-vscode/JSONUtils.h
@@ -13,6 +13,7 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/JSON.h"
 #include "VSCodeForward.h"
+#include "lldb/API/SBModule.h"
 
 namespace lldb_vscode {
 
@@ -237,6 +238,16 @@
  llvm::Optional request_path = llvm::None,
  llvm::Optional request_line = llvm::None);
 
+/// Converts Module Event to a Visual Studio Code "Module"
+///
+/// \param[in] module
+/// A LLDB module object to convert into a JSON value
+///
+/// \return
+/// A "Module" JSON object with that follows the formal JSON
+/// definition outlined by Microsoft.
+llvm::json::Value CreateModule(lldb::SBModule &module);
+
 /// Create a "Event" JSON object using \a event_name as the event name
 ///
 /// \param[in] event_name
Index: lldb/tools/lldb-vscode/JSONUtils.cpp
===
--- lldb/tools/lldb-vscode/JSONUtils.cpp
+++ lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -327,6 +327,31 @@
   return llvm::json::Value(std::move(object));
 }
 
+llvm::json::Value CreateModule(lldb::SBModule &module) {
+  llvm::json::Object object;
+  if (!module.IsValid())
+return llvm::json::Value(std::move(object));
+  object.try_emplace("id", std::string(module.GetUUIDString()));
+  object.try_emplace(
+"name",
+std::string(module.GetFileSpec().GetFilename()));
+  std::string module_path = std::string(module.GetFileSpec().GetDirectory()) +
+"/" +
+  

[Lldb-commits] [PATCH] D82505: [lldb-vscode] Add Support for Module Event

[Yifan Shen via Phabricator via lldb-commits]

aelitashen abandoned this revision.
aelitashen added a comment.

Mistakenly created two diffs on same commit, See D82477 
 for the original diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82505



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

[Lldb-commits] [lldb] d79273c - [lldb/ScriptInterpreter] Extract IO redirection logic

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T09:43:28-07:00
New Revision: d79273c941d58486d09c020eb7767a5246a9c24d

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

LOG: [lldb/ScriptInterpreter] Extract IO redirection logic

This patch takes the IO redirection logic from ScriptInterpreterPython
and moves it into the interpreter library so that it can be used by
other script interpreters. I've turned it into a RAII object so that we
don't have to worry about cleaning up in the calling code.

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

Added: 


Modified: 
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/source/Interpreter/ScriptInterpreter.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h 
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index d008e18e7b6f..8086886149f8 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -9,16 +9,16 @@
 #ifndef LLDB_INTERPRETER_SCRIPTINTERPRETER_H
 #define LLDB_INTERPRETER_SCRIPTINTERPRETER_H
 
-#include "lldb/lldb-private.h"
-
 #include "lldb/Breakpoint/BreakpointOptions.h"
+#include "lldb/Core/Communication.h"
 #include "lldb/Core/PluginInterface.h"
 #include "lldb/Core/SearchFilter.h"
+#include "lldb/Core/StreamFile.h"
+#include "lldb/Host/PseudoTerminal.h"
 #include "lldb/Utility/Broadcaster.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StructuredData.h"
-
-#include "lldb/Host/PseudoTerminal.h"
+#include "lldb/lldb-private.h"
 
 namespace lldb_private {
 
@@ -34,6 +34,37 @@ class ScriptInterpreterLocker {
   operator=(const ScriptInterpreterLocker &) = delete;
 };
 
+class ScriptInterpreterIORedirect {
+public:
+  /// Create an IO redirect with /dev/null as input, output and error file.
+  static llvm::Expected> Create();
+
+  /// Create an IO redirect that redirects the output to the command return
+  /// object if set or to the debugger otherwise.
+  static llvm::Expected>
+  Create(Debugger &debugger, CommandReturnObject *result);
+
+  ~ScriptInterpreterIORedirect();
+
+  lldb::FileSP GetInputFile() const { return m_input_file_sp; }
+  lldb::FileSP GetOutputFile() const { return m_output_file_sp->GetFileSP(); }
+  lldb::FileSP GetErrorFile() const { return m_error_file_sp->GetFileSP(); }
+
+  /// Flush our output and error file handles.
+  void Flush();
+
+private:
+  ScriptInterpreterIORedirect(std::unique_ptr input,
+  std::unique_ptr output);
+  ScriptInterpreterIORedirect(Debugger &debugger, CommandReturnObject *result);
+
+  lldb::FileSP m_input_file_sp;
+  lldb::StreamFileSP m_output_file_sp;
+  lldb::StreamFileSP m_error_file_sp;
+  Communication m_communication;
+  bool m_disconnect;
+};
+
 class ScriptInterpreter : public PluginInterface {
 public:
   enum ScriptReturnType {

diff  --git a/lldb/source/Interpreter/ScriptInterpreter.cpp 
b/lldb/source/Interpreter/ScriptInterpreter.cpp
index 2dda1bbbff47..d46a104fa25c 100644
--- a/lldb/source/Interpreter/ScriptInterpreter.cpp
+++ b/lldb/source/Interpreter/ScriptInterpreter.cpp
@@ -8,10 +8,14 @@
 
 #include "lldb/Interpreter/ScriptInterpreter.h"
 
+#include 
 #include 
 #include 
 #include 
 
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/ConnectionFileDescriptor.h"
+#include "lldb/Host/Pipe.h"
 #include "lldb/Host/PseudoTerminal.h"
 #include "lldb/Interpreter/CommandReturnObject.h"
 #include "lldb/Utility/Status.h"
@@ -104,3 +108,113 @@ std::unique_ptr
 ScriptInterpreter::AcquireInterpreterLock() {
   return std::make_unique();
 }
+
+static void ReadThreadBytesReceived(void *baton, const void *src,
+size_t src_len) {
+  if (src && src_len) {
+Stream *strm = (Stream *)baton;
+strm->Write(src, src_len);
+strm->Flush();
+  }
+}
+
+llvm::Expected>
+ScriptInterpreterIORedirect::Create() {
+  auto nullin = FileSystem::Instance().Open(FileSpec(FileSystem::DEV_NULL),
+File::eOpenOptionRead);
+  if (!nullin)
+return nullin.takeError();
+
+  auto nullout = FileSystem::Instance().Open(FileSpec(FileSystem::DEV_NULL),
+ File::eOpenOptionWrite);
+  if (!nullout)
+return nullin.takeError();
+
+  return std::unique_ptr(
+  new ScriptInterpreterIORedirect(std::move(*nullin), 
std::move(*nullout)));
+}
+
+llvm::Expected>
+ScriptInterpreterIORedirect::Create(Debugger &debugger,
+CommandReturnObject *result) {
+  return std::unique_ptr(
+  new ScriptInterpreterIORedirect(debugger, result));
+}
+
+ScriptInterpreterIORedirect::ScriptInterpreterIORedirect(
+std::unique

[Lldb-commits] [lldb] ed8184b - [lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObject

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T09:55:46-07:00
New Revision: ed8184b7814df4310dbad065a9a1c3bb8f3bfa86

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

LOG: [lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObject

Redirect the output of stdout and stderr to the CommandReturnObject for
one line commands.

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

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
lldb/test/Shell/ScriptInterpreter/Lua/io.test

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
index 30a50e1c9888..8cbeac4563c3 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
@@ -15,6 +15,7 @@
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/StringList.h"
 #include "lldb/Utility/Timer.h"
+#include "llvm/Support/FormatAdapters.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -65,12 +66,43 @@ ScriptInterpreterLua::~ScriptInterpreterLua() {}
 bool ScriptInterpreterLua::ExecuteOneLine(llvm::StringRef command,
   CommandReturnObject *result,
   const ExecuteScriptOptions &options) 
{
+  if (command.empty()) {
+if (result)
+  result->AppendError("empty command passed to lua\n");
+return false;
+  }
+
+  llvm::Expected>
+  io_redirect_or_error = ScriptInterpreterIORedirect::Create(
+  options.GetEnableIO(), m_debugger, result);
+  if (!io_redirect_or_error) {
+if (result)
+  result->AppendErrorWithFormatv(
+  "failed to redirect I/O: {0}\n",
+  llvm::fmt_consume(io_redirect_or_error.takeError()));
+else
+  llvm::consumeError(io_redirect_or_error.takeError());
+return false;
+  }
+
+  ScriptInterpreterIORedirect &io_redirect = **io_redirect_or_error;
+
+  if (llvm::Error e =
+  m_lua->ChangeIO(io_redirect.GetOutputFile()->GetStream(),
+  io_redirect.GetErrorFile()->GetStream())) {
+result->AppendErrorWithFormatv("lua failed to redirect I/O: {0}\n",
+   llvm::toString(std::move(e)));
+return false;
+  }
+
   if (llvm::Error e = m_lua->Run(command)) {
 result->AppendErrorWithFormatv(
 "lua failed attempting to evaluate '{0}': {1}\n", command,
 llvm::toString(std::move(e)));
 return false;
   }
+
+  io_redirect.Flush();
   return true;
 }
 

diff  --git a/lldb/test/Shell/ScriptInterpreter/Lua/io.test 
b/lldb/test/Shell/ScriptInterpreter/Lua/io.test
index fecdd344b885..af86253f90f2 100644
--- a/lldb/test/Shell/ScriptInterpreter/Lua/io.test
+++ b/lldb/test/Shell/ScriptInterpreter/Lua/io.test
@@ -1,6 +1,7 @@
 # REQUIRES: lua
 # UNSUPPORTED: lldb-repro
 #
+# RUN: rm -rf %t.stderr %t.stdout
 # RUN: cat %s | %lldb --script-language lua 2> %t.stderr > %t.stdout
 # RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT
 # RUN: cat %t.stderr | FileCheck %s --check-prefix STDERR
@@ -11,6 +12,11 @@ io.write(95000 + 126, "\n")
 quit
 script
 io.write(95000 + 14, "\n")
+
 # STDOUT: 95126
 # STDOUT-NOT: 95014
 # STDERR: 95014
+
+# RUN: rm -rf %t.stderr %t.stdout
+# RUN: %lldb --script-language lua -o 'script io.stderr:write(95000 + 126, 
"\n")' 2> %t.stderr > %t.stdout
+# RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT



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

[Lldb-commits] [lldb] 8422836 - [lldb/ScriptInterpreter] Let the IORedirect factory handle IO being disabled.

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T09:55:46-07:00
New Revision: 842283652eb89e7c207ecfdac5e546472332f02b

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

LOG: [lldb/ScriptInterpreter] Let the IORedirect factory handle IO being 
disabled.

Have one factory method that decides how to initialize the
ScriptInterpreterIORedirect object based on whether IO is enabled or
disabled.

Added: 


Modified: 
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/source/Interpreter/ScriptInterpreter.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h 
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index 8086886149f8..491923e6a6c4 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -36,13 +36,11 @@ class ScriptInterpreterLocker {
 
 class ScriptInterpreterIORedirect {
 public:
-  /// Create an IO redirect with /dev/null as input, output and error file.
-  static llvm::Expected> Create();
-
-  /// Create an IO redirect that redirects the output to the command return
-  /// object if set or to the debugger otherwise.
+  /// Create an IO redirect. If IO is enabled, this will redirects the output
+  /// to the command return object if set or to the debugger otherwise. If IO
+  /// is disabled, it will redirect all IO to /dev/null.
   static llvm::Expected>
-  Create(Debugger &debugger, CommandReturnObject *result);
+  Create(bool enable_io, Debugger &debugger, CommandReturnObject *result);
 
   ~ScriptInterpreterIORedirect();
 

diff  --git a/lldb/source/Interpreter/ScriptInterpreter.cpp 
b/lldb/source/Interpreter/ScriptInterpreter.cpp
index d46a104fa25c..967c22819313 100644
--- a/lldb/source/Interpreter/ScriptInterpreter.cpp
+++ b/lldb/source/Interpreter/ScriptInterpreter.cpp
@@ -119,7 +119,12 @@ static void ReadThreadBytesReceived(void *baton, const 
void *src,
 }
 
 llvm::Expected>
-ScriptInterpreterIORedirect::Create() {
+ScriptInterpreterIORedirect::Create(bool enable_io, Debugger &debugger,
+CommandReturnObject *result) {
+  if (enable_io)
+return std::unique_ptr(
+new ScriptInterpreterIORedirect(debugger, result));
+
   auto nullin = FileSystem::Instance().Open(FileSpec(FileSystem::DEV_NULL),
 File::eOpenOptionRead);
   if (!nullin)
@@ -134,13 +139,6 @@ ScriptInterpreterIORedirect::Create() {
   new ScriptInterpreterIORedirect(std::move(*nullin), 
std::move(*nullout)));
 }
 
-llvm::Expected>
-ScriptInterpreterIORedirect::Create(Debugger &debugger,
-CommandReturnObject *result) {
-  return std::unique_ptr(
-  new ScriptInterpreterIORedirect(debugger, result));
-}
-
 ScriptInterpreterIORedirect::ScriptInterpreterIORedirect(
 std::unique_ptr input, std::unique_ptr output)
 : m_input_file_sp(std::move(input)),

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 40ce7d997800..d7f2fc659cf6 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -912,10 +912,8 @@ bool ScriptInterpreterPythonImpl::ExecuteOneLine(
 // we use the following more complicated method to pass the command string
 // directly down to Python.
 llvm::Expected>
-io_redirect_or_error =
-options.GetEnableIO()
-? ScriptInterpreterIORedirect::Create(m_debugger, result)
-: ScriptInterpreterIORedirect::Create();
+io_redirect_or_error = ScriptInterpreterIORedirect::Create(
+options.GetEnableIO(), m_debugger, result);
 if (!io_redirect_or_error) {
   if (result)
 result->AppendErrorWithFormatv(



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

[Lldb-commits] [lldb] 4df7d85 - [lldb][NFC] Use expect_expr in TestDollarInVariable

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2020-06-25T19:07:55+02:00
New Revision: 4df7d852afc04844184f0a02d3a3ca4449bbbc5f

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

LOG: [lldb][NFC] Use expect_expr in TestDollarInVariable

Added: 


Modified: 
lldb/test/API/commands/expression/dollar-in-variable/main.c

Removed: 




diff  --git a/lldb/test/API/commands/expression/dollar-in-variable/main.c 
b/lldb/test/API/commands/expression/dollar-in-variable/main.c
index 97c939b68edf..7d2a048720bd 100644
--- a/lldb/test/API/commands/expression/dollar-in-variable/main.c
+++ b/lldb/test/API/commands/expression/dollar-in-variable/main.c
@@ -13,10 +13,10 @@ int main() {
   int $R0 = 13;
   int $0 = 14;
 
-  //%self.expect("expr $__lldb_expr_result", substrs=['(int) $0 = 11'])
-  //%self.expect("expr $foo", substrs=['(int)', ' = 12'])
-  //%self.expect("expr $R0", substrs=['(int)', ' = 13'])
+  //%self.expect_expr("$__lldb_expr_result", result_type="int", 
result_value="11")
+  //%self.expect_expr("$foo", result_type="int", result_value="12")
+  //%self.expect_expr("$R0", result_type="int", result_value="13")
   //%self.expect("expr int $foo = 123", error=True, substrs=["declaration 
conflicts"])
-  //%self.expect("expr $0", substrs=['(int)', ' = 11'])
+  //%self.expect_expr("$0", result_type="int", result_value="11")
   return 0;
 }



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

[Lldb-commits] [PATCH] D82507: [lldb/Docs] Add more details to the issues with custom Python installs on macOS

[Frederic Riss via Phabricator via lldb-commits]

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

LGTM


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D82507



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

[Lldb-commits] [PATCH] D82412: [lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObject

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGed8184b7814d: [lldb/Lua] Redirect Lua stdout/stderr to the 
CommandReturnObject (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D82412?vs=273073&id=273432#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82412

Files:
  lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
  lldb/test/Shell/ScriptInterpreter/Lua/io.test


Index: lldb/test/Shell/ScriptInterpreter/Lua/io.test
===
--- lldb/test/Shell/ScriptInterpreter/Lua/io.test
+++ lldb/test/Shell/ScriptInterpreter/Lua/io.test
@@ -1,6 +1,7 @@
 # REQUIRES: lua
 # UNSUPPORTED: lldb-repro
 #
+# RUN: rm -rf %t.stderr %t.stdout
 # RUN: cat %s | %lldb --script-language lua 2> %t.stderr > %t.stdout
 # RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT
 # RUN: cat %t.stderr | FileCheck %s --check-prefix STDERR
@@ -11,6 +12,11 @@
 quit
 script
 io.write(95000 + 14, "\n")
+
 # STDOUT: 95126
 # STDOUT-NOT: 95014
 # STDERR: 95014
+
+# RUN: rm -rf %t.stderr %t.stdout
+# RUN: %lldb --script-language lua -o 'script io.stderr:write(95000 + 126, 
"\n")' 2> %t.stderr > %t.stdout
+# RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT
Index: lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
@@ -15,6 +15,7 @@
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/StringList.h"
 #include "lldb/Utility/Timer.h"
+#include "llvm/Support/FormatAdapters.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -65,12 +66,43 @@
 bool ScriptInterpreterLua::ExecuteOneLine(llvm::StringRef command,
   CommandReturnObject *result,
   const ExecuteScriptOptions &options) 
{
+  if (command.empty()) {
+if (result)
+  result->AppendError("empty command passed to lua\n");
+return false;
+  }
+
+  llvm::Expected>
+  io_redirect_or_error = ScriptInterpreterIORedirect::Create(
+  options.GetEnableIO(), m_debugger, result);
+  if (!io_redirect_or_error) {
+if (result)
+  result->AppendErrorWithFormatv(
+  "failed to redirect I/O: {0}\n",
+  llvm::fmt_consume(io_redirect_or_error.takeError()));
+else
+  llvm::consumeError(io_redirect_or_error.takeError());
+return false;
+  }
+
+  ScriptInterpreterIORedirect &io_redirect = **io_redirect_or_error;
+
+  if (llvm::Error e =
+  m_lua->ChangeIO(io_redirect.GetOutputFile()->GetStream(),
+  io_redirect.GetErrorFile()->GetStream())) {
+result->AppendErrorWithFormatv("lua failed to redirect I/O: {0}\n",
+   llvm::toString(std::move(e)));
+return false;
+  }
+
   if (llvm::Error e = m_lua->Run(command)) {
 result->AppendErrorWithFormatv(
 "lua failed attempting to evaluate '{0}': {1}\n", command,
 llvm::toString(std::move(e)));
 return false;
   }
+
+  io_redirect.Flush();
   return true;
 }
 


Index: lldb/test/Shell/ScriptInterpreter/Lua/io.test
===
--- lldb/test/Shell/ScriptInterpreter/Lua/io.test
+++ lldb/test/Shell/ScriptInterpreter/Lua/io.test
@@ -1,6 +1,7 @@
 # REQUIRES: lua
 # UNSUPPORTED: lldb-repro
 #
+# RUN: rm -rf %t.stderr %t.stdout
 # RUN: cat %s | %lldb --script-language lua 2> %t.stderr > %t.stdout
 # RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT
 # RUN: cat %t.stderr | FileCheck %s --check-prefix STDERR
@@ -11,6 +12,11 @@
 quit
 script
 io.write(95000 + 14, "\n")
+
 # STDOUT: 95126
 # STDOUT-NOT: 95014
 # STDERR: 95014
+
+# RUN: rm -rf %t.stderr %t.stdout
+# RUN: %lldb --script-language lua -o 'script io.stderr:write(95000 + 126, "\n")' 2> %t.stderr > %t.stdout
+# RUN: cat %t.stdout | FileCheck %s --check-prefix STDOUT
Index: lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
@@ -15,6 +15,7 @@
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/StringList.h"
 #include "lldb/Utility/Timer.h"
+#include "llvm/Support/FormatAdapters.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -65,12 +66,43 @@
 bool ScriptInterpreterLua::ExecuteOneLine(llvm::StringRef command,
   CommandReturnObject *result,
   const ExecuteScriptOptions &options) {
+  if (command.empty()) {
+if (

[Lldb-commits] [PATCH] D82396: [lldb/ScriptInterpreter] Extract IO redirection logic and move it out of ScriptInterpreterPython (NFC)

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd79273c941d5: [lldb/ScriptInterpreter] Extract IO 
redirection logic (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D82396?vs=273068&id=273429#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82396

Files:
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -42,6 +42,7 @@
 
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatAdapters.h"
 
@@ -895,15 +896,6 @@
   return m_run_one_line_function.IsValid();
 }
 
-static void ReadThreadBytesReceived(void *baton, const void *src,
-size_t src_len) {
-  if (src && src_len) {
-Stream *strm = (Stream *)baton;
-strm->Write(src, src_len);
-strm->Flush();
-  }
-}
-
 bool ScriptInterpreterPythonImpl::ExecuteOneLine(
 llvm::StringRef command, CommandReturnObject *result,
 const ExecuteScriptOptions &options) {
@@ -919,77 +911,23 @@
 // another string to pass to PyRun_SimpleString messes up the escaping.  So
 // we use the following more complicated method to pass the command string
 // directly down to Python.
-Debugger &debugger = m_debugger;
-
-FileSP input_file_sp;
-StreamFileSP output_file_sp;
-StreamFileSP error_file_sp;
-Communication output_comm(
-"lldb.ScriptInterpreterPythonImpl.ExecuteOneLine.comm");
-bool join_read_thread = false;
-if (options.GetEnableIO()) {
-  if (result) {
-input_file_sp = debugger.GetInputFileSP();
-// Set output to a temporary file so we can forward the results on to
-// the result object
-
-Pipe pipe;
-Status pipe_result = pipe.CreateNew(false);
-if (pipe_result.Success()) {
-#if defined(_WIN32)
-  lldb::file_t read_file = pipe.GetReadNativeHandle();
-  pipe.ReleaseReadFileDescriptor();
-  std::unique_ptr conn_up(
-  new ConnectionGenericFile(read_file, true));
-#else
-  std::unique_ptr conn_up(
-  new ConnectionFileDescriptor(pipe.ReleaseReadFileDescriptor(),
-   true));
-#endif
-  if (conn_up->IsConnected()) {
-output_comm.SetConnection(std::move(conn_up));
-output_comm.SetReadThreadBytesReceivedCallback(
-ReadThreadBytesReceived, &result->GetOutputStream());
-output_comm.StartReadThread();
-join_read_thread = true;
-FILE *outfile_handle =
-fdopen(pipe.ReleaseWriteFileDescriptor(), "w");
-output_file_sp = std::make_shared(outfile_handle, true);
-error_file_sp = output_file_sp;
-if (outfile_handle)
-  ::setbuf(outfile_handle, nullptr);
-
-result->SetImmediateOutputFile(
-debugger.GetOutputStream().GetFileSP());
-result->SetImmediateErrorFile(
-debugger.GetErrorStream().GetFileSP());
-  }
-}
-  }
-  if (!input_file_sp || !output_file_sp || !error_file_sp)
-debugger.AdoptTopIOHandlerFilesIfInvalid(input_file_sp, output_file_sp,
- error_file_sp);
-} else {
-  auto nullin = FileSystem::Instance().Open(
-  FileSpec(FileSystem::DEV_NULL),
-  File::eOpenOptionRead);
-  auto nullout = FileSystem::Instance().Open(
-  FileSpec(FileSystem::DEV_NULL),
-  File::eOpenOptionWrite);
-  if (!nullin) {
-result->AppendErrorWithFormatv("failed to open /dev/null: {0}\n",
-   llvm::fmt_consume(nullin.takeError()));
-return false;
-  }
-  if (!nullout) {
-result->AppendErrorWithFormatv("failed to open /dev/null: {0}\n",
-   llvm::fmt_consume(nullout.takeError()));
-return false;
-  }
-  input_file_sp = std::move(nullin.get());
-  error_file_sp = output_file_sp = std::make_shared(std::move(nullout.get()));
+llvm::Expected>
+io_redirect_or_error =
+options.GetEnableIO()
+? ScriptInterpreterIORedirect::Create(m_debugger, result)
+: ScriptInterpr

[Lldb-commits] [lldb] 2bdd41b - [lldb/Docs] Add more details to the issues with custom Python installs on macOS

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T10:53:30-07:00
New Revision: 2bdd41b8c0b4cc8d13ca6c3d255a642a8a9c0969

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

LOG: [lldb/Docs] Add more details to the issues with custom Python installs on 
macOS

Although this issue is not specific to macOS, Python (in)compatibility
comes up quite often and we've been linking users to this page. This
just adds more details for this particular scenario.

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

Added: 


Modified: 
lldb/docs/resources/caveats.rst

Removed: 




diff  --git a/lldb/docs/resources/caveats.rst b/lldb/docs/resources/caveats.rst
index 7a77b0dce9fd..2f37a6821ca5 100644
--- a/lldb/docs/resources/caveats.rst
+++ b/lldb/docs/resources/caveats.rst
@@ -31,7 +31,41 @@ against Python comes with some constraints to be aware of.
 the one used to build and link LLDB.
 
 The previous considerations are especially important during development, but
-apply to binary distributions of LLDB as well. For example, the LLDB that comes
-with Xcode links against the Python 3 that's part of Xcode. Therefore you
-should always use the Python in Xcode (through ``xcrun python3`` or
-``/usr/bin/python3``) to import the lldb module or install packages.
+apply to binary distributions of LLDB as well.
+
+LLDB in Xcode on macOS
+``
+
+Users of lldb in Xcode on macOS commonly run into these issues when they
+install Python, often unknowingly as a dependency pulled in by Homebrew or
+other package managers. The problem is the symlinks that get created in
+``/usr/local/bin``, which comes before ``/usr/bin`` in your path. You can use
+``which python3`` to check to what it resolves.
+
+To be sure you use the Python that matches with the lldb in Xcode use ``xcrun``
+or use the absolute path to the shims in ``/usr/bin``.
+
+::
+
+   $ xcrun python3
+   $ /usr/bin/python3
+
+Similarly, to install packages and be able to use them from within lldb, you'll
+need to install them with the matching ``pip3``.
+
+::
+
+   $ xcrun pip3
+   $ /usr/bin/pip3
+
+The same is true for Python 2. Although Python 2 comes with the operating
+system rather than Xcode, you can still use ``xcrun`` to launch the system
+variant.
+
+::
+
+   $ xcrun python
+   $ /usr/bin/python
+
+Keep in mind that Python 2 is deprecated and no longer maintained. Future
+versions of macOS will not include Python 2.7.



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

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

Just a quick comment while I look into how we can test this code.




Comment at: lldb/source/Host/common/Editline.cpp:1017
+  el_insertstr(m_editline, to_add.c_str());
+  return CC_REFRESH;
+}

If I understand the only effect this whole code has is to return CC_REFRESH 
instead of CC_REDISPLAY? If yes, then I think you can just replace the `break` 
below with `return CC_REFRESH;` which will be much simpler.


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

https://reviews.llvm.org/D81001



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

[Lldb-commits] [PATCH] D82522: [lldb/IOHandlerCursesGUI] Make the menu bar clickable

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

I wrote all this, so feel free to contact me directly with questions! It would 
be nice to pass the events along to the window or object for the mouse 
coordinates. See inlined comment and let me know what you think.




Comment at: lldb/source/Core/IOHandlerCursesGUI.cpp:1085
+if (event.bstate & BUTTON1_PRESSED) {
+  int selected = GetSubmenuForPosition(event.x, event.y);
+  if (selected < static_cast(num_submenus)) {

It might be nice for this to be a bit more generic and be 
GetWindowForPosition(...). If we are going to enable mouse support, it would be 
nice to pass the mouse clicks to the windows and let them handle the clicks. 
Something like:

```
auto window = GetWindowForPosition(event.x, event.y);
if (window)
  result = window->HandleMouseButtonPressed(event);
```

The HandleMouseButton will return eKeyHandled if it handled the press. We might 
also allow other button presses to be passed along for right click and center 
clicks.
Then menu bars can handle the clicking. We might also want to pass


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D82522



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

[Lldb-commits] [PATCH] D82477: [lldb-vscode] Add Support for Module Event

[Greg Clayton via Phabricator via lldb-commits]

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

We need to add a test for the symbols added target notification. See my 
previous comment on stripping a.out to a.out.stripped and then using 
"a.out.stripped" as the main executable.




Comment at: lldb/test/API/tools/lldb-vscode/module/main.cpp:2-9
+int multiply(int x, int y) {
+  return x * y; // breakpoint 1
+}
+
+int main(int argc, char const *argv[]) {
+  int result = multiply(argc, 20);
+  return result < 0;

We can probably simplify this to just be:

```
int main(int argc, char const *argv[]) {
  return 0; // breakpoint 1
}
```



Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:337-340
+std::string(module.GetFileSpec().GetFilename()));
+  std::string module_path = std::string(module.GetFileSpec().GetDirectory()) +
+"/" +
+std::string(module.GetFileSpec().GetFilename());

Let LLDB take care of the directory delimiter. Otherwise this will be bad on 
windows:
```
char module_path[PATH_MAX];
module.GetFileSpec().GetPath(module_path, sizeof(module_path));
```




Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:344-346
+std::string symbol_path =
+std::string(module.GetSymbolFileSpec().GetDirectory()) + "/" +
+std::string(module.GetSymbolFileSpec().GetFilename());

Let LLDB take care of the directory delimiter. Otherwise this will be bad on 
windows:

```
char symbol_path[PATH_MAX];
module.GetSymbolFileSpec().GetPath(module_path, sizeof(symbol_path));
```




Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:349-350
+  }
+  std::string loaded_addr = std::to_string(
+  module.GetObjectFileHeaderAddress().GetLoadAddress(g_vsc.target));
+  object.try_emplace("addressRange", loaded_addr);

We need to make sure the address returned is valid and we want the string value 
to be in hex. Are we sure std::to_string() will create a hex number? If not we 
can use sprintf:

```
uint64_t load_addr = 
module.GetObjectFileHeaderAddress().GetLoadAddress(g_vsc.target);
if (load_addr != LLDB_INVALID_ADDRESS) {
  char load_addr_str[64];
  snprintf(load_addr_str, sizeof(load_addr_str), "0x%016" PRIx64, load_addr);
  object.try_emplace("addressRange", load_addr_str);
}
```



Comment at: lldb/tools/lldb-vscode/JSONUtils.h:241
 
+/// Converts Module Event to a Visual Studio Code "Module"
+///

Might be better with text like:

```
/// Converts a LLDB module to a VS Code DAP module for use in "modules" events.
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82477



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

[Lldb-commits] [PATCH] D82507: [lldb/Docs] Add more details to the issues with custom Python installs on macOS

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2bdd41b8c0b4: [lldb/Docs] Add more details to the issues 
with custom Python installs on macOS (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D82507?vs=273179&id=273465#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82507

Files:
  lldb/docs/resources/caveats.rst


Index: lldb/docs/resources/caveats.rst
===
--- lldb/docs/resources/caveats.rst
+++ lldb/docs/resources/caveats.rst
@@ -31,7 +31,41 @@
 the one used to build and link LLDB.
 
 The previous considerations are especially important during development, but
-apply to binary distributions of LLDB as well. For example, the LLDB that comes
-with Xcode links against the Python 3 that's part of Xcode. Therefore you
-should always use the Python in Xcode (through ``xcrun python3`` or
-``/usr/bin/python3``) to import the lldb module or install packages.
+apply to binary distributions of LLDB as well.
+
+LLDB in Xcode on macOS
+``
+
+Users of lldb in Xcode on macOS commonly run into these issues when they
+install Python, often unknowingly as a dependency pulled in by Homebrew or
+other package managers. The problem is the symlinks that get created in
+``/usr/local/bin``, which comes before ``/usr/bin`` in your path. You can use
+``which python3`` to check to what it resolves.
+
+To be sure you use the Python that matches with the lldb in Xcode use ``xcrun``
+or use the absolute path to the shims in ``/usr/bin``.
+
+::
+
+   $ xcrun python3
+   $ /usr/bin/python3
+
+Similarly, to install packages and be able to use them from within lldb, you'll
+need to install them with the matching ``pip3``.
+
+::
+
+   $ xcrun pip3
+   $ /usr/bin/pip3
+
+The same is true for Python 2. Although Python 2 comes with the operating
+system rather than Xcode, you can still use ``xcrun`` to launch the system
+variant.
+
+::
+
+   $ xcrun python
+   $ /usr/bin/python
+
+Keep in mind that Python 2 is deprecated and no longer maintained. Future
+versions of macOS will not include Python 2.7.


Index: lldb/docs/resources/caveats.rst
===
--- lldb/docs/resources/caveats.rst
+++ lldb/docs/resources/caveats.rst
@@ -31,7 +31,41 @@
 the one used to build and link LLDB.
 
 The previous considerations are especially important during development, but
-apply to binary distributions of LLDB as well. For example, the LLDB that comes
-with Xcode links against the Python 3 that's part of Xcode. Therefore you
-should always use the Python in Xcode (through ``xcrun python3`` or
-``/usr/bin/python3``) to import the lldb module or install packages.
+apply to binary distributions of LLDB as well.
+
+LLDB in Xcode on macOS
+``
+
+Users of lldb in Xcode on macOS commonly run into these issues when they
+install Python, often unknowingly as a dependency pulled in by Homebrew or
+other package managers. The problem is the symlinks that get created in
+``/usr/local/bin``, which comes before ``/usr/bin`` in your path. You can use
+``which python3`` to check to what it resolves.
+
+To be sure you use the Python that matches with the lldb in Xcode use ``xcrun``
+or use the absolute path to the shims in ``/usr/bin``.
+
+::
+
+   $ xcrun python3
+   $ /usr/bin/python3
+
+Similarly, to install packages and be able to use them from within lldb, you'll
+need to install them with the matching ``pip3``.
+
+::
+
+   $ xcrun pip3
+   $ /usr/bin/pip3
+
+The same is true for Python 2. Although Python 2 comes with the operating
+system rather than Xcode, you can still use ``xcrun`` to launch the system
+variant.
+
+::
+
+   $ xcrun python
+   $ /usr/bin/python
+
+Keep in mind that Python 2 is deprecated and no longer maintained. Future
+versions of macOS will not include Python 2.7.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Jim Ingham via lldb-commits]

I’m not sure 

> On Jun 25, 2020, at 5:08 AM, Pavel Labath  wrote:
> 
> On 24/06/2020 18:55, Jim Ingham wrote:
>> 
>>> On Jun 22, 2020, at 5:52 AM, Pavel Labath via Phabricator via lldb-commits 
>>>  wrote:
>>> 
>>> labath added a comment.
>>> 
>>> This seems like it could be useful in some circumstances, though for the 
>>> use cases I am imagining (bug reporting) it would be easier to just 
>>> copy-paste the terminal contents.
>>> 
>>> As for the implementation, if the intention is for this to eventually 
>>> capture all debugger output, then I am not sure if this is the right 
>>> design. I think it would be fine for python/lua interpreters as those are 
>>> invoked from the lldb command interpreter, but I have a feeling that 
>>> routing the output printed via `Debugger::PrintAsync` back to the command 
>>> interpreter would look pretty weird. It may make sense for the core logic 
>>> of this to live in the Debugger or the IOHandler(Stack) classes -- though I 
>>> am not exactly sure about that either as the Debugger and CommandIntepreter 
>>> classes are fairly tightly coupled. However, I think that would be 
>>> consistent with the long term goal of reimplementing the command 
>>> interpreter on top of the SB API (in which case the `Debugger` object 
>>> should not know anything about the command interpreter (but it would still 
>>> need to to "something" with the PrintAsync output).
>> This isn’t directly related to how much and how we should capture lldb 
>> session output, and maybe I’m misunderstanding your meaning, but I wasn’t 
>> expecting that moving the command interpreter to use SB API’s would mean the 
>> Debugger Object would know nothing about the Command interpreter.  It would 
>> know as much about the command interpreter as it does about the script 
>> interpreter, namely the Debugger holds these objects and is the one to hand 
>> them out.  For instance when the breakpoint has a bunch of commands in its 
>> command action, it would go to the debugger to evaluate those commands.  I 
>> think that’s the reasonable place from which to vend the command and script 
>> interpreters.  So it’s okay IMO for the Debugger to know a little bit about 
>> these entities.  It shouldn’t know anything about the command syntax, etc.  
>> But since it is still the vendor of these objects, it seems okay for it to 
>> have an affordance to be notified of command results.
>> 
> 
> Well, the way I was thinking about this the "Debugger" would not know
> anything about Command *or* script interpreters. It would just know how
> to "debug" -- offer a programming API without any sort of textual
> interaction with a human.
> 
> However, this may be just a naming issue. There obviously needs to be
> some object which ties all of these together the thing which "debugs"
> and the thing which interfaces this with the user -- and it's not
> unreasonable to call this thing "the Debugger".
> 
> Nevertheless I think having this separation between "core debugger
> functionality" and a "particular way of interacting with the user" can
> be very useful:
> - it can enable someone to write a fully gdb-compatible (or some other
> debugger emulation) CLI experience on top of the "debugger core". This
> CLI would not need anything from the lldb CLI, but it could make use of
> all the "core" functionality (targets, breakpoints, threads, etc.)
> - someone wanting to build a lean-and-mean debugger for some specialized
> task could just make use of the "core" debugger functionality without
> pulling in the entire CLI
> 
> I don't expect either of these things to happen in the near future (or
> at all), but I like that this design would enable that sort of thing.
> Additionally (and this is the reason why I said (lldb_private::)Debugger
> in my first comment) this organization would avoid some problematic
> circular dependencies: If lldb_private::Debugger knows about the
> "command interpreter" and the "command interpreter" uses the SB api,
> then which side of the SB boundary does the command interpreter lie? It
> can't be "inside" the API, because it needs to access it to drive the
> debugging. But it also cannot be "outside" of the SB API, because then
> lldb_private::Debugger could not know about it.
> 
> That's why I figured that lldb::SBDebugger could be the "one debugger to
> rule them all", and lldb_private::Debugger could be "demoted" to just
> the "core" debugging facilities.
> 
> But now we're getting way ahead of ourselves...


One of the things that is core functionality in the debugger is “when X 
happens, do Y”.  When I stop, do something, when I hit a breakpoint do 
something, when a new shared library is loaded (we don’t offer this affordance 
yet, but we should), etc…  Similarly the script interpreter side of lldb gets 
pretty involved in formatting data.  Both of these tasks require non-trivial 
managing.   I think it would be annoying for every debugger client to have to 
code that up themselves.  Some of that c

[Lldb-commits] [PATCH] D82477: [lldb-vscode] Add Support for Module Event

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Here is a makefile that does stripping:

llvm-project/lldb/test/API/lang/objc/objc-ivar-stripped/Makefile

Then when creating the target, use a.out.stripped:

  exe = self.getBuildArtifact("a.out.stripped")
  symbols = exe = self.getBuildArtifact("a.out")
  target = self.dbg.CreateTarget(exe)

Then after you get the modules, you can do:

  self.dbg.HandleCommand('target symbols add "%s"' % (symbols))

And that should trigger the symbols added notification and then you can fetch 
the modules again and verify that there is now a symbol file for 
"a.out.stripped".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82477



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

[Lldb-commits] [PATCH] D81001: [lldb] Display autosuggestion part in gray if there is one possible suggestion

[Shu Anzai via Phabricator via lldb-commits]

gedatsu217 marked an inline comment as done.
gedatsu217 added inline comments.



Comment at: lldb/source/Host/common/Editline.cpp:1017
+  el_insertstr(m_editline, to_add.c_str());
+  return CC_REFRESH;
+}

teemperor wrote:
> If I understand the only effect this whole code has is to return CC_REFRESH 
> instead of CC_REDISPLAY? If yes, then I think you can just replace the 
> `break` below with `return CC_REFRESH;` which will be much simpler.
> If yes, then I think you can just replace the break below with return 
> CC_REFRESH; which will be much simpler.

Isn't it "return CC_REDISPLAY", not "CC_REFRESH"? I want to return CC_REFRESH 
only when "to_add" is in "to_add_autosuggestion" (e.g. to_add = b, 
to_add_autosuggestion = "breakpoint").  

That is because CC_REDISPLAY deletes the gray-colored autosuggested part, while 
CC_REFRESH leaves it.




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

https://reviews.llvm.org/D81001



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

[Lldb-commits] [lldb] 11f2ef4 - [lldb/ScriptInterpreter] Fix missing include on Windows

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T12:19:04-07:00
New Revision: 11f2ef4d9e78fd51cc9813d4ff0d8913c4ae70e1

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

LOG: [lldb/ScriptInterpreter] Fix missing include on Windows

Added: 


Modified: 
lldb/source/Interpreter/ScriptInterpreter.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/ScriptInterpreter.cpp 
b/lldb/source/Interpreter/ScriptInterpreter.cpp
index 967c22819313..86620449f2f4 100644
--- a/lldb/source/Interpreter/ScriptInterpreter.cpp
+++ b/lldb/source/Interpreter/ScriptInterpreter.cpp
@@ -7,12 +7,6 @@
 
//===--===//
 
 #include "lldb/Interpreter/ScriptInterpreter.h"
-
-#include 
-#include 
-#include 
-#include 
-
 #include "lldb/Core/Debugger.h"
 #include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/Pipe.h"
@@ -21,6 +15,13 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/StringList.h"
+#if defined(_WIN32)
+#include "lldb/Host/windows/ConnectionGenericFileWindows.h"
+#endif
+#include 
+#include 
+#include 
+#include 
 
 using namespace lldb;
 using namespace lldb_private;

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index d7f2fc659cf6..9f56b4fa60a5 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -16,7 +16,6 @@
 #include "PythonDataObjects.h"
 #include "PythonReadline.h"
 #include "ScriptInterpreterPythonImpl.h"
-
 #include "lldb/API/SBFrame.h"
 #include "lldb/API/SBValue.h"
 #include "lldb/Breakpoint/StoppointCallbackContext.h"
@@ -26,7 +25,6 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/ValueObject.h"
 #include "lldb/DataFormatters/TypeSummary.h"
-#include "lldb/Host/ConnectionFileDescriptor.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/Pipe.h"
@@ -35,11 +33,6 @@
 #include "lldb/Target/Thread.h"
 #include "lldb/Target/ThreadPlan.h"
 #include "lldb/Utility/Timer.h"
-
-#if defined(_WIN32)
-#include "lldb/Host/windows/ConnectionGenericFileWindows.h"
-#endif
-
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Error.h"



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

[Lldb-commits] [lldb] d358ec4 - [lldb/test] Skip TestBreakpointThumbCodesection on arm64.

[Davide Italiano via lldb-commits]

Author: Davide Italiano
Date: 2020-06-25T16:20:27-07:00
New Revision: d358ec463943878936080064d1c43afd8798aaf0

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

LOG: [lldb/test] Skip TestBreakpointThumbCodesection on arm64.

This test relies on thumb, which is a 32-bits feature only.

Added: 


Modified: 

lldb/test/API/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py

Removed: 




diff  --git 
a/lldb/test/API/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py
 
b/lldb/test/API/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py
index 0726369b6765..d472b79fb87a 100644
--- 
a/lldb/test/API/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py
+++ 
b/lldb/test/API/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py
@@ -15,6 +15,7 @@ class TestBreakpointThumbCodesection(TestBase):
 mydir = TestBase.compute_mydir(__file__)
 
 @skipIf(archs=no_match(["arm"]))
+@skipIf(archs=["arm64"])
 @skipIfDarwinEmbedded   # codegen on darwin always defaults to thumb for 
armv7/armv7k targets
 def test_breakpoint(self):
 self.build()



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

[Lldb-commits] [lldb] 0df7be2 - [lldb/test] XFAIL TestHWBreakMultiThread on arch rather platform.

[Davide Italiano via lldb-commits]

Author: Davide Italiano
Date: 2020-06-25T16:21:23-07:00
New Revision: 0df7be234412e60fbbaaf8c181fe2dfb3a2c1cc3

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

LOG: [lldb/test] XFAIL TestHWBreakMultiThread on arch rather platform.

Added: 


Modified: 

lldb/test/API/functionalities/breakpoint/hardware_breakpoints/hardware_breakpoint_on_multiple_threads/TestHWBreakMultiThread.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/hardware_breakpoint_on_multiple_threads/TestHWBreakMultiThread.py
 
b/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/hardware_breakpoint_on_multiple_threads/TestHWBreakMultiThread.py
index a4a1d9effbe1..bca7b278631f 100644
--- 
a/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/hardware_breakpoint_on_multiple_threads/TestHWBreakMultiThread.py
+++ 
b/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/hardware_breakpoint_on_multiple_threads/TestHWBreakMultiThread.py
@@ -36,7 +36,7 @@ def test_hw_break_set_disable_multi_thread_linux(self):
 # architectures.
 @skipUnlessDarwin
 @skipIfOutOfTreeDebugserver
-@skipIfDarwinEmbedded
+@expectedFailureAll(archs=["arm64"])
 def test_hw_break_set_delete_multi_thread_macos(self):
 self.build()
 self.setTearDownCleanup()
@@ -46,7 +46,7 @@ def test_hw_break_set_delete_multi_thread_macos(self):
 # architectures.
 @skipUnlessDarwin
 @skipIfOutOfTreeDebugserver
-@skipIfDarwinEmbedded
+@expectedFailureAll(archs=["arm64"])
 def test_hw_break_set_disable_multi_thread_macos(self):
 self.build()
 self.setTearDownCleanup()



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

[Lldb-commits] [lldb] 38135b2 - [test] XFail TestSigtrampUnwind based on arch rather than OS

[Davide Italiano via lldb-commits]

Author: Davide Italiano
Date: 2020-06-25T16:22:52-07:00
New Revision: 38135b2a7fff008093c0ca020855373f33ec9b12

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

LOG: [test] XFail TestSigtrampUnwind based on arch rather than OS

Added: 


Modified: 
lldb/test/API/functionalities/unwind/sigtramp/TestSigtrampUnwind.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/unwind/sigtramp/TestSigtrampUnwind.py 
b/lldb/test/API/functionalities/unwind/sigtramp/TestSigtrampUnwind.py
index bf19cacac06d..3ee86f786133 100644
--- a/lldb/test/API/functionalities/unwind/sigtramp/TestSigtrampUnwind.py
+++ b/lldb/test/API/functionalities/unwind/sigtramp/TestSigtrampUnwind.py
@@ -17,7 +17,7 @@ class SigtrampUnwind(TestBase):
 # On 
diff erent platforms the "_sigtramp" and "__kill" frames are likely to be 
diff erent.
 # This test could probably be adapted to run on linux/*bsd easily enough.
 @skipUnlessDarwin
-@expectedFailureAll(oslist=["ios", "watchos", "tvos", "bridgeos"], 
bugnumber="")  # lldb skips 1 frame on arm64 above 
_sigtramp
+@expectedFailureAll(archs=["arm64"], 
bugnumber="")  # lldb skips 1 frame on arm64 above 
_sigtramp
 def test(self):
 """Test that we can backtrace correctly with _sigtramp on the stack"""
 self.build()



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

[Lldb-commits] [lldb] c7eb06a - [test] XFail TestStepNoDebug based on arch rather than OS

[Davide Italiano via lldb-commits]

Author: Davide Italiano
Date: 2020-06-25T16:23:59-07:00
New Revision: c7eb06a880522867e7df3f025056f6c5b10d0eca

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

LOG: [test] XFail TestStepNoDebug based on arch rather than OS

Added: 


Modified: 
lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py 
b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
index e166848f853f..92036b2f215a 100644
--- a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
+++ b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
@@ -48,7 +48,7 @@ def test_step_over_with_python(self):
 "3.9"],
 archs=["i386"],
 bugnumber="llvm.org/pr28549")
-@expectedFailureAll(oslist=["ios", "tvos", "bridgeos"], 
bugnumber="")  # lldb doesn't step past last source 
line in function on arm64
+@expectedFailureAll(archs=["arm64"], 
bugnumber="")  # lldb doesn't step past last source 
line in function on arm64
 @expectedFailureAll(archs=["aarch64"], oslist=["linux"],
 bugnumber="llvm.org/pr44057")
 def test_step_in_with_python(self):



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

[Lldb-commits] [lldb] f441313 - [lldb/ScriptInterpreter] Fix Windows error C2371: 'pid_t': redefinition

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-06-25T17:15:29-07:00
New Revision: f441313464b2eef94a41c60bfde31a2bf9c602d7

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

LOG: [lldb/ScriptInterpreter] Fix Windows error C2371: 'pid_t': redefinition

pyconfig.h(194): error C2371: 'pid_t': redefinition; different basic types
PosixApi.h(82): note: see declaration of 'pid_t'

Added: 


Modified: 
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Removed: 




diff  --git a/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp 
b/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
index 78234612500b..f661835d191b 100644
--- a/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
+++ b/lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
@@ -8,9 +8,10 @@
 
 #include "gtest/gtest.h"
 
+#include "Plugins/ScriptInterpreter/Python/lldb-python.h"
+
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h"
-#include "Plugins/ScriptInterpreter/Python/lldb-python.h"
 #include "lldb/Host/FileSystem.h"
 #include "lldb/Host/HostInfo.h"
 



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

[Lldb-commits] [PATCH] D82559: [LLDB][Clang Integration][NFC] Remove redundant condition

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik accepted this revision.
shafik 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/D82559/new/

https://reviews.llvm.org/D82559



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

[Lldb-commits] [PATCH] D82616: Improve the detection of iOS/tvOS/watchOS simulator binaries in debugserver and lldb

[Adrian Prantl via Phabricator via lldb-commits]

aprantl created this revision.
aprantl added reviewers: jasonmolenda, friss, davide.

This patch improves the heuristics for correctly identifying simulator binaries 
on Darwin and adds support for simulators running on Apple Silicon.

rdar://problem/64046344


https://reviews.llvm.org/D82616

Files:
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  lldb/test/API/macosx/simulator/Makefile
  lldb/test/API/macosx/simulator/TestSimulatorPlatform.py
  lldb/tools/debugserver/source/DNB.cpp
  lldb/tools/debugserver/source/MacOSX/MachProcess.h
  lldb/tools/debugserver/source/MacOSX/MachProcess.mm

Index: lldb/tools/debugserver/source/MacOSX/MachProcess.mm
===
--- lldb/tools/debugserver/source/MacOSX/MachProcess.mm
+++ lldb/tools/debugserver/source/MacOSX/MachProcess.mm
@@ -601,88 +601,78 @@
   plo_pthread_tsd_entry_size);
 }
 
-/// Determine whether this is running on macOS.
-/// Since debugserver runs on the same machine as the process, we can
-/// just look at the compilation target.
-static bool IsMacOSHost() {
-#if TARGET_OS_OSX == 1
-  return true;
-#else
-  return false;
-#endif
-}
-
-const char *MachProcess::GetDeploymentInfo(const struct load_command& lc,
-   uint64_t load_command_address,
-   uint32_t& major_version,
-   uint32_t& minor_version,
-   uint32_t& patch_version) {
+MachProcess::DeploymentInfo
+MachProcess::GetDeploymentInfo(const struct load_command &lc,
+   uint64_t load_command_address) {
+  DeploymentInfo info;
   uint32_t cmd = lc.cmd & ~LC_REQ_DYLD;
-  bool lc_cmd_known =
-cmd == LC_VERSION_MIN_IPHONEOS || cmd == LC_VERSION_MIN_MACOSX ||
-cmd == LC_VERSION_MIN_TVOS || cmd == LC_VERSION_MIN_WATCHOS;
-
-  if (lc_cmd_known) {
+  // Handle the older LC_VERSION load commands, which don't
+  // distinguish between simulator and real hardware.
+  auto handle_version_min = [&](char platform) {
 struct version_min_command vers_cmd;
 if (ReadMemory(load_command_address, sizeof(struct version_min_command),
-   &vers_cmd) != sizeof(struct version_min_command)) {
-  return nullptr;
-}
-major_version = vers_cmd.sdk >> 16;
-minor_version = (vers_cmd.sdk >> 8) & 0xffu;
-patch_version = vers_cmd.sdk & 0xffu;
-
-// Handle the older LC_VERSION load commands, which don't
-// distinguish between simulator and real hardware.
-switch (cmd) {
-case LC_VERSION_MIN_IPHONEOS:
-  return IsMacOSHost() ? "iossimulator": "ios";
-case LC_VERSION_MIN_MACOSX:
-  return "macosx";
-case LC_VERSION_MIN_TVOS:
-  return IsMacOSHost() ? "tvossimulator": "tvos";
-case LC_VERSION_MIN_WATCHOS:
-  return IsMacOSHost() ? "watchossimulator" : "watchos";
-default:
-  return nullptr;
-}
-  }
-#if defined (LC_BUILD_VERSION)
-  if (cmd == LC_BUILD_VERSION) {
+   &vers_cmd) != sizeof(struct version_min_command))
+  return;
+info.platform = platform;
+info.major_version = vers_cmd.sdk >> 16;
+info.minor_version = (vers_cmd.sdk >> 8) & 0xffu;
+info.patch_version = vers_cmd.sdk & 0xffu;
+info.maybe_simulator = true;
+  };
+  switch (cmd) {
+  case LC_VERSION_MIN_IPHONEOS:
+handle_version_min(PLATFORM_IOS);
+break;
+  case LC_VERSION_MIN_MACOSX:
+handle_version_min(PLATFORM_MACOS);
+break;
+  case LC_VERSION_MIN_TVOS:
+handle_version_min(PLATFORM_TVOS);
+break;
+  case LC_VERSION_MIN_WATCHOS:
+handle_version_min(PLATFORM_WATCHOS);
+break;
+#if defined(LC_BUILD_VERSION)
+  case LC_BUILD_VERSION: {
 struct build_version_command build_vers;
 if (ReadMemory(load_command_address, sizeof(struct build_version_command),
-   &build_vers) != sizeof(struct build_version_command)) {
-  return nullptr;
-}
-major_version = build_vers.sdk >> 16;;
-minor_version = (build_vers.sdk >> 8) & 0xffu;
-patch_version = build_vers.sdk & 0xffu;
-
-switch (build_vers.platform) {
-case PLATFORM_MACOS:
-  return "macosx";
-case PLATFORM_MACCATALYST:
-  return "maccatalyst";
-case PLATFORM_IOS:
-  return "ios";
-case PLATFORM_IOSSIMULATOR:
-  return "iossimulator";
-case PLATFORM_TVOS:
-  return "tvos";
-case PLATFORM_TVOSSIMULATOR:
-  return "tvossimulator";
-case PLATFORM_WATCHOS:
-  return "watchos";
-case PLATFORM_WATCHOSSIMULATOR:
-  return "watchossimulator";
-case PLATFORM_BRIDGEOS:
-  return "bridgeos";
-case PLATFORM_DRIVERKIT:
-  return "driverkit";
-}
+   &build_vers) != sizeof(struct build_version_command))
+  break;
+info.platform = build_vers.platform;
+info.major_version = build_vers.sdk >> 16;
+info.minor_version = (build_vers.sdk >> 8) & 0xff

[Lldb-commits] [PATCH] D82622: [DWARFYAML][debug_info] Replace 'InitialLength' with 'Format' and 'Length'.

[Xing GUO via Phabricator via lldb-commits]

Higuoxing created this revision.
Higuoxing added reviewers: jhenderson, grimar, MaskRay.
Herald added subscribers: llvm-commits, lldb-commits, cmtice, hiraditya, 
aprantl, emaste.
Herald added a reviewer: espindola.
Herald added a reviewer: alexshap.
Herald added a reviewer: rupprecht.
Herald added projects: LLDB, LLVM.
Higuoxing added a parent revision: D82621: [DWARFYAML][debug_info] Teach 
yaml2obj emit correct DWARF64 unit header..
Higuoxing edited the summary of this revision.

'InitialLength' is replaced with 'Format' (DWARF32 by default) and 'Length' in 
this patch.
Besides, test cases for DWARFv4 and DWARFv5, DWARF32 and DWARF64 is
added.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D82622

Files:
  lldb/test/API/functionalities/source-map/a.yaml
  lldb/unittests/Expression/DWARFExpressionTest.cpp
  lldb/unittests/Symbol/Inputs/inlined-functions.yaml
  lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
  llvm/include/llvm/ObjectYAML/DWARFYAML.h
  llvm/lib/ObjectYAML/DWARFEmitter.cpp
  llvm/lib/ObjectYAML/DWARFVisitor.cpp
  llvm/lib/ObjectYAML/DWARFYAML.cpp
  llvm/test/ObjectYAML/MachO/DWARF-debug_info.yaml
  llvm/test/ObjectYAML/MachO/DWARF-debug_line.yaml
  llvm/test/ObjectYAML/MachO/DWARF-debug_ranges.yaml
  llvm/test/ObjectYAML/MachO/DWARF2-AddrSize8-FormValues.yaml
  llvm/test/ObjectYAML/MachO/DWARF5-debug_info.yaml
  llvm/test/tools/llvm-dwarfdump/X86/verify_overlapping_cu_ranges.yaml
  llvm/test/tools/llvm-gsymutil/ARM_AArch64/fat-macho-dwarf.yaml
  llvm/test/tools/llvm-gsymutil/X86/mach-dwarf.yaml
  llvm/test/tools/llvm-objcopy/MachO/Inputs/strip-all-with-dwarf.yaml
  llvm/test/tools/yaml2obj/ELF/DWARF/debug-info.yaml
  llvm/tools/obj2yaml/dwarf2yaml.cpp
  llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
  llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
  llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp

Index: llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
===
--- llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
+++ llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
@@ -1437,8 +1437,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 52
+- Length:  52
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1517,8 +1516,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 44
+- Length:  44
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1617,8 +1615,7 @@
 - Attribute:   DW_AT_artificial
   Form:DW_FORM_flag_present
   debug_info:
-- Length:
-TotalLength: 68
+- Length:  68
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1722,8 +1719,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 78
+- Length:  78
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1836,8 +1832,7 @@
 - Attribute:   DW_AT_call_line
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 74
+- Length:  74
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -2092,8 +2087,7 @@
 - Attribute:   DW_AT_decl_line
   Form:DW_FORM_data1
   debug_info:
-- Length:
-TotalLength: 103
+- Length:  103
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -2299,7 +2293,6 @@
   //
   // 0x004e:   NULL
 
-
   StringRef yamldata = R"(
   debug_str:
 - ''
@@ -2342,8 +2335,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 75
+- Length:  75
   Version: 4
   AbbrOffset:  0
   AddrSize:4
@@ -2485,8 +2477,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 103
+- Length:  103
   Version: 4
   AbbrOffset:  0
   AddrSize:8
Index: llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
+++ llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
@@ -34,8 +34,7 @@
   - Attribute:   DW_AT_call_data_location
 Form:DW_FORM_sec_offset
 debug_info:
-  - Length:
-  TotalLength: 0
+  - Length:  0
 Version: 5
 UnitType:DW_UT_compile
 AbbrOffset:  0
Index: llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp

[Lldb-commits] [PATCH] D82622: [DWARFYAML][debug_info] Replace 'InitialLength' with 'Format' and 'Length'.

[Xing GUO via Phabricator via lldb-commits]

Higuoxing updated this revision to Diff 273584.
Higuoxing added a comment.

Prettify test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82622

Files:
  lldb/test/API/functionalities/source-map/a.yaml
  lldb/unittests/Expression/DWARFExpressionTest.cpp
  lldb/unittests/Symbol/Inputs/inlined-functions.yaml
  lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
  llvm/include/llvm/ObjectYAML/DWARFYAML.h
  llvm/lib/ObjectYAML/DWARFEmitter.cpp
  llvm/lib/ObjectYAML/DWARFVisitor.cpp
  llvm/lib/ObjectYAML/DWARFYAML.cpp
  llvm/test/ObjectYAML/MachO/DWARF-debug_info.yaml
  llvm/test/ObjectYAML/MachO/DWARF-debug_line.yaml
  llvm/test/ObjectYAML/MachO/DWARF-debug_ranges.yaml
  llvm/test/ObjectYAML/MachO/DWARF2-AddrSize8-FormValues.yaml
  llvm/test/ObjectYAML/MachO/DWARF5-debug_info.yaml
  llvm/test/tools/llvm-dwarfdump/X86/verify_overlapping_cu_ranges.yaml
  llvm/test/tools/llvm-gsymutil/ARM_AArch64/fat-macho-dwarf.yaml
  llvm/test/tools/llvm-gsymutil/X86/mach-dwarf.yaml
  llvm/test/tools/llvm-objcopy/MachO/Inputs/strip-all-with-dwarf.yaml
  llvm/test/tools/yaml2obj/ELF/DWARF/debug-info.yaml
  llvm/tools/obj2yaml/dwarf2yaml.cpp
  llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
  llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
  llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp

Index: llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
===
--- llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
+++ llvm/unittests/DebugInfo/GSYM/GSYMTest.cpp
@@ -1437,8 +1437,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 52
+- Length:  52
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1517,8 +1516,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 44
+- Length:  44
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1617,8 +1615,7 @@
 - Attribute:   DW_AT_artificial
   Form:DW_FORM_flag_present
   debug_info:
-- Length:
-TotalLength: 68
+- Length:  68
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1722,8 +1719,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 78
+- Length:  78
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -1836,8 +1832,7 @@
 - Attribute:   DW_AT_call_line
   Form:DW_FORM_data4
   debug_info:
-- Length:
-TotalLength: 74
+- Length:  74
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -2092,8 +2087,7 @@
 - Attribute:   DW_AT_decl_line
   Form:DW_FORM_data1
   debug_info:
-- Length:
-TotalLength: 103
+- Length:  103
   Version: 4
   AbbrOffset:  0
   AddrSize:8
@@ -2342,8 +2336,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 75
+- Length:  75
   Version: 4
   AbbrOffset:  0
   AddrSize:4
@@ -2485,8 +2478,7 @@
 - Attribute:   DW_AT_high_pc
   Form:DW_FORM_addr
   debug_info:
-- Length:
-TotalLength: 103
+- Length:  103
   Version: 4
   AbbrOffset:  0
   AddrSize:8
Index: llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
+++ llvm/unittests/DebugInfo/DWARF/DWARFDieTest.cpp
@@ -34,8 +34,7 @@
   - Attribute:   DW_AT_call_data_location
 Form:DW_FORM_sec_offset
 debug_info:
-  - Length:
-  TotalLength: 0
+  - Length:  0
 Version: 5
 UnitType:DW_UT_compile
 AbbrOffset:  0
Index: llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
+++ llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
@@ -1368,8 +1368,7 @@
  "Children:DW_CHILDREN_yes\n"
  "Attributes:\n"
  "debug_info:\n"
- "  - Length:\n"
- "  TotalLength:  0\n"
+ "  - Length:  0\n"
  "Version: 4\n"
  "AbbrOffset:  0\n"