[Lldb-commits] [lldb] r347962 - [PDB] Support PDB-backed expressions evaluation

[Aleksandr Urakov via lldb-commits]

Author: aleksandr.urakov
Date: Thu Nov 29 23:12:22 2018
New Revision: 347962

URL: http://llvm.org/viewvc/llvm-project?rev=347962=rev
Log:
[PDB] Support PDB-backed expressions evaluation

Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
  value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
  evaluation crash;
- create parameter declarations for functions in AST to make it possible to call
  debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
  it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.

Reviewers: zturner, asmith, stella.stamenova

Reviewed By: stella.stamenova, asmith

Tags: #lldb

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

Added:
lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp
lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script
lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script
lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script
lldb/trunk/lit/SymbolFile/PDB/expressions.test
Modified:
lldb/trunk/source/Expression/IRExecutionUnit.cpp
lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.h
lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp

Added: lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp?rev=347962=auto
==
--- lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp (added)
+++ lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp Thu Nov 29 
23:12:22 2018
@@ -0,0 +1,20 @@
+namespace N0 {
+namespace N1 {
+
+char *buf0 = nullptr;
+char buf1[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+char sum(char *buf, int size) {
+  char result = 0;
+  for (int i = 0; i < size; i++)
+result += buf[i];
+  return result;
+}
+
+} // namespace N1
+} // namespace N0
+
+int main() {
+  char result = N0::N1::sum(N0::N1::buf1, sizeof(N0::N1::buf1));
+  return 0;
+}

Added: lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script?rev=347962=auto
==
--- lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script (added)
+++ lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script Thu Nov 29 
23:12:22 2018
@@ -0,0 +1,7 @@
+breakpoint set --file ExpressionsTest.cpp --line 19
+run
+print result
+print N0::N1::sum(N0::N1::buf1, sizeof(N0::N1::buf1))
+print N1::sum(N1::buf1, sizeof(N1::buf1))
+print sum(buf1, sizeof(buf1))
+print sum(buf1, 10)

Added: lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script?rev=347962=auto
==
--- lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script (added)
+++ lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script Thu Nov 29 
23:12:22 2018
@@ -0,0 +1 @@
+print sum(buf0, 1)

Added: lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script?rev=347962=auto
==
--- lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script (added)
+++ lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script Thu Nov 29 
23:12:22 2018
@@ -0,0 +1,2 @@
+print sum(buf0, result - 28)
+print sum(buf1 + 3, 3)

Added: lldb/trunk/lit/SymbolFile/PDB/expressions.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/expressions.test?rev=347962=auto
==
--- lldb/trunk/lit/SymbolFile/PDB/expressions.test (added)
+++ lldb/trunk/lit/SymbolFile/PDB/expressions.test Thu Nov 29 23:12:22 2018
@@ -0,0 +1,36 @@
+REQUIRES: system-windows, msvc
+RUN: %msvc_cl /Zi /GS- /c %S/Inputs/ExpressionsTest.cpp /Fo%t.obj
+RUN: %msvc_link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe
+RUN: %lldb -b -s 

[Lldb-commits] [PATCH] D53759: [PDB] Support PDB-backed expressions evaluation

[Aleksandr Urakov via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
aleksandr.urakov marked an inline comment as done.
Closed by commit rL347962: [PDB] Support PDB-backed expressions evaluation 
(authored by aleksandr.urakov, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53759?vs=175634=176042#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D53759

Files:
  lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest.cpp
  lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest0.script
  lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest1.script
  lldb/trunk/lit/SymbolFile/PDB/Inputs/ExpressionsTest2.script
  lldb/trunk/lit/SymbolFile/PDB/expressions.test
  lldb/trunk/source/Expression/IRExecutionUnit.cpp
  lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
  lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.h
  lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp

Index: lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.cpp
===
--- lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.cpp
+++ lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.cpp
@@ -42,7 +42,7 @@
 lldb::DataBufferSP _sp) {
   if (!CacheAllRegisterValues())
 return false;
-  if (data_sp->GetByteSize() < sizeof(m_context)) {
+  if (!data_sp || data_sp->GetByteSize() < sizeof(m_context)) {
 data_sp.reset(new DataBufferHeap(sizeof(CONTEXT), 0));
   }
   memcpy(data_sp->GetBytes(), _context, sizeof(m_context));
Index: lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
===
--- lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
+++ lldb/trunk/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
@@ -957,8 +957,9 @@
   }
 
   if (!first_chance) {
-// Any second chance exception is an application crash by definition.
-SetPrivateState(eStateCrashed);
+// Not any second chance exception is an application crash by definition.
+// It may be an expression evaluation crash.
+SetPrivateState(eStateStopped);
   }
 
   ExceptionResult result = ExceptionResult::SendToApplication;
Index: lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -817,12 +817,12 @@
 return m_entry_point_address;
 
   SectionList *section_list = GetSectionList();
-  addr_t offset = m_coff_header_opt.entry;
+  addr_t file_addr = m_coff_header_opt.entry + m_coff_header_opt.image_base;
 
   if (!section_list)
-m_entry_point_address.SetOffset(offset);
+m_entry_point_address.SetOffset(file_addr);
   else
-m_entry_point_address.ResolveAddressUsingFileSections(offset, section_list);
+m_entry_point_address.ResolveAddressUsingFileSections(file_addr, section_list);
   return m_entry_point_address;
 }
 
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -286,6 +286,10 @@
 const PDBSymbolFunc _func, const lldb_private::SymbolContext ) {
   lldbassert(sc.comp_unit && sc.module_sp.get());
 
+  if (FunctionSP result =
+  sc.comp_unit->FindFunctionByUID(pdb_func.getSymIndexId()))
+return result.get();
+
   auto file_vm_addr = pdb_func.getVirtualAddress();
   if (file_vm_addr == LLDB_INVALID_ADDRESS || file_vm_addr == 0)
 return nullptr;
@@ -1047,8 +1051,6 @@
 const lldb_private::ConstString ,
 const lldb_private::CompilerDeclContext *parent_decl_ctx,
 uint32_t max_matches, lldb_private::VariableList ) {
-  if (!parent_decl_ctx)
-parent_decl_ctx = m_tu_decl_ctx_up.get();
   if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
 return 0;
   if (name.IsEmpty())
@@ -1078,9 +1080,8 @@
 if (sc.comp_unit == nullptr)
   continue;
 
-auto actual_parent_decl_ctx =
-GetDeclContextContainingUID(result->getSymIndexId());
-if (actual_parent_decl_ctx != *parent_decl_ctx)
+if (parent_decl_ctx && GetDeclContextContainingUID(
+   result->getSymIndexId()) != *parent_decl_ctx)
   continue;
 
 ParseVariables(sc, *pdb_data, );
@@ -1269,20 +1270,28 @@
 CacheFunctionNames();
 
 std::set resolved_ids;
-auto ResolveFn = [include_inlines, , _list, 

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Aleksandr Urakov via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL347960: [Symbol] Search symbols with name and type in a 
symbol file (authored by aleksandr.urakov, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53368?vs=174916=176040#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D53368

Files:
  lldb/trunk/include/lldb/Symbol/SymbolFile.h
  lldb/trunk/include/lldb/Symbol/SymbolVendor.h
  lldb/trunk/source/Core/Address.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
  lldb/trunk/source/Symbol/SymbolVendor.cpp
  lldb/trunk/unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp

Index: lldb/trunk/source/Core/Address.cpp
===
--- lldb/trunk/source/Core/Address.cpp
+++ lldb/trunk/source/Core/Address.cpp
@@ -988,8 +988,10 @@
   if (module_sp) {
 ObjectFile *obj_file = module_sp->GetObjectFile();
 if (obj_file) {
-  // Give the symbol vendor a chance to add to the unified section list.
-  module_sp->GetSymbolVendor();
+  // Give the symbol vendor a chance to add to the unified section list
+  // and to symtab from symbol file
+  if (SymbolVendor *vendor = module_sp->GetSymbolVendor())
+vendor->GetSymtab();
   return obj_file->GetAddressClass(GetFileAddress());
 }
   }
Index: lldb/trunk/source/Symbol/SymbolVendor.cpp
===
--- lldb/trunk/source/Symbol/SymbolVendor.cpp
+++ lldb/trunk/source/Symbol/SymbolVendor.cpp
@@ -57,7 +57,7 @@
 //--
 SymbolVendor::SymbolVendor(const lldb::ModuleSP _sp)
 : ModuleChild(module_sp), m_type_list(), m_compile_units(),
-  m_sym_file_ap() {}
+  m_sym_file_ap(), m_symtab() {}
 
 //--
 // Destructor
@@ -434,14 +434,23 @@
 
 Symtab *SymbolVendor::GetSymtab() {
   ModuleSP module_sp(GetModule());
-  if (module_sp) {
-ObjectFile *objfile = module_sp->GetObjectFile();
-if (objfile) {
-  // Get symbol table from unified section list.
-  return objfile->GetSymtab();
-}
-  }
-  return nullptr;
+  if (!module_sp)
+return nullptr;
+
+  std::lock_guard guard(module_sp->GetMutex());
+
+  if (m_symtab)
+return m_symtab;
+
+  ObjectFile *objfile = module_sp->GetObjectFile();
+  if (!objfile)
+return nullptr;
+
+  m_symtab = objfile->GetSymtab();
+  if (m_symtab && m_sym_file_ap)
+m_sym_file_ap->AddSymbols(*m_symtab);
+
+  return m_symtab;
 }
 
 void SymbolVendor::ClearSymtab() {
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -1328,6 +1328,58 @@
 const std::string _qualified_name,
 std::vector _names) {}
 
+void SymbolFilePDB::AddSymbols(lldb_private::Symtab ) {
+  std::set sym_addresses;
+  for (size_t i = 0; i < symtab.GetNumSymbols(); i++)
+sym_addresses.insert(symtab.SymbolAtIndex(i)->GetFileAddress());
+
+  auto results = m_global_scope_up->findAllChildren();
+  if (!results)
+return;
+
+  auto section_list = m_obj_file->GetSectionList();
+  if (!section_list)
+return;
+
+  while (auto pub_symbol = results->getNext()) {
+auto section_idx = pub_symbol->getAddressSection() - 1;
+if (section_idx >= section_list->GetSize())
+  continue;
+
+auto section = section_list->GetSectionAtIndex(section_idx);
+if (!section)
+  continue;
+
+auto offset = pub_symbol->getAddressOffset();
+
+auto file_addr = section->GetFileAddress() + offset;
+if (sym_addresses.find(file_addr) != sym_addresses.end())
+  continue;
+sym_addresses.insert(file_addr);
+
+auto size = pub_symbol->getLength();
+symtab.AddSymbol(
+Symbol(pub_symbol->getSymIndexId(),   // symID
+   pub_symbol->getName().c_str(), // name
+   true,  // name_is_mangled
+   pub_symbol->isCode() ? eSymbolTypeCode : eSymbolTypeData, // type
+   true,  // external
+   false, // is_debug
+   false, // is_trampoline
+   false, // is_artificial
+   section,   // section_sp
+   offset,// value
+   size,  // size
+   size != 0, // size_is_valid
+   false, // contains_linker_annotations
+   0  // flags
+   ));
+  }
+
+  symtab.CalculateSymbolSizes();
+  symtab.Finalize();
+}
+
 uint32_t SymbolFilePDB::FindTypes(
 const lldb_private::SymbolContext ,
 const 

[Lldb-commits] [PATCH] D54617: [wip][Reproducers] Add file provider

[Jonas Devlieghere via Phabricator via lldb-commits]

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

- Get the external path with modifying the VFS in LLVM.
- Integrate with the new integration logic.
- Add a test. (that doesn't work yet, still WIP)


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

https://reviews.llvm.org/D54617

Files:
  include/lldb/Host/FileSystem.h
  include/lldb/Utility/FileCollector.h
  include/lldb/Utility/Reproducer.h
  lit/Reproducer/Inputs/FileCapture.in
  lit/Reproducer/Inputs/FileReplay.in
  lit/Reproducer/TestFileRepro.test
  lit/Reproducer/TestGDBRemoteRepro.test
  source/Host/common/FileSystem.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Utility/CMakeLists.txt
  source/Utility/FileCollector.cpp
  source/Utility/Reproducer.cpp

Index: source/Utility/Reproducer.cpp
===
--- source/Utility/Reproducer.cpp
+++ source/Utility/Reproducer.cpp
@@ -224,3 +224,4 @@
 
 void ProviderBase::anchor() {}
 char ProviderBase::ID = 0;
+char FileProvider::ID = 0;
Index: source/Utility/FileCollector.cpp
===
--- /dev/null
+++ source/Utility/FileCollector.cpp
@@ -0,0 +1,137 @@
+//===-- FileCollector.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Utility/FileCollector.h"
+
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+
+using namespace lldb_private;
+using namespace llvm;
+
+static bool IsCaseSensitivePath(StringRef path) {
+  SmallString<256> tmp_dest = path, upper_dest, real_dest;
+
+  // Remove component traversals, links, etc.
+  if (!sys::fs::real_path(path, tmp_dest))
+return true; // Current default value in vfs.yaml
+  path = tmp_dest;
+
+  // Change path to all upper case and ask for its real path, if the latter
+  // exists and is equal to path, it's not case sensitive. Default to case
+  // sensitive in the absence of real_path, since this is the YAMLVFSWriter
+  // default.
+  upper_dest = path.upper();
+  if (sys::fs::real_path(upper_dest, real_dest) && path.equals(real_dest))
+return false;
+  return true;
+}
+
+FileCollector::FileCollector(const FileSpec ) : m_root(directory) {
+  sys::fs::create_directories(m_root.GetPath(), true);
+}
+
+bool FileCollector::GetRealPath(StringRef src_path,
+SmallVectorImpl ) {
+  SmallString<256> real_path;
+  StringRef FileName = sys::path::filename(src_path);
+  std::string directory = sys::path::parent_path(src_path).str();
+  auto dir_with_symlink = m_symlink_map.find(directory);
+
+  // Use real_path to fix any symbolic link component present in a path.
+  // Computing the real path is expensive, cache the search through the
+  // parent path directory.
+  if (dir_with_symlink == m_symlink_map.end()) {
+if (!sys::fs::real_path(directory, real_path))
+  return false;
+m_symlink_map[directory] = real_path.str();
+  } else {
+real_path = dir_with_symlink->second;
+  }
+
+  sys::path::append(real_path, FileName);
+  result.swap(real_path);
+  return true;
+}
+
+void FileCollector::AddFile(const Twine ) {
+  std::lock_guard lock(m_mutex);
+  std::string file_str = file.str();
+  if (MarkAsSeen(file_str))
+AddFileImpl(file_str);
+}
+
+void FileCollector::AddFileImpl(StringRef src_path) {
+  std::string root = m_root.GetPath();
+
+  // We need an absolute src path to append to the root.
+  SmallString<256> absolute_src = src_path;
+  sys::fs::make_absolute(absolute_src);
+
+  // Canonicalize src to a native path to avoid mixed separator styles.
+  sys::path::native(absolute_src);
+
+  // Remove redundant leading "./" pieces and consecutive separators.
+  absolute_src = sys::path::remove_leading_dotslash(absolute_src);
+
+  // Canonicalize the source path by removing "..", "." components.
+  SmallString<256> virtual_path = absolute_src;
+  sys::path::remove_dots(virtual_path, /*remove_dot_dot=*/true);
+
+  // If a ".." component is present after a symlink component, remove_dots may
+  // lead to the wrong real destination path. Let the source be canonicalized
+  // like that but make sure we always use the real path for the destination.
+  SmallString<256> copy_from;
+  if (!GetRealPath(absolute_src, copy_from))
+copy_from = virtual_path;
+
+  SmallString<256> dst_path = StringRef(root);
+  sys::path::append(dst_path, sys::path::relative_path(copy_from));
+
+  // Always map a canonical src path to its real path into the YAML, by doing
+  // this we map different virtual src paths to the same entry in the VFS
+  // overlay, which is a way to emulate symlink inside the VFS; this is also
+  // 

[Lldb-commits] [PATCH] D55038: [Reproducers] Change how reproducers are initialized.

[Jonas Devlieghere via Phabricator via lldb-commits]

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

Test didn't run. Is there a way to REQUIRE either darwin or linux?


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

https://reviews.llvm.org/D55038

Files:
  include/lldb/API/SBDebugger.h
  include/lldb/API/SBDefines.h
  include/lldb/API/SBFileSpec.h
  include/lldb/API/SBInitializerOptions.h
  include/lldb/Core/Debugger.h
  include/lldb/Host/HostInfoBase.h
  include/lldb/Initialization/SystemInitializer.h
  include/lldb/Initialization/SystemInitializerCommon.h
  include/lldb/Initialization/SystemLifetimeManager.h
  include/lldb/Utility/Reproducer.h
  lit/Reproducer/Inputs/GDBRemoteCapture.in
  lit/Reproducer/Inputs/GDBRemoteReplay.in
  lit/Reproducer/Inputs/simple.c
  lit/Reproducer/TestGDBRemoteRepro.test
  packages/Python/lldbsuite/test/functionalities/reproducer/gdb-remote/Makefile
  
packages/Python/lldbsuite/test/functionalities/reproducer/gdb-remote/TestGdbRemoteReproducer.py
  scripts/interface/SBDebugger.i
  scripts/interface/SBInitializerOptions.i
  scripts/lldb.swig
  source/API/CMakeLists.txt
  source/API/SBDebugger.cpp
  source/API/SBInitializerOptions.cpp
  source/API/SystemInitializerFull.cpp
  source/API/SystemInitializerFull.h
  source/Commands/CommandObjectReproducer.cpp
  source/Core/Debugger.cpp
  source/Host/common/HostInfoBase.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Initialization/SystemLifetimeManager.cpp
  source/Utility/Reproducer.cpp
  tools/driver/Driver.cpp
  tools/driver/Options.td
  tools/lldb-server/SystemInitializerLLGS.cpp
  tools/lldb-server/SystemInitializerLLGS.h
  tools/lldb-server/lldb-server.cpp
  tools/lldb-test/SystemInitializerTest.cpp
  tools/lldb-test/SystemInitializerTest.h
  tools/lldb-test/lldb-test.cpp
  unittests/Utility/ReproducerTest.cpp

Index: unittests/Utility/ReproducerTest.cpp
===
--- unittests/Utility/ReproducerTest.cpp
+++ unittests/Utility/ReproducerTest.cpp
@@ -32,10 +32,18 @@
   static char ID;
 };
 
+class DummyReproducer : public Reproducer {
+public:
+  DummyReproducer() : Reproducer(){};
+
+  using Reproducer::SetCapture;
+  using Reproducer::SetReplay;
+};
+
 char DummyProvider::ID = 0;
 
 TEST(ReproducerTest, SetCapture) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   // Initially both generator and loader are unset.
   EXPECT_EQ(nullptr, reproducer.GetGenerator());
@@ -59,7 +67,7 @@
 }
 
 TEST(ReproducerTest, SetReplay) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   // Initially both generator and loader are unset.
   EXPECT_EQ(nullptr, reproducer.GetGenerator());
@@ -80,7 +88,7 @@
 }
 
 TEST(GeneratorTest, Create) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
@@ -95,7 +103,7 @@
 }
 
 TEST(GeneratorTest, Get) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
@@ -109,7 +117,7 @@
 }
 
 TEST(GeneratorTest, GetOrCreate) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -934,7 +934,7 @@
   cl::ParseCommandLineOptions(argc, argv, "LLDB Testing Utility\n");
 
   SystemLifetimeManager DebuggerLifetime;
-  DebuggerLifetime.Initialize(llvm::make_unique(),
+  DebuggerLifetime.Initialize(llvm::make_unique(), {},
   nullptr);
   CleanUp TerminateDebugger([&] { DebuggerLifetime.Terminate(); });
 
Index: tools/lldb-test/SystemInitializerTest.h
===
--- tools/lldb-test/SystemInitializerTest.h
+++ tools/lldb-test/SystemInitializerTest.h
@@ -26,7 +26,7 @@
   SystemInitializerTest();
   ~SystemInitializerTest() override;
 
-  void Initialize() override;
+  void Initialize(const InitializerOptions ) override;
   void Terminate() override;
 };
 
Index: tools/lldb-test/SystemInitializerTest.cpp
===
--- tools/lldb-test/SystemInitializerTest.cpp
+++ tools/lldb-test/SystemInitializerTest.cpp
@@ -111,8 +111,8 @@
 
 SystemInitializerTest::~SystemInitializerTest() {}
 
-void SystemInitializerTest::Initialize() {
-  SystemInitializerCommon::Initialize();
+void SystemInitializerTest::Initialize(const InitializerOptions ) {
+  SystemInitializerCommon::Initialize(options);
 
   ObjectFileELF::Initialize();
   ObjectFileMachO::Initialize();
Index: tools/lldb-server/lldb-server.cpp
===
--- tools/lldb-server/lldb-server.cpp

[Lldb-commits] [lldb] r347952 - Fix the Xcode project (pt. 2)

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu Nov 29 18:44:16 2018
New Revision: 347952

URL: http://llvm.org/viewvc/llvm-project?rev=347952=rev
Log:
Fix the Xcode project (pt. 2)

Apparently LLVM's libSupport depends on libDemangle to print the stack
trace. I'm not sure if this is desired but for now we don't have much
choice if we want to turn to bot green again.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=347952=347951=347952=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Nov 29 18:44:16 2018
@@ -9972,6 +9972,7 @@

"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
"-lLLVMOption",
"-lLLVMSupport",
+   "-lLLVMDemangle",
);
"OTHER_LDFLAGS[sdk=macosx*]" = (
"$(inherited)",
@@ -9981,6 +9982,7 @@

"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
"-lLLVMOption",
"-lLLVMSupport",
+   "-lLLVMDemangle",

"$(PROJECT_DIR)/tools/driver/lldb-Info.plist",

"-Wl,-rpath,@loader_path/../../Library/PrivateFrameworks",

"-Wl,-rpath,@loader_path/../../../SharedFrameworks",
@@ -10588,6 +10590,7 @@

"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
"-lLLVMOption",
"-lLLVMSupport",
+   "-lLLVMDemangle",
);
PRODUCT_NAME = lldb;
USER_HEADER_SEARCH_PATHS = "$(SRCROOT)/include 
$(SRCROOT)/source $(LLVM_SOURCE_DIR)/include 
$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/include ${LLDB_BUILD_DIR}/include";
@@ -10745,6 +10748,7 @@

"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
"-lLLVMOption",
"-lLLVMSupport",
+   "-lLLVMDemangle",
);
PRODUCT_NAME = lldb;
USER_HEADER_SEARCH_PATHS = "$(SRCROOT)/include 
$(SRCROOT)/source $(LLVM_SOURCE_DIR)/include 
$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/include";


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

[Lldb-commits] [PATCH] D55038: [Reproducers] Change how reproducers are initialized.

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 175993.
JDevlieghere marked 12 inline comments as done.
JDevlieghere added a comment.

Address feedback from Pavel.


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

https://reviews.llvm.org/D55038

Files:
  include/lldb/API/SBDebugger.h
  include/lldb/API/SBDefines.h
  include/lldb/API/SBFileSpec.h
  include/lldb/API/SBInitializerOptions.h
  include/lldb/Core/Debugger.h
  include/lldb/Host/HostInfoBase.h
  include/lldb/Initialization/SystemInitializer.h
  include/lldb/Initialization/SystemInitializerCommon.h
  include/lldb/Initialization/SystemLifetimeManager.h
  include/lldb/Utility/Reproducer.h
  lit/Reproducer/Inputs/GDBRemoteCapture.in
  lit/Reproducer/Inputs/GDBRemoteReplay.in
  lit/Reproducer/TestGDBRemoteRepro.test
  packages/Python/lldbsuite/test/functionalities/reproducer/gdb-remote/Makefile
  
packages/Python/lldbsuite/test/functionalities/reproducer/gdb-remote/TestGdbRemoteReproducer.py
  scripts/interface/SBDebugger.i
  scripts/interface/SBInitializerOptions.i
  scripts/lldb.swig
  source/API/CMakeLists.txt
  source/API/SBDebugger.cpp
  source/API/SBInitializerOptions.cpp
  source/API/SystemInitializerFull.cpp
  source/API/SystemInitializerFull.h
  source/Commands/CommandObjectReproducer.cpp
  source/Core/Debugger.cpp
  source/Host/common/HostInfoBase.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Initialization/SystemLifetimeManager.cpp
  source/Utility/Reproducer.cpp
  tools/driver/Driver.cpp
  tools/driver/Options.td
  tools/lldb-server/SystemInitializerLLGS.cpp
  tools/lldb-server/SystemInitializerLLGS.h
  tools/lldb-server/lldb-server.cpp
  tools/lldb-test/SystemInitializerTest.cpp
  tools/lldb-test/SystemInitializerTest.h
  tools/lldb-test/lldb-test.cpp
  unittests/Utility/ReproducerTest.cpp

Index: unittests/Utility/ReproducerTest.cpp
===
--- unittests/Utility/ReproducerTest.cpp
+++ unittests/Utility/ReproducerTest.cpp
@@ -32,10 +32,18 @@
   static char ID;
 };
 
+class DummyReproducer : public Reproducer {
+public:
+  DummyReproducer() : Reproducer(){};
+
+  using Reproducer::SetCapture;
+  using Reproducer::SetReplay;
+};
+
 char DummyProvider::ID = 0;
 
 TEST(ReproducerTest, SetCapture) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   // Initially both generator and loader are unset.
   EXPECT_EQ(nullptr, reproducer.GetGenerator());
@@ -59,7 +67,7 @@
 }
 
 TEST(ReproducerTest, SetReplay) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   // Initially both generator and loader are unset.
   EXPECT_EQ(nullptr, reproducer.GetGenerator());
@@ -80,7 +88,7 @@
 }
 
 TEST(GeneratorTest, Create) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
@@ -95,7 +103,7 @@
 }
 
 TEST(GeneratorTest, Get) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
@@ -109,7 +117,7 @@
 }
 
 TEST(GeneratorTest, GetOrCreate) {
-  Reproducer reproducer;
+  DummyReproducer reproducer;
 
   EXPECT_THAT_ERROR(reproducer.SetCapture(FileSpec("/bogus/path")),
 Succeeded());
Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -934,7 +934,7 @@
   cl::ParseCommandLineOptions(argc, argv, "LLDB Testing Utility\n");
 
   SystemLifetimeManager DebuggerLifetime;
-  DebuggerLifetime.Initialize(llvm::make_unique(),
+  DebuggerLifetime.Initialize(llvm::make_unique(), {},
   nullptr);
   CleanUp TerminateDebugger([&] { DebuggerLifetime.Terminate(); });
 
Index: tools/lldb-test/SystemInitializerTest.h
===
--- tools/lldb-test/SystemInitializerTest.h
+++ tools/lldb-test/SystemInitializerTest.h
@@ -26,7 +26,7 @@
   SystemInitializerTest();
   ~SystemInitializerTest() override;
 
-  void Initialize() override;
+  void Initialize(const InitializerOptions ) override;
   void Terminate() override;
 };
 
Index: tools/lldb-test/SystemInitializerTest.cpp
===
--- tools/lldb-test/SystemInitializerTest.cpp
+++ tools/lldb-test/SystemInitializerTest.cpp
@@ -111,8 +111,8 @@
 
 SystemInitializerTest::~SystemInitializerTest() {}
 
-void SystemInitializerTest::Initialize() {
-  SystemInitializerCommon::Initialize();
+void SystemInitializerTest::Initialize(const InitializerOptions ) {
+  SystemInitializerCommon::Initialize(options);
 
   ObjectFileELF::Initialize();
   ObjectFileMachO::Initialize();
Index: tools/lldb-server/lldb-server.cpp
===
--- tools/lldb-server/lldb-server.cpp
+++ 

[Lldb-commits] [PATCH] D55038: [Reproducers] Change how reproducers are initialized.

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: source/Utility/Reproducer.cpp:41-42
+Reproducer::Reproducer(ReproducerMode mode, llvm::Optional root) {
+  // It's unfortunate that we have to do so much I/O here that can fail. The
+  // best we can do is not initialize the reproducer.
+  switch (mode) {

labath wrote:
> It should be possible to bubble this all the way up to the 
> `SBDebugger::Initialize` call. Is there a reason to not do that?
Do you mean having the private Initialize function return an error (and an 
SBError for the SB variant)?



Comment at: tools/driver/CMakeLists.txt:21
 liblldb
+lldbUtility
 ${host_lib}

labath wrote:
> This is wrong. The driver should only  use the public API exposed via 
> liblldb. Why did you need to do that?
I don't remember, anyway it's definitely not necessary or correct. 


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

https://reviews.llvm.org/D55038



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

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Greg Clayton via lldb-commits]

> On Nov 29, 2018, at 3:31 PM, Zachary Turner  wrote:
> 
> Objects have a symbol table, but a Module is just a loaded object file. And a 
> loaded object file can have multiple symbol tables (from the object file, or 
> symbol file, etc).
> 
> Would it make sense to have Module provide a GetSymtab method that can find 
> all appropriate Symtabs and present a unified view?

That is exactly what currently happens. Module just lets the symbol vendor do 
the work of gathering all files (executable + dSYM for Mac, executable + 
external debug info file for ELF, etc). So yes, the goal is the module provides 
the view a user wants to see and uses the symbol vendor to help get that view.

Greg

> On Thu, Nov 29, 2018 at 2:39 PM Greg Clayton  > wrote:
> 
> 
> > On Nov 29, 2018, at 2:02 PM, Zachary Turner via Phabricator 
> > mailto:revi...@reviews.llvm.org>> wrote:
> > 
> > zturner added a comment.
> > 
> > In D53368#1313238  > >, @labath wrote:
> > 
> >> In D53368#1313145  >> >, @zturner wrote:
> >> 
> >>> In D53368#1313124  >>> >, @labath wrote:
> >>> 
>  I've recently started looking at adding a new symbol file format 
>  (breakpad symbols). While researching the best way to achieve that, I 
>  started comparing the operation of PDB and DWARF symbol files. I noticed 
>  a very important difference there, and I think that is the cause of our 
>  problems here. In the DWARF implementation, a symbol file is an overlay 
>  on top of an object file - it takes the data contained by the object 
>  file and presents it in a more structured way.
>  
>  However, that is not the case with PDB (both implementations). These 
>  take the debug information from a completely different file, which is 
>  not backed by an ObjectFile instance, and then present that. Since the 
>  SymbolFile interface requires them to be backed by an object file, they 
>  both pretend they are backed by the original EXE file, but in reality 
>  the data comes from elsewhere.
> >>> 
> >>> 
> >>> Don't DWARF DWP files work this way as well?  How is support for this 
> >>> implemented in LLDB?
> >> 
> >> 
> >> There are some similarities, but DWP is a bit different. The main 
> >> difference is that the DWP file is still an ELF (or whatever) file, so we 
> >> still have a ObjectFile sitting below the symbol file. The other 
> >> difference is that in case of DWP we still have a significant chunk of 
> >> debug information present in the main executable (mainly various offsets 
> >> that need to be applied to the unlinked debug info in the dwo/dwp files), 
> >> so you can still very well say that the symbol file is reading information 
> >> from the main executable. What DWARF does in this case is it creates a 
> >> main SymbolFileDWARF for reading data from the main object file, and then 
> >> a bunch of inner SymbolFileDWARFDwo/Dwp instances which read data from the 
> >> other files. There are plenty of things to not like here as well, but at 
> >> least this maintains the property that each symbol file sits on top of the 
> >> object file from which it reads the data from. (and symtab doesn't go into 
> >> the dwp file, so there are no issues with that).
> >> 
>  I am asking this because now I am facing a choice in how to implement 
>  breakpad symbols. I could go the PDB way, and read the symbols without 
>  an intervening object file, or I could create an ObjectFileBreakpad and 
>  then (possibly) a SymbolFileBreakpad sitting on top of that.
> >>> 
> >>> What if `SymbolFile` interface provided a new method such as 
> >>> `GetSymtab()` while `ObjectFile` provides a method called 
> >>> `HasExternalSymtab()`.  When you call `ObjectFilePECOFF::GetSymtab()`, it 
> >>> could first check if `HasExternalSymtab()` is true, and if so it could 
> >>> call the SymbolFile plugin and return that
> >> 
> >> I don't think this would be good because there's no way for the PECOFF 
> >> file to know if we will have a PDB file on top of it.
> > 
> > 
> > I'm actually starting to wonder even if `GetSymtab()` should be part of 
> > `ObjectFile`.  The first thing it does is get the Module and then start 
> > calling a bunch of stuff on the Module interface.  Perhaps the place to 
> > start is comparing the Module and ObjectFile interfaces and seeing if the 
> > existing APIs make the most sense being moved up to Module.  If everything 
> > was on Module then the Module has everything it needs to go to the 
> > SymbolVendor and find a PDB file.
> 
> I would vote against moving anything into the module. Object files have their 
> own symbol tables and we need the ability for an object file to be able to 
> find a symbol 

[Lldb-commits] [lldb] r347936 - Fix the Xcode project

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu Nov 29 16:09:04 2018
New Revision: 347936

URL: http://llvm.org/viewvc/llvm-project?rev=347936=rev
Log:
Fix the Xcode project

This fixes the driver with the Xcode project. We need to link the driver
against the correct LLVM libraries and make sure we're disabling
exceptions/rtti.

Thanks to Jim for helping me figure this out.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=347936=347935=347936=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Nov 29 16:09:04 2018
@@ -9926,6 +9926,7 @@
"$(LLDB_ZLIB_LDFLAGS)",
"$(LLDB_COVERAGE_LDFLAGS)",
);
+   "OTHER_LDFLAGS[sdk=macosx*]" = "";
PYTHON_FRAMEWORK_PATH = 
/System/Library/Frameworks/Python.framework/;
PYTHON_VERSION_MAJOR = 2;
PYTHON_VERSION_MINOR = 7;
@@ -9951,23 +9952,35 @@
INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
+   OTHER_CFLAGS = (
+   "-Wparentheses",
+   "$(LLDB_ZLIB_CFLAGS)",
+   "$(LLDB_COMPRESSION_CFLAGS)",
+   "$(LLDB_COVERAGE_CFLAGS)",
+   "-Wimplicit-fallthrough",
+   "-fno-rtti",
+   "-fno-exceptions",
+   "-DNDEBUG",
+   );
"OTHER_LDFLAGS[sdk=iphoneos*]" = (
"$(inherited)",
"-sectcreate",
__TEXT,
__info_plist,
-   "-filelist",
-   "$(LLVM_BUILD_DIR)/archives.txt",

"$(PROJECT_DIR)/tools/driver/lldb-Info.plist",

"-Wl,-rpath,@loader_path/../../../System/Library/PrivateFrameworks",
+   
"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
+   "-lLLVMOption",
+   "-lLLVMSupport",
);
"OTHER_LDFLAGS[sdk=macosx*]" = (
"$(inherited)",
"-sectcreate",
__TEXT,
__info_plist,
-   "-filelist",
-   "$(LLVM_BUILD_DIR)/archives.txt",
+   
"-L$(LLVM_BUILD_DIR)/$(LLVM_BUILD_DIR_ARCH)/lib",
+   "-lLLVMOption",
+   "-lLLVMSupport",

"$(PROJECT_DIR)/tools/driver/lldb-Info.plist",

"-Wl,-rpath,@loader_path/../../Library/PrivateFrameworks",

"-Wl,-rpath,@loader_path/../../../SharedFrameworks",
@@ -10515,6 +10528,15 @@
INFOPLIST_FILE = "tools/driver/lldb-Info.plist";
INSTALL_PATH = "$(LLDB_TOOLS_INSTALL_DIR)";
LIBRARY_SEARCH_PATHS = "$(inherited)";
+   OTHER_CFLAGS = (
+   "-Wparentheses",
+   "$(LLDB_ZLIB_CFLAGS)",
+   "$(LLDB_COMPRESSION_CFLAGS)",
+   "$(LLDB_COVERAGE_CFLAGS)",
+   "-Wimplicit-fallthrough",
+   "-fno-rtti",
+   "-fno-exceptions",
+   );
OTHER_LDFLAGS = (
"$(inherited)",
"-sectcreate",
@@ -10522,8 +10544,10 @@
__info_plist,

"$(PROJECT_DIR)/tools/driver/lldb-Info.plist",
"-Wl,-rpath,@loader_path",
-   

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Zachary Turner via lldb-commits]

Objects have a symbol table, but a Module is just a loaded object file. And
a loaded object file can have multiple symbol tables (from the object file,
or symbol file, etc).

Would it make sense to have Module provide a GetSymtab method that can find
all appropriate Symtabs and present a unified view?
On Thu, Nov 29, 2018 at 2:39 PM Greg Clayton  wrote:

>
>
> > On Nov 29, 2018, at 2:02 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > zturner added a comment.
> >
> > In D53368#1313238 , @labath
> wrote:
> >
> >> In D53368#1313145 , @zturner
> wrote:
> >>
> >>> In D53368#1313124 , @labath
> wrote:
> >>>
>  I've recently started looking at adding a new symbol file format
> (breakpad symbols). While researching the best way to achieve that, I
> started comparing the operation of PDB and DWARF symbol files. I noticed a
> very important difference there, and I think that is the cause of our
> problems here. In the DWARF implementation, a symbol file is an overlay on
> top of an object file - it takes the data contained by the object file and
> presents it in a more structured way.
> 
>  However, that is not the case with PDB (both implementations). These
> take the debug information from a completely different file, which is not
> backed by an ObjectFile instance, and then present that. Since the
> SymbolFile interface requires them to be backed by an object file, they
> both pretend they are backed by the original EXE file, but in reality the
> data comes from elsewhere.
> >>>
> >>>
> >>> Don't DWARF DWP files work this way as well?  How is support for this
> implemented in LLDB?
> >>
> >>
> >> There are some similarities, but DWP is a bit different. The main
> difference is that the DWP file is still an ELF (or whatever) file, so we
> still have a ObjectFile sitting below the symbol file. The other difference
> is that in case of DWP we still have a significant chunk of debug
> information present in the main executable (mainly various offsets that
> need to be applied to the unlinked debug info in the dwo/dwp files), so you
> can still very well say that the symbol file is reading information from
> the main executable. What DWARF does in this case is it creates a main
> SymbolFileDWARF for reading data from the main object file, and then a
> bunch of inner SymbolFileDWARFDwo/Dwp instances which read data from the
> other files. There are plenty of things to not like here as well, but at
> least this maintains the property that each symbol file sits on top of the
> object file from which it reads the data from. (and symtab doesn't go into
> the dwp file, so there are no issues with that).
> >>
>  I am asking this because now I am facing a choice in how to implement
> breakpad symbols. I could go the PDB way, and read the symbols without an
> intervening object file, or I could create an ObjectFileBreakpad and then
> (possibly) a SymbolFileBreakpad sitting on top of that.
> >>>
> >>> What if `SymbolFile` interface provided a new method such as
> `GetSymtab()` while `ObjectFile` provides a method called
> `HasExternalSymtab()`.  When you call `ObjectFilePECOFF::GetSymtab()`, it
> could first check if `HasExternalSymtab()` is true, and if so it could call
> the SymbolFile plugin and return that
> >>
> >> I don't think this would be good because there's no way for the PECOFF
> file to know if we will have a PDB file on top of it.
> >
> >
> > I'm actually starting to wonder even if `GetSymtab()` should be part of
> `ObjectFile`.  The first thing it does is get the Module and then start
> calling a bunch of stuff on the Module interface.  Perhaps the place to
> start is comparing the Module and ObjectFile interfaces and seeing if the
> existing APIs make the most sense being moved up to Module.  If everything
> was on Module then the Module has everything it needs to go to the
> SymbolVendor and find a PDB file.
>
> I would vote against moving anything into the module. Object files have
> their own symbol tables and we need the ability for an object file to be
> able to find a symbol that it created and we really don't want to abstract
> this away since at any time when we delve further into an object file we
> might need to dig up a symbol by its original symbol table index. So the
> cleanest design in my opinion is one where the object files can each have
> their own symbol table and the module uses the symbol vendor to get promote
> the best information up to the user. Symbols can come from one object file,
> or an external debug info object file, or from Breakpad. But each of those
> files should be able to have their own notion of their own symbols.
>
> Greg
>
> >
> >
> > CHANGES SINCE LAST ACTION
> >  https://reviews.llvm.org/D53368/new/
> >
> > https://reviews.llvm.org/D53368
> >
> >
> >
>
>
___

[Lldb-commits] [PATCH] D55084: [CMake] Add RPATHS parameter to llvm_add_executable/library

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz created this revision.
Herald added a subscriber: mgorny.

This allows to set target-specific LC_RPATH load commands on macOS. It would be 
useful to locate LLDB.framework in LLDB tools.


Repository:
  rL LLVM

https://reviews.llvm.org/D55084

Files:
  cmake/modules/AddLLVM.cmake


Index: cmake/modules/AddLLVM.cmake
===
--- cmake/modules/AddLLVM.cmake
+++ cmake/modules/AddLLVM.cmake
@@ -379,7 +379,7 @@
   cmake_parse_arguments(ARG
 "MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME"
 "OUTPUT_NAME;PLUGIN_TOOL"
-"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
+"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS;RPATHS"
 ${ARGN})
   list(APPEND LLVM_COMMON_DEPENDS ${ARG_DEPENDS})
   if(ARG_ADDITIONAL_HEADERS)
@@ -448,12 +448,12 @@
 
   if(ARG_MODULE)
 add_library(${name} MODULE ${ALL_FILES})
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
   elseif(ARG_SHARED)
 add_windows_version_resource_file(ALL_FILES ${ALL_FILES})
 add_library(${name} SHARED ${ALL_FILES})
 
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
 
   else()
 add_library(${name} STATIC ${ALL_FILES})
@@ -711,7 +711,7 @@
   cmake_parse_arguments(ARG
 
"DISABLE_LLVM_LINK_LLVM_DYLIB;IGNORE_EXTERNALIZE_DEBUGINFO;NO_INSTALL_RPATH"
 "ENTITLEMENTS"
-"DEPENDS"
+"DEPENDS;RPATHS"
 ${ARGN})
 
   llvm_process_sources( ALL_FILES ${ARG_UNPARSED_ARGUMENTS} )
@@ -748,7 +748,7 @@
   setup_dependency_debugging(${name} ${LLVM_COMMON_DEPENDS})
 
   if(NOT ARG_NO_INSTALL_RPATH)
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
   endif()
 
   if(DEFINED windows_resource_file)
@@ -1660,17 +1660,11 @@
 return()
   endif()
 
-  if(LLVM_INSTALL_PREFIX AND NOT (LLVM_INSTALL_PREFIX STREQUAL 
CMAKE_INSTALL_PREFIX))
-set(extra_libdir ${LLVM_LIBRARY_DIR})
-  elseif(LLVM_BUILD_LIBRARY_DIR)
-set(extra_libdir ${LLVM_LIBRARY_DIR})
-  endif()
-
   if (APPLE)
 set(_install_name_dir INSTALL_NAME_DIR "@rpath")
-set(_install_rpath "@loader_path/../lib" ${extra_libdir})
+set(_install_rpath_default "@loader_path/../lib")
   elseif(UNIX)
-set(_install_rpath "\$ORIGIN/../lib${LLVM_LIBDIR_SUFFIX}" ${extra_libdir})
+set(_install_rpath_default "\$ORIGIN/../lib${LLVM_LIBDIR_SUFFIX}")
 if(${CMAKE_SYSTEM_NAME} MATCHES "(FreeBSD|DragonFly)")
   set_property(TARGET ${name} APPEND_STRING PROPERTY
LINK_FLAGS " -Wl,-z,origin ")
@@ -1684,6 +1678,18 @@
 return()
   endif()
 
+  if(DEFINED ARG_RPATHS)
+set(_install_rpath ${ARG_RPATHS})
+  else()
+set(_install_rpath ${_install_rpath_default})
+  endif()
+
+  if(LLVM_INSTALL_PREFIX AND NOT (LLVM_INSTALL_PREFIX STREQUAL 
CMAKE_INSTALL_PREFIX))
+list(APPEND _install_rpath ${LLVM_LIBRARY_DIR})
+  elseif(LLVM_BUILD_LIBRARY_DIR)
+list(APPEND _install_rpath ${LLVM_LIBRARY_DIR})
+  endif()
+
   set_target_properties(${name} PROPERTIES
 BUILD_WITH_INSTALL_RPATH On
 INSTALL_RPATH "${_install_rpath}"


Index: cmake/modules/AddLLVM.cmake
===
--- cmake/modules/AddLLVM.cmake
+++ cmake/modules/AddLLVM.cmake
@@ -379,7 +379,7 @@
   cmake_parse_arguments(ARG
 "MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME"
 "OUTPUT_NAME;PLUGIN_TOOL"
-"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
+"ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS;RPATHS"
 ${ARGN})
   list(APPEND LLVM_COMMON_DEPENDS ${ARG_DEPENDS})
   if(ARG_ADDITIONAL_HEADERS)
@@ -448,12 +448,12 @@
 
   if(ARG_MODULE)
 add_library(${name} MODULE ${ALL_FILES})
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
   elseif(ARG_SHARED)
 add_windows_version_resource_file(ALL_FILES ${ALL_FILES})
 add_library(${name} SHARED ${ALL_FILES})
 
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
 
   else()
 add_library(${name} STATIC ${ALL_FILES})
@@ -711,7 +711,7 @@
   cmake_parse_arguments(ARG
 "DISABLE_LLVM_LINK_LLVM_DYLIB;IGNORE_EXTERNALIZE_DEBUGINFO;NO_INSTALL_RPATH"
 "ENTITLEMENTS"
-"DEPENDS"
+"DEPENDS;RPATHS"
 ${ARGN})
 
   llvm_process_sources( ALL_FILES ${ARG_UNPARSED_ARGUMENTS} )
@@ -748,7 +748,7 @@
   setup_dependency_debugging(${name} ${LLVM_COMMON_DEPENDS})
 
   if(NOT ARG_NO_INSTALL_RPATH)
-llvm_setup_rpath(${name})
+llvm_setup_rpath(${name} RPATHS ${ARG_RPATHS})
   endif()
 
   if(DEFINED windows_resource_file)
@@ -1660,17 +1660,11 @@
 return()
   endif()
 
-  if(LLVM_INSTALL_PREFIX AND NOT (LLVM_INSTALL_PREFIX STREQUAL CMAKE_INSTALL_PREFIX))
-set(extra_libdir ${LLVM_LIBRARY_DIR})
-  elseif(LLVM_BUILD_LIBRARY_DIR)
-set(extra_libdir ${LLVM_LIBRARY_DIR})
-  endif()
-
   if (APPLE)
   

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Greg Clayton via lldb-commits]

> On Nov 29, 2018, at 2:02 PM, Zachary Turner via Phabricator 
>  wrote:
> 
> zturner added a comment.
> 
> In D53368#1313238 , @labath wrote:
> 
>> In D53368#1313145 , @zturner wrote:
>> 
>>> In D53368#1313124 , @labath wrote:
>>> 
 I've recently started looking at adding a new symbol file format (breakpad 
 symbols). While researching the best way to achieve that, I started 
 comparing the operation of PDB and DWARF symbol files. I noticed a very 
 important difference there, and I think that is the cause of our problems 
 here. In the DWARF implementation, a symbol file is an overlay on top of 
 an object file - it takes the data contained by the object file and 
 presents it in a more structured way.
 
 However, that is not the case with PDB (both implementations). These take 
 the debug information from a completely different file, which is not 
 backed by an ObjectFile instance, and then present that. Since the 
 SymbolFile interface requires them to be backed by an object file, they 
 both pretend they are backed by the original EXE file, but in reality the 
 data comes from elsewhere.
>>> 
>>> 
>>> Don't DWARF DWP files work this way as well?  How is support for this 
>>> implemented in LLDB?
>> 
>> 
>> There are some similarities, but DWP is a bit different. The main difference 
>> is that the DWP file is still an ELF (or whatever) file, so we still have a 
>> ObjectFile sitting below the symbol file. The other difference is that in 
>> case of DWP we still have a significant chunk of debug information present 
>> in the main executable (mainly various offsets that need to be applied to 
>> the unlinked debug info in the dwo/dwp files), so you can still very well 
>> say that the symbol file is reading information from the main executable. 
>> What DWARF does in this case is it creates a main SymbolFileDWARF for 
>> reading data from the main object file, and then a bunch of inner 
>> SymbolFileDWARFDwo/Dwp instances which read data from the other files. There 
>> are plenty of things to not like here as well, but at least this maintains 
>> the property that each symbol file sits on top of the object file from which 
>> it reads the data from. (and symtab doesn't go into the dwp file, so there 
>> are no issues with that).
>> 
 I am asking this because now I am facing a choice in how to implement 
 breakpad symbols. I could go the PDB way, and read the symbols without an 
 intervening object file, or I could create an ObjectFileBreakpad and then 
 (possibly) a SymbolFileBreakpad sitting on top of that.
>>> 
>>> What if `SymbolFile` interface provided a new method such as `GetSymtab()` 
>>> while `ObjectFile` provides a method called `HasExternalSymtab()`.  When 
>>> you call `ObjectFilePECOFF::GetSymtab()`, it could first check if 
>>> `HasExternalSymtab()` is true, and if so it could call the SymbolFile 
>>> plugin and return that
>> 
>> I don't think this would be good because there's no way for the PECOFF file 
>> to know if we will have a PDB file on top of it.
> 
> 
> I'm actually starting to wonder even if `GetSymtab()` should be part of 
> `ObjectFile`.  The first thing it does is get the Module and then start 
> calling a bunch of stuff on the Module interface.  Perhaps the place to start 
> is comparing the Module and ObjectFile interfaces and seeing if the existing 
> APIs make the most sense being moved up to Module.  If everything was on 
> Module then the Module has everything it needs to go to the SymbolVendor and 
> find a PDB file.

I would vote against moving anything into the module. Object files have their 
own symbol tables and we need the ability for an object file to be able to find 
a symbol that it created and we really don't want to abstract this away since 
at any time when we delve further into an object file we might need to dig up a 
symbol by its original symbol table index. So the cleanest design in my opinion 
is one where the object files can each have their own symbol table and the 
module uses the symbol vendor to get promote the best information up to the 
user. Symbols can come from one object file, or an external debug info object 
file, or from Breakpad. But each of those files should be able to have their 
own notion of their own symbols.

Greg

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

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

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Greg Clayton via lldb-commits]

> On Nov 29, 2018, at 10:55 AM, Pavel Labath via Phabricator 
>  wrote:
> 
> labath added a comment.
> 
> I've recently started looking at adding a new symbol file format (breakpad 
> symbols). While researching the best way to achieve that, I started comparing 
> the operation of PDB and DWARF symbol files. I noticed a very important 
> difference there, and I think that is the cause of our problems here. In the 
> DWARF implementation, a symbol file is an overlay on top of an object file - 
> it takes the data contained by the object file and presents it in a more 
> structured way.
> 
> However, that is not the case with PDB (both implementations). These take the 
> debug information from a completely different file, which is not backed by an 
> ObjectFile instance, and then present that. Since the SymbolFile interface 
> requires them to be backed by an object file, they both pretend they are 
> backed by the original EXE file, but in reality the data comes from elsewhere.
> 
> If we had an ObjectFilePDB (which not also not ideal, though in a way it is a 
> better fit to the current lldb organization), then this could expose the PDB 
> symtab via the existing ObjectFile interface and we could reuse the existing 
> mechanism for merging symtabs from two object files.
> 
> I am asking this because now I am facing a choice in how to implement 
> breakpad symbols. I could go the PDB way, and read the symbols without an 
> intervening object file, or I could create an ObjectFileBreakpad and then 
> (possibly) a SymbolFileBreakpad sitting on top of that.
> 
> The drawbacks of the PDB approach I see are:
> 
> - I lose the ability to do matching of the (real) object file via symbol 
> vendors. The PDB symbol files now basically implement their own little symbol 
> vendors inside them, which is mostly fine if you just need to find the PDB 
> next to the exe file. However, things could get a bit messy if you wanted to 
> implement some more complex searching on multiple paths, or downloading them 
> from the internet.
> - I'll hit issues when attempting to unwind (which is the real meat of the 
> breakpad symbols), because unwind info is currently provided via the 
> ObjectFile interface (ObjectFile::GetUnwindTable).
> 
> The drawbacks of the ObjectFile approach are:
> 
> - more code  - it needs a new ObjectFile and a new SymbolFile class (possibly 
> also a SymbolVendor)
> - it will probably look a bit weird because Breakpad files (and PDBs) aren't 
> really object files
> 
> I'd like to hear your thoughts on this, if you have any.

Since the Breakpad files contain symbol and debug info, I would make a 
ObjectFileBreakpad and SymbolFileBreakpad route. We might want to just load a 
break pad file and be able to symbolicate with it. Each symbol vendor will need 
to be able to use a breakpad file (since Breakpad produces files for all 
architectures), so we can build some functionality into the SymbolVendor base 
class for file formats that any file format (ELF, Mach-o, COFF) might want to 
use.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D53368/new/
> 
> https://reviews.llvm.org/D53368
> 
> 
> 

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

[Lldb-commits] [PATCH] D44072: [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type

[Kuba (Brecka) Mracek via Phabricator via lldb-commits]

kubamracek updated this revision to Diff 175961.
Herald added a subscriber: jfb.

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

https://reviews.llvm.org/D44072

Files:
  include/lldb/API/SBThread.h
  include/lldb/Target/LanguageRuntime.h
  include/lldb/Target/Thread.h
  packages/Python/lldbsuite/test/lang/objc/exceptions/TestObjCExceptions.py
  packages/Python/lldbsuite/test/lang/objc/exceptions/main.m
  scripts/interface/SBThread.i
  source/API/SBThread.cpp
  source/Commands/CommandObjectThread.cpp
  
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h
  source/Target/Thread.cpp

Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -23,6 +23,7 @@
 #include "lldb/Target/ABI.h"
 #include "lldb/Target/DynamicLoader.h"
 #include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/ObjCLanguageRuntime.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/StackFrameRecognizer.h"
@@ -2202,16 +2203,30 @@
 }
 
 ValueObjectSP Thread::GetCurrentException() {
-  StackFrameSP frame_sp(GetStackFrameAtIndex(0));
-  if (!frame_sp) return ValueObjectSP();
+  if (auto frame_sp = GetStackFrameAtIndex(0))
+if (auto recognized_frame = frame_sp->GetRecognizedFrame())
+  if (auto e = recognized_frame->GetExceptionObject())
+return e;
+
+  // FIXME: For now, only ObjC exceptions are supported. This should really
+  // iterate over all language runtimes and ask them all to give us the current
+  // exception.
+  if (auto runtime = GetProcess()->GetObjCLanguageRuntime())
+if (auto e = runtime->GetExceptionObjectForThread(shared_from_this()))
+  return e;
 
-  RecognizedStackFrameSP recognized_frame(frame_sp->GetRecognizedFrame());
-  if (!recognized_frame) return ValueObjectSP();
-
-  return recognized_frame->GetExceptionObject();
+  return ValueObjectSP();
 }
 
-/* TODO(kubamracek)
 ThreadSP Thread::GetCurrentExceptionBacktrace() {
-  return ThreadSP();
-}*/
+  ValueObjectSP exception = GetCurrentException();
+  if (!exception) return ThreadSP();
+
+  // FIXME: For now, only ObjC exceptions are supported. This should really
+  // iterate over all language runtimes and ask them all to give us the current
+  // exception.
+  auto runtime = GetProcess()->GetObjCLanguageRuntime();
+  if (!runtime) return ThreadSP();
+
+  return runtime->GetBacktraceThreadFromException(exception);
+}
Index: source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h
===
--- source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h
+++ source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h
@@ -89,6 +89,12 @@
   
   static std::tuple GetExceptionThrowLocation();
 
+  lldb::ValueObjectSP GetExceptionObjectForThread(
+  lldb::ThreadSP thread_sp) override;
+
+  lldb::ThreadSP GetBacktraceThreadFromException(
+  lldb::ValueObjectSP thread_sp) override;
+
   uint32_t GetFoundationVersion();
 
   virtual void GetValuesForGlobalCFBooleans(lldb::addr_t _true,
Index: source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
===
--- source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
+++ source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
@@ -19,10 +19,13 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Core/ValueObject.h"
+#include "lldb/Core/ValueObjectConstResult.h"
+#include "lldb/DataFormatters/FormattersHelpers.h"
 #include "lldb/Expression/DiagnosticManager.h"
 #include "lldb/Expression/FunctionCaller.h"
 #include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Target/CPPLanguageRuntime.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/RegisterContext.h"
@@ -35,6 +38,9 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StreamString.h"
 
+#include "Plugins/Process/Utility/HistoryThread.h"
+#include "Plugins/Language/ObjC/NSString.h"
+
 #include 
 
 using namespace lldb;
@@ -462,6 +468,102 @@
   }
 }
 
+ValueObjectSP AppleObjCRuntime::GetExceptionObjectForThread(
+ThreadSP thread_sp) {
+  auto cpp_runtime = m_process->GetCPPLanguageRuntime();
+  if (!cpp_runtime) return ValueObjectSP();
+  auto cpp_exception = cpp_runtime->GetExceptionObjectForThread(thread_sp);
+  if (!cpp_exception) return ValueObjectSP();
+  
+  auto descriptor = GetClassDescriptor(*cpp_exception.get());
+  if (!descriptor || !descriptor->IsValid()) 

[Lldb-commits] [lldb] r347924 - [lldbsuite] Build with -gdwarf on Windows

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Thu Nov 29 14:15:23 2018
New Revision: 347924

URL: http://llvm.org/viewvc/llvm-project?rev=347924=rev
Log:
[lldbsuite] Build with -gdwarf on Windows

Earlier this month there was a change in clang that defaulted to using codeview 
rather than dwarf on Windows. Since all the tests rely on dwarf, we need to 
explicitly request dwarf when building on Windows.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules

Modified: lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules?rev=347924=347923=347924=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules Thu Nov 29 
14:15:23 2018
@@ -257,6 +257,12 @@ endif
 CFLAGS += -I$(SRCDIR) -include $(THIS_FILE_DIR)test_common.h -I$(THIS_FILE_DIR)
 CFLAGS += $(NO_LIMIT_DEBUG_INFO_FLAGS) $(ARCH_CFLAGS) $(CFLAGS_EXTRAS)
 
+# If the OS is Windows, we need to pass -gdwarf to clang, otherwise it will 
build
+# with codeview by default but all the tests rely on dwarf.
+ifeq "$(OS)" "Windows_NT"
+   CFLAGS += -gdwarf
+endif
+
 # Use this one if you want to build one part of the result without debug 
information:
 ifeq "$(OS)" "Darwin"
CFLAGS_NO_DEBUG = -O0 $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) 
$(ARCH_CFLAGS) $(CFLAGS_EXTRAS)


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

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In D53368#1313238 , @labath wrote:

> In D53368#1313145 , @zturner wrote:
>
> > In D53368#1313124 , @labath wrote:
> >
> > > I've recently started looking at adding a new symbol file format 
> > > (breakpad symbols). While researching the best way to achieve that, I 
> > > started comparing the operation of PDB and DWARF symbol files. I noticed 
> > > a very important difference there, and I think that is the cause of our 
> > > problems here. In the DWARF implementation, a symbol file is an overlay 
> > > on top of an object file - it takes the data contained by the object file 
> > > and presents it in a more structured way.
> > >
> > > However, that is not the case with PDB (both implementations). These take 
> > > the debug information from a completely different file, which is not 
> > > backed by an ObjectFile instance, and then present that. Since the 
> > > SymbolFile interface requires them to be backed by an object file, they 
> > > both pretend they are backed by the original EXE file, but in reality the 
> > > data comes from elsewhere.
> >
> >
> > Don't DWARF DWP files work this way as well?  How is support for this 
> > implemented in LLDB?
>
>
> There are some similarities, but DWP is a bit different. The main difference 
> is that the DWP file is still an ELF (or whatever) file, so we still have a 
> ObjectFile sitting below the symbol file. The other difference is that in 
> case of DWP we still have a significant chunk of debug information present in 
> the main executable (mainly various offsets that need to be applied to the 
> unlinked debug info in the dwo/dwp files), so you can still very well say 
> that the symbol file is reading information from the main executable. What 
> DWARF does in this case is it creates a main SymbolFileDWARF for reading data 
> from the main object file, and then a bunch of inner SymbolFileDWARFDwo/Dwp 
> instances which read data from the other files. There are plenty of things to 
> not like here as well, but at least this maintains the property that each 
> symbol file sits on top of the object file from which it reads the data from. 
> (and symtab doesn't go into the dwp file, so there are no issues with that).
>
> >> I am asking this because now I am facing a choice in how to implement 
> >> breakpad symbols. I could go the PDB way, and read the symbols without an 
> >> intervening object file, or I could create an ObjectFileBreakpad and then 
> >> (possibly) a SymbolFileBreakpad sitting on top of that.
> > 
> > What if `SymbolFile` interface provided a new method such as `GetSymtab()` 
> > while `ObjectFile` provides a method called `HasExternalSymtab()`.  When 
> > you call `ObjectFilePECOFF::GetSymtab()`, it could first check if 
> > `HasExternalSymtab()` is true, and if so it could call the SymbolFile 
> > plugin and return that
>
> I don't think this would be good because there's no way for the PECOFF file 
> to know if we will have a PDB file on top of it.


I'm actually starting to wonder even if `GetSymtab()` should be part of 
`ObjectFile`.  The first thing it does is get the Module and then start calling 
a bunch of stuff on the Module interface.  Perhaps the place to start is 
comparing the Module and ObjectFile interfaces and seeing if the existing APIs 
make the most sense being moved up to Module.  If everything was on Module then 
the Module has everything it needs to go to the SymbolVendor and find a PDB 
file.


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

https://reviews.llvm.org/D53368



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

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

On 29/11/2018 21:29, Leonard Mosescu wrote:

> Hi Aleksandr, yes, no objections to this patch.
> 
> I was responding to Pavel's comments, which I also assume are 
>  forward-looking as well, not strictly related to this patch.

Agreed, and I apologise for hijacking your review (I seem to be getting in the 
habit of that). I initially thought that having a ObjectFilePDB might mean that 
this patch would not be needed, but now I am slowly growing to like it. I think 
it makes sense for a symbol file to be able to provide additional symbols 
regardless of whether this could be done differently too.


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

https://reviews.llvm.org/D53368



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

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

> Great observations Pavel! I think it's really important to have 
>  orthogonal/composable abstractions here: the symbols should be decoupled 
>  from the container format IMO.
> 
> You know more about the ObjectFile than me so I can't say if 
>  ObjectFileBreakpad is the best interface, but here are my initial 
>  observations (in a somewhat random order):

Even though it doesn't sound like that, ironically, Breakpad might be now 
better of as an ObjectFile rather than a SymbolFile. The main three pieces of 
information contained in breakpad files are:

- list of symbols
- unwind information
- line tables

Of these, the first two are presently vended by object files, and only the line 
table is done by symbol files. The auxiliary pieces of information in the 
breakpad files (architecture, OS, UUID), are also a property of object files in 
lldb.

> 1. We need clear and separate abstractions for a container (ELF, PE file, 
> Breakpad symbols) vs. the content (debug Information).

I agree, unfortunately I think we're quite far from that now. This is 
complicated by the fact that different "symbol file" formats have different 
notion of what "symbols" are. E.g. it's obvious that Symtab ended up being 
vended by the object files because that's how elf+macho/dwarf do things, but 
that's not the case for pecoff/pdb.

> 2. We need to be able to consume symbols when the corresponding module binary 
> is not available. This is common for postmortem debugging (ex. having a 
> minidump + PDBs, but not all the .DLLs or EXE files).

This is also going to be a bit tricky, though slightly orthogonal requirement. 
Right now things generally assume that a Module has an ObjectFile to read the 
data from, even though ProcessMinidump tries to work around that with special 
kinds of Modules. That might be enough to make addresses resolve somewhat 
reasonably, but I'm not sure what will happen once we start providing symbols 
for those kinds of modules.

> 
> 
> 3. I'm not a fan of the PDB model, where the symbols are searched in both the 
> symtabs then in the symbol files. I'd rather like to see the symtab an 
> interface for symbols regardless of where they come from. (Zach expressed 
> some efficiency concerns if we'd need to build a symtab from a PDB for 
> example as opposed to accessing the PDB symfile directly, although I think we 
> can design to address this - ie. multiple concrete symtab implementations, 
> some of which are *internally* aware of the source container, but w/o leaking 
> this through the interface)

I am afraid I am a bit lost here, as I don't know much about PDBs. I'll have to 
study this in more detail.

> 
> 
> 4. The symbol vendor observation is very important. Right now LLDB has basic 
> support for looking up DWARF symbols and none for PDBs. (for example, IMO 
> LLDB could greatly benefit from something like Microsoft's symsrv - I'm 
> actually planning to look into it soon) (Whatever we do, this should be one 
> of the key requirements IMO)

agreed.


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

https://reviews.llvm.org/D53368



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

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Leonard Mosescu via lldb-commits]

Hi Aleksandr, yes, no objections to this patch.

I was responding to Pavel's comments, which I also assume are
forward-looking as well, not strictly related to this patch.

On Thu, Nov 29, 2018 at 12:08 PM Aleksandr Urakov <
aleksandr.ura...@jetbrains.com> wrote:

> Yes, I agree that the current model of object files - symbol files -
> symtabs is not clear and orthogonal for cases like PDB, and I think that it
> requires some redesign too.
>
> But can we commit this patch now to proceed with several dependent (and
> not directly related to the theme) patches?
>
> When a new model of work with symbol files will be approved I'm ready to
> help with fixing the PDB part to conform it.
>
> Am Do., 29. Nov. 2018, 22:18 hat Leonard Mosescu 
> geschrieben:
>
>> Great observations Pavel! I think it's really important to have
>> orthogonal/composable abstractions here: the symbols should be decoupled
>> from the container format IMO.
>>
>> You know more about the ObjectFile than me so I can't say if
>> ObjectFileBreakpad is the best interface, but here are my initial
>> observations (in a somewhat random order):
>>
>> 1. We need clear and separate abstractions for a container (ELF, PE file,
>> Breakpad symbols) vs. the content (debug Information).
>>
>> 2. We need to be able to consume symbols when the corresponding module
>> binary is not available. This is common for postmortem debugging (ex.
>> having a minidump + PDBs, but not all the .DLLs or EXE files).
>>
>> 3. I'm not a fan of the PDB model, where the symbols are searched in both
>> the symtabs then in the symbol files. I'd rather like to see the symtab an
>> interface for symbols regardless of where they come from.
>>(Zach expressed some efficiency concerns if we'd need to build a
>> symtab from a PDB for example as opposed to accessing the PDB symfile
>> directly, although I think we can design to address this - ie. multiple
>> concrete symtab implementations, some of which are *internally* aware of
>> the source container, but w/o leaking this through the interface)
>>
>> 4. The symbol vendor observation is very important. Right now LLDB has
>> basic support for looking up DWARF symbols and none for PDBs. (for example,
>> IMO LLDB could greatly benefit from something like Microsoft's symsrv - I'm
>> actually planning to look into it soon)
>>   (Whatever we do, this should be one of the key requirements IMO)
>>
>> I have a local change to address #2 specifically for PDBs (I'll try to
>> send out a code review soon).
>>
>> On Thu, Nov 29, 2018 at 10:55 AM Pavel Labath via Phabricator via
>> lldb-commits  wrote:
>>
>>> labath added a comment.
>>>
>>> I've recently started looking at adding a new symbol file format
>>> (breakpad symbols). While researching the best way to achieve that, I
>>> started comparing the operation of PDB and DWARF symbol files. I noticed a
>>> very important difference there, and I think that is the cause of our
>>> problems here. In the DWARF implementation, a symbol file is an overlay on
>>> top of an object file - it takes the data contained by the object file and
>>> presents it in a more structured way.
>>>
>>> However, that is not the case with PDB (both implementations). These
>>> take the debug information from a completely different file, which is not
>>> backed by an ObjectFile instance, and then present that. Since the
>>> SymbolFile interface requires them to be backed by an object file, they
>>> both pretend they are backed by the original EXE file, but in reality the
>>> data comes from elsewhere.
>>>
>>> If we had an ObjectFilePDB (which not also not ideal, though in a way it
>>> is a better fit to the current lldb organization), then this could expose
>>> the PDB symtab via the existing ObjectFile interface and we could reuse the
>>> existing mechanism for merging symtabs from two object files.
>>>
>>> I am asking this because now I am facing a choice in how to implement
>>> breakpad symbols. I could go the PDB way, and read the symbols without an
>>> intervening object file, or I could create an ObjectFileBreakpad and then
>>> (possibly) a SymbolFileBreakpad sitting on top of that.
>>>
>>> The drawbacks of the PDB approach I see are:
>>>
>>> - I lose the ability to do matching of the (real) object file via symbol
>>> vendors. The PDB symbol files now basically implement their own little
>>> symbol vendors inside them, which is mostly fine if you just need to find
>>> the PDB next to the exe file. However, things could get a bit messy if you
>>> wanted to implement some more complex searching on multiple paths, or
>>> downloading them from the internet.
>>> - I'll hit issues when attempting to unwind (which is the real meat of
>>> the breakpad symbols), because unwind info is currently provided via the
>>> ObjectFile interface (ObjectFile::GetUnwindTable).
>>>
>>> The drawbacks of the ObjectFile approach are:
>>>
>>> - more code  - it needs a new ObjectFile and a new SymbolFile class
>>> (possibly also a 

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D53368#1313145 , @zturner wrote:

> In D53368#1313124 , @labath wrote:
>
> > I've recently started looking at adding a new symbol file format (breakpad 
> > symbols). While researching the best way to achieve that, I started 
> > comparing the operation of PDB and DWARF symbol files. I noticed a very 
> > important difference there, and I think that is the cause of our problems 
> > here. In the DWARF implementation, a symbol file is an overlay on top of an 
> > object file - it takes the data contained by the object file and presents 
> > it in a more structured way.
> >
> > However, that is not the case with PDB (both implementations). These take 
> > the debug information from a completely different file, which is not backed 
> > by an ObjectFile instance, and then present that. Since the SymbolFile 
> > interface requires them to be backed by an object file, they both pretend 
> > they are backed by the original EXE file, but in reality the data comes 
> > from elsewhere.
>
>
> Don't DWARF DWP files work this way as well?  How is support for this 
> implemented in LLDB?


There are some similarities, but DWP is a bit different. The main difference is 
that the DWP file is still an ELF (or whatever) file, so we still have a 
ObjectFile sitting below the symbol file. The other difference is that in case 
of DWP we still have a significant chunk of debug information present in the 
main executable (mainly various offsets that need to be applied to the unlinked 
debug info in the dwo/dwp files), so you can still very well say that the 
symbol file is reading information from the main executable. What DWARF does in 
this case is it creates a main SymbolFileDWARF for reading data from the main 
object file, and then a bunch of inner SymbolFileDWARFDwo/Dwp instances which 
read data from the other files. There are plenty of things to not like here as 
well, but at least this maintains the property that each symbol file sits on 
top of the object file from which it reads the data from. (and symtab doesn't 
go into the dwp file, so there are no issues with that).

>> I am asking this because now I am facing a choice in how to implement 
>> breakpad symbols. I could go the PDB way, and read the symbols without an 
>> intervening object file, or I could create an ObjectFileBreakpad and then 
>> (possibly) a SymbolFileBreakpad sitting on top of that.
> 
> What if `SymbolFile` interface provided a new method such as `GetSymtab()` 
> while `ObjectFile` provides a method called `HasExternalSymtab()`.  When you 
> call `ObjectFilePECOFF::GetSymtab()`, it could first check if 
> `HasExternalSymtab()` is true, and if so it could call the SymbolFile plugin 
> and return that

I don't think this would be good because there's no way for the PECOFF file to 
know if we will have a PDB file on top of it. If we don't find the pdb file, 
then the best we can do is use the list of external symbols as the symtab for 
the PECOFF file. I think a better way would ask the SymbolFile for the symtab. 
Then the symbol file can either return it's own symtab, or just forward the 
symtab from the object file (we already have a SymbolFileSymtab for cases when 
we have no debug info). That is more-or-less what this patch is doing, except 
that here the SymbolFile is inserting it's own symbols into the symtab created 
by the object file.


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

https://reviews.llvm.org/D53368



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

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Aleksandr Urakov via lldb-commits]

Yes, I agree that the current model of object files - symbol files -
symtabs is not clear and orthogonal for cases like PDB, and I think that it
requires some redesign too.

But can we commit this patch now to proceed with several dependent (and not
directly related to the theme) patches?

When a new model of work with symbol files will be approved I'm ready to
help with fixing the PDB part to conform it.

Am Do., 29. Nov. 2018, 22:18 hat Leonard Mosescu 
geschrieben:

> Great observations Pavel! I think it's really important to have
> orthogonal/composable abstractions here: the symbols should be decoupled
> from the container format IMO.
>
> You know more about the ObjectFile than me so I can't say if
> ObjectFileBreakpad is the best interface, but here are my initial
> observations (in a somewhat random order):
>
> 1. We need clear and separate abstractions for a container (ELF, PE file,
> Breakpad symbols) vs. the content (debug Information).
>
> 2. We need to be able to consume symbols when the corresponding module
> binary is not available. This is common for postmortem debugging (ex.
> having a minidump + PDBs, but not all the .DLLs or EXE files).
>
> 3. I'm not a fan of the PDB model, where the symbols are searched in both
> the symtabs then in the symbol files. I'd rather like to see the symtab an
> interface for symbols regardless of where they come from.
>(Zach expressed some efficiency concerns if we'd need to build a symtab
> from a PDB for example as opposed to accessing the PDB symfile directly,
> although I think we can design to address this - ie. multiple concrete
> symtab implementations, some of which are *internally* aware of the source
> container, but w/o leaking this through the interface)
>
> 4. The symbol vendor observation is very important. Right now LLDB has
> basic support for looking up DWARF symbols and none for PDBs. (for example,
> IMO LLDB could greatly benefit from something like Microsoft's symsrv - I'm
> actually planning to look into it soon)
>   (Whatever we do, this should be one of the key requirements IMO)
>
> I have a local change to address #2 specifically for PDBs (I'll try to
> send out a code review soon).
>
> On Thu, Nov 29, 2018 at 10:55 AM Pavel Labath via Phabricator via
> lldb-commits  wrote:
>
>> labath added a comment.
>>
>> I've recently started looking at adding a new symbol file format
>> (breakpad symbols). While researching the best way to achieve that, I
>> started comparing the operation of PDB and DWARF symbol files. I noticed a
>> very important difference there, and I think that is the cause of our
>> problems here. In the DWARF implementation, a symbol file is an overlay on
>> top of an object file - it takes the data contained by the object file and
>> presents it in a more structured way.
>>
>> However, that is not the case with PDB (both implementations). These take
>> the debug information from a completely different file, which is not backed
>> by an ObjectFile instance, and then present that. Since the SymbolFile
>> interface requires them to be backed by an object file, they both pretend
>> they are backed by the original EXE file, but in reality the data comes
>> from elsewhere.
>>
>> If we had an ObjectFilePDB (which not also not ideal, though in a way it
>> is a better fit to the current lldb organization), then this could expose
>> the PDB symtab via the existing ObjectFile interface and we could reuse the
>> existing mechanism for merging symtabs from two object files.
>>
>> I am asking this because now I am facing a choice in how to implement
>> breakpad symbols. I could go the PDB way, and read the symbols without an
>> intervening object file, or I could create an ObjectFileBreakpad and then
>> (possibly) a SymbolFileBreakpad sitting on top of that.
>>
>> The drawbacks of the PDB approach I see are:
>>
>> - I lose the ability to do matching of the (real) object file via symbol
>> vendors. The PDB symbol files now basically implement their own little
>> symbol vendors inside them, which is mostly fine if you just need to find
>> the PDB next to the exe file. However, things could get a bit messy if you
>> wanted to implement some more complex searching on multiple paths, or
>> downloading them from the internet.
>> - I'll hit issues when attempting to unwind (which is the real meat of
>> the breakpad symbols), because unwind info is currently provided via the
>> ObjectFile interface (ObjectFile::GetUnwindTable).
>>
>> The drawbacks of the ObjectFile approach are:
>>
>> - more code  - it needs a new ObjectFile and a new SymbolFile class
>> (possibly also a SymbolVendor)
>> - it will probably look a bit weird because Breakpad files (and PDBs)
>> aren't really object files
>>
>> I'd like to hear your thoughts on this, if you have any.
>>
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D53368/new/
>>
>> https://reviews.llvm.org/D53368
>>
>>
>>
>> ___
>> lldb-commits 

Re: [Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Leonard Mosescu via lldb-commits]

Great observations Pavel! I think it's really important to have
orthogonal/composable abstractions here: the symbols should be decoupled
from the container format IMO.

You know more about the ObjectFile than me so I can't say if
ObjectFileBreakpad is the best interface, but here are my initial
observations (in a somewhat random order):

1. We need clear and separate abstractions for a container (ELF, PE file,
Breakpad symbols) vs. the content (debug Information).

2. We need to be able to consume symbols when the corresponding module
binary is not available. This is common for postmortem debugging (ex.
having a minidump + PDBs, but not all the .DLLs or EXE files).

3. I'm not a fan of the PDB model, where the symbols are searched in both
the symtabs then in the symbol files. I'd rather like to see the symtab an
interface for symbols regardless of where they come from.
   (Zach expressed some efficiency concerns if we'd need to build a symtab
from a PDB for example as opposed to accessing the PDB symfile directly,
although I think we can design to address this - ie. multiple concrete
symtab implementations, some of which are *internally* aware of the source
container, but w/o leaking this through the interface)

4. The symbol vendor observation is very important. Right now LLDB has
basic support for looking up DWARF symbols and none for PDBs. (for example,
IMO LLDB could greatly benefit from something like Microsoft's symsrv - I'm
actually planning to look into it soon)
  (Whatever we do, this should be one of the key requirements IMO)

I have a local change to address #2 specifically for PDBs (I'll try to send
out a code review soon).

On Thu, Nov 29, 2018 at 10:55 AM Pavel Labath via Phabricator via
lldb-commits  wrote:

> labath added a comment.
>
> I've recently started looking at adding a new symbol file format (breakpad
> symbols). While researching the best way to achieve that, I started
> comparing the operation of PDB and DWARF symbol files. I noticed a very
> important difference there, and I think that is the cause of our problems
> here. In the DWARF implementation, a symbol file is an overlay on top of an
> object file - it takes the data contained by the object file and presents
> it in a more structured way.
>
> However, that is not the case with PDB (both implementations). These take
> the debug information from a completely different file, which is not backed
> by an ObjectFile instance, and then present that. Since the SymbolFile
> interface requires them to be backed by an object file, they both pretend
> they are backed by the original EXE file, but in reality the data comes
> from elsewhere.
>
> If we had an ObjectFilePDB (which not also not ideal, though in a way it
> is a better fit to the current lldb organization), then this could expose
> the PDB symtab via the existing ObjectFile interface and we could reuse the
> existing mechanism for merging symtabs from two object files.
>
> I am asking this because now I am facing a choice in how to implement
> breakpad symbols. I could go the PDB way, and read the symbols without an
> intervening object file, or I could create an ObjectFileBreakpad and then
> (possibly) a SymbolFileBreakpad sitting on top of that.
>
> The drawbacks of the PDB approach I see are:
>
> - I lose the ability to do matching of the (real) object file via symbol
> vendors. The PDB symbol files now basically implement their own little
> symbol vendors inside them, which is mostly fine if you just need to find
> the PDB next to the exe file. However, things could get a bit messy if you
> wanted to implement some more complex searching on multiple paths, or
> downloading them from the internet.
> - I'll hit issues when attempting to unwind (which is the real meat of the
> breakpad symbols), because unwind info is currently provided via the
> ObjectFile interface (ObjectFile::GetUnwindTable).
>
> The drawbacks of the ObjectFile approach are:
>
> - more code  - it needs a new ObjectFile and a new SymbolFile class
> (possibly also a SymbolVendor)
> - it will probably look a bit weird because Breakpad files (and PDBs)
> aren't really object files
>
> I'd like to hear your thoughts on this, if you have any.
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D53368/new/
>
> https://reviews.llvm.org/D53368
>
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In D53368#1313124 , @labath wrote:

> I've recently started looking at adding a new symbol file format (breakpad 
> symbols). While researching the best way to achieve that, I started comparing 
> the operation of PDB and DWARF symbol files. I noticed a very important 
> difference there, and I think that is the cause of our problems here. In the 
> DWARF implementation, a symbol file is an overlay on top of an object file - 
> it takes the data contained by the object file and presents it in a more 
> structured way.
>
> However, that is not the case with PDB (both implementations). These take the 
> debug information from a completely different file, which is not backed by an 
> ObjectFile instance, and then present that. Since the SymbolFile interface 
> requires them to be backed by an object file, they both pretend they are 
> backed by the original EXE file, but in reality the data comes from elsewhere.


Don't DWARF DWP files work this way as well?  How is support for this 
implemented in LLDB?

> If we had an ObjectFilePDB (which not also not ideal, though in a way it is a 
> better fit to the current lldb organization), then this could expose the PDB 
> symtab via the existing ObjectFile interface and we could reuse the existing 
> mechanism for merging symtabs from two object files.
> 
> I am asking this because now I am facing a choice in how to implement 
> breakpad symbols. I could go the PDB way, and read the symbols without an 
> intervening object file, or I could create an ObjectFileBreakpad and then 
> (possibly) a SymbolFileBreakpad sitting on top of that.

What `SymbolFile` interface provided a new method such as `GetSymtab()` while 
`ObjectFile` provides a method called `HasExternalSymtab()`.  When you call 
`ObjectFilePECOFF::GetSymtab()`, it could first check if `HasExternalSymtab()` 
is true, and if so it could call the SymbolFile plugin and return that


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

https://reviews.llvm.org/D53368



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

[Lldb-commits] [PATCH] D53368: [Symbol] Search symbols with name and type in a symbol file

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I've recently started looking at adding a new symbol file format (breakpad 
symbols). While researching the best way to achieve that, I started comparing 
the operation of PDB and DWARF symbol files. I noticed a very important 
difference there, and I think that is the cause of our problems here. In the 
DWARF implementation, a symbol file is an overlay on top of an object file - it 
takes the data contained by the object file and presents it in a more 
structured way.

However, that is not the case with PDB (both implementations). These take the 
debug information from a completely different file, which is not backed by an 
ObjectFile instance, and then present that. Since the SymbolFile interface 
requires them to be backed by an object file, they both pretend they are backed 
by the original EXE file, but in reality the data comes from elsewhere.

If we had an ObjectFilePDB (which not also not ideal, though in a way it is a 
better fit to the current lldb organization), then this could expose the PDB 
symtab via the existing ObjectFile interface and we could reuse the existing 
mechanism for merging symtabs from two object files.

I am asking this because now I am facing a choice in how to implement breakpad 
symbols. I could go the PDB way, and read the symbols without an intervening 
object file, or I could create an ObjectFileBreakpad and then (possibly) a 
SymbolFileBreakpad sitting on top of that.

The drawbacks of the PDB approach I see are:

- I lose the ability to do matching of the (real) object file via symbol 
vendors. The PDB symbol files now basically implement their own little symbol 
vendors inside them, which is mostly fine if you just need to find the PDB next 
to the exe file. However, things could get a bit messy if you wanted to 
implement some more complex searching on multiple paths, or downloading them 
from the internet.
- I'll hit issues when attempting to unwind (which is the real meat of the 
breakpad symbols), because unwind info is currently provided via the ObjectFile 
interface (ObjectFile::GetUnwindTable).

The drawbacks of the ObjectFile approach are:

- more code  - it needs a new ObjectFile and a new SymbolFile class (possibly 
also a SymbolVendor)
- it will probably look a bit weird because Breakpad files (and PDBs) aren't 
really object files

I'd like to hear your thoughts on this, if you have any.


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

https://reviews.llvm.org/D53368



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

[Lldb-commits] [PATCH] D54914: Add a generic build script for building test inferiors

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

If there are no further comments I'd like to get this in later today.


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

https://reviews.llvm.org/D54914



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

[Lldb-commits] [PATCH] D55013: [CMake] Streamline code signing for debugserver #2

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added inline comments.



Comment at: tools/debugserver/CMakeLists.txt:18
+
+  option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if 
available" ON)
+  set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING

JDevlieghere wrote:
> sgraenitz wrote:
> > JDevlieghere wrote:
> > > Why do we need to define this option again for the debugserver? Why can't 
> > > it use the one from LLDBConfig.cmake?
> > In a debugserver standalone build we don't `include(LLDBConfig)`. It makes 
> > sense to me, because there is not much to configure when only building the 
> > debugserver.
> Makes sense. Maybe we could put this in the top level CMakeLists.txt? 
This is the top level CMakeLists.txt for standalone debugserver :) See my 
previous comment about testing.


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

https://reviews.llvm.org/D55013



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

[Lldb-commits] [PATCH] D55032: [CMake] Fix standalone build for debugserver on macOS

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL347869: [CMake] Fix standalone build for debugserver on 
macOS (authored by stefan.graenitz, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D55032?vs=175775=175865#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D55032

Files:
  lldb/trunk/tools/debugserver/CMakeLists.txt


Index: lldb/trunk/tools/debugserver/CMakeLists.txt
===
--- lldb/trunk/tools/debugserver/CMakeLists.txt
+++ lldb/trunk/tools/debugserver/CMakeLists.txt
@@ -8,12 +8,17 @@
 "${CMAKE_SOURCE_DIR}/../../cmake"
 "${CMAKE_SOURCE_DIR}/../../cmake/modules"
 )
-  
+
   include(LLDBStandalone)
   include(AddLLDB)
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
   include_directories(${LLDB_SOURCE_DIR}/include)
+
+  # lldb-suite is a dummy target that encompasses all the necessary tools and
+  # libraries for building a fully-functioning liblldb.
+  add_custom_target(lldb-suite)
+  set(LLDB_SUITE_TARGET lldb-suite)
 endif()
 
 add_subdirectory(source)


Index: lldb/trunk/tools/debugserver/CMakeLists.txt
===
--- lldb/trunk/tools/debugserver/CMakeLists.txt
+++ lldb/trunk/tools/debugserver/CMakeLists.txt
@@ -8,12 +8,17 @@
 "${CMAKE_SOURCE_DIR}/../../cmake"
 "${CMAKE_SOURCE_DIR}/../../cmake/modules"
 )
-  
+
   include(LLDBStandalone)
   include(AddLLDB)
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
   include_directories(${LLDB_SOURCE_DIR}/include)
+
+  # lldb-suite is a dummy target that encompasses all the necessary tools and
+  # libraries for building a fully-functioning liblldb.
+  add_custom_target(lldb-suite)
+  set(LLDB_SUITE_TARGET lldb-suite)
 endif()
 
 add_subdirectory(source)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r347869 - [CMake] Fix standalone build for debugserver on macOS

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Thu Nov 29 06:51:49 2018
New Revision: 347869

URL: http://llvm.org/viewvc/llvm-project?rev=347869=rev
Log:
[CMake] Fix standalone build for debugserver on macOS

Summary:
Quick-fix to avoid CMake config issue:
```
CMake Error at /path/to/lldb/cmake/modules/AddLLDB.cmake:116 (add_dependencies):
  Cannot add target-level dependencies to non-existent target "lldb-suite".
```

Reviewers: xiaobai, beanz

Subscribers: mgorny, lldb-commits

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

Modified:
lldb/trunk/tools/debugserver/CMakeLists.txt

Modified: lldb/trunk/tools/debugserver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/CMakeLists.txt?rev=347869=347868=347869=diff
==
--- lldb/trunk/tools/debugserver/CMakeLists.txt (original)
+++ lldb/trunk/tools/debugserver/CMakeLists.txt Thu Nov 29 06:51:49 2018
@@ -8,12 +8,17 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 "${CMAKE_SOURCE_DIR}/../../cmake"
 "${CMAKE_SOURCE_DIR}/../../cmake/modules"
 )
-  
+
   include(LLDBStandalone)
   include(AddLLDB)
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
   include_directories(${LLDB_SOURCE_DIR}/include)
+
+  # lldb-suite is a dummy target that encompasses all the necessary tools and
+  # libraries for building a fully-functioning liblldb.
+  add_custom_target(lldb-suite)
+  set(LLDB_SUITE_TARGET lldb-suite)
 endif()
 
 add_subdirectory(source)


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

[Lldb-commits] [PATCH] D55032: [CMake] Fix standalone build for debugserver on macOS

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

Thought about it, but yes, at the moment it looks like overkill. I'd go on 
duplicating options to debugserver for now and change the approach if it gets 
unpractical. There are some more changes to come. I want to upstream these 
first and see how it looks then.


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

https://reviews.llvm.org/D55032



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

[Lldb-commits] [PATCH] D54844: [LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwo

[George Rimar via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL347859: [LLDB] - Improve the support of 
.debug_str_offsets/.debug_str_offsets.dwo (authored by grimar, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D54844?vs=175092=175853#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D54844

Files:
  lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml
  lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file2.dwo.yaml
  lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-main.yaml
  lldb/trunk/lit/Breakpoint/split-dwarf5-debug-stroffsets.test
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.h

Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
@@ -111,9 +111,11 @@
   dw_addr_t GetBaseAddress() const { return m_base_addr; }
   dw_addr_t GetAddrBase() const { return m_addr_base; }
   dw_addr_t GetRangesBase() const { return m_ranges_base; }
+  dw_addr_t GetStrOffsetsBase() const { return m_str_offsets_base; }
   void SetAddrBase(dw_addr_t addr_base);
   void SetRangesBase(dw_addr_t ranges_base);
   void SetBaseObjOffset(dw_offset_t base_obj_offset);
+  void SetStrOffsetsBase(dw_offset_t str_offsets_base);
   void BuildAddressRangeTable(SymbolFileDWARF *dwarf,
   DWARFDebugAranges *debug_aranges);
 
@@ -217,7 +219,7 @@
   // If this is a dwo compile unit this is the offset of the base compile unit
   // in the main object file
   dw_offset_t m_base_obj_offset = DW_INVALID_OFFSET;
-
+  dw_offset_t m_str_offsets_base = 0; // Value of DW_AT_str_offsets_base.
   // Offset of the initial length field.
   dw_offset_t m_offset;
 
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -569,22 +569,9 @@
 if (!symbol_file)
   return nullptr;
 
-lldb::offset_t baseOffset = 0;
-const DWARFDataExtractor  =
-symbol_file->get_debug_str_offsets_data();
-uint64_t length = strOffsets.GetU32();
-if (length == 0x)
-  length = strOffsets.GetU64();
-
-// Check version.
-if (strOffsets.GetU16() < 5)
-  return nullptr;
-
-// Skip padding.
-baseOffset += 2;
-
 uint32_t indexSize = m_cu->IsDWARF64() ? 8 : 4;
-lldb::offset_t offset = baseOffset + m_value.value.uval * indexSize;
+lldb::offset_t offset =
+m_cu->GetStrOffsetsBase() + m_value.value.uval * indexSize;
 dw_offset_t strOffset =
 symbol_file->get_debug_str_offsets_data().GetMaxU64(, indexSize);
 return symbol_file->get_debug_str_data().PeekCStr(strOffset);
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -305,6 +305,31 @@
   }
 }
 
+// This is used when a split dwarf is enabled.
+// A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
+// that points to the first string offset of the CU contribution to the
+// .debug_str_offsets. At the same time, the corresponding split debug unit also
+// may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo and
+// for that case, we should find the offset (skip the section header).
+static void SetDwoStrOffsetsBase(DWARFUnit *dwo_cu) {
+  lldb::offset_t baseOffset = 0;
+
+  const DWARFDataExtractor  =
+  dwo_cu->GetSymbolFileDWARF()->get_debug_str_offsets_data();
+  uint64_t length = strOffsets.GetU32();
+  if (length == 0x)
+length = strOffsets.GetU64();
+
+  // Check version.
+  if (strOffsets.GetU16() < 5)
+return;
+
+  // Skip padding.
+  baseOffset += 2;
+
+  dwo_cu->SetStrOffsetsBase(baseOffset);
+}
+
 // m_die_array_mutex must be already held as read/write.
 void DWARFUnit::AddUnitDIE(const DWARFDebugInfoEntry _die) {
   dw_addr_t addr_base = cu_die.GetAttributeValueAsUnsigned(
@@ -312,8 +337,13 @@
   if (addr_base != LLDB_INVALID_ADDRESS)
 SetAddrBase(addr_base);
 
-  SetRangesBase(cu_die.GetAttributeValueAsUnsigned(m_dwarf, this,
-   DW_AT_rnglists_base, 0));
+  dw_addr_t ranges_base = cu_die.GetAttributeValueAsUnsigned(
+  m_dwarf, this, DW_AT_rnglists_base, LLDB_INVALID_ADDRESS);
+  if (ranges_base != LLDB_INVALID_ADDRESS)
+

[Lldb-commits] [lldb] r347859 - [LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwo

[George Rimar via lldb-commits]

Author: grimar
Date: Thu Nov 29 04:44:10 2018
New Revision: 347859

URL: http://llvm.org/viewvc/llvm-project?rev=347859=rev
Log:
[LLDB] - Improve the support of .debug_str_offsets/.debug_str_offsets.dwo

A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
that points to the first string offset of the CU contribution to the
.debug_str_offsets. At the same time, when we use split dwarf,
the corresponding split debug unit also
may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo.
In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB
still need to know and skip the .debug_str_offsets.dwo section header to
access the offsets.

The patch implements the support of DW_AT_str_offsets_base.

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

Added:

lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml

lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file2.dwo.yaml
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-main.yaml
lldb/trunk/lit/Breakpoint/split-dwarf5-debug-stroffsets.test
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.h

Added: 
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml?rev=347859=auto
==
--- 
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml 
(added)
+++ 
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file1.dwo.yaml 
Thu Nov 29 04:44:10 2018
@@ -0,0 +1,40 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_REL
+  Machine: EM_X86_64
+Sections:
+  - Name:.debug_loc.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: ''
+  - Name:.debug_str_offsets.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
5C0005000A002D0037004000500052005A0060006200660076007F0084008A008F009400960099009C00A500B500
+  - Name:.debug_str.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE, SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x0001
+Content: 
66696C65312E64776F00636C616E672076657273696F6E20382E302E3020287472756E6B20333437323939290066696C65312E637070007E73747275637431005F5A4E37737472756374313166457600660073747275637431005F5A316776006700696E74005F5A4E377374727563743144324576005F5A347465737476007465737400666C6F6174006D61696E00746869730078007331007332007E73747275637432005F5A4E377374727563743231664576007374727563743200
+  - Name:.debug_info.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
D900050005088D03E0CB5B41F18901000104000202000B00015607080103B400030406010201040302020540060405020300072A00080132000156580001070A390291780FBC000A000B029174100108B4000C0206000156010B3A000203090001560B0C010DB8000D046E0001560E0111B4000B0291781101152A000B029170120116C10E0905040E0D0404072A000304150102060413020705D706140502080007C1
+  - Name:.debug_abbrev.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
011101B04225252513050325022E00111B120640186E2503253A0B3B0B49133F19031301360B03250B0B3A0B3B0B042E0103253A0B3B0B3C193F1905050049133419062E006E2503253A0B3B0B3C193F19070F004913082E0B1206401864133A0B3B0B6E25471309050002180325491334190A0B0155230B3400021803253A0B3B0B49130C2E00111B120640183A0B3B0B47130D2E0B1206401803253A0B3B0B49133F190E240003253E0B0B0B00
+  - Name:.debug_rnglists.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 150005000800010004000101040C1F04253200
+Symbols: {}
+DynamicSymbols:  {}
+...

Added: 
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file2.dwo.yaml
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/Inputs/split-dwarf5-debug-stroffsets-file2.dwo.yaml?rev=347859=auto
==
--- 

[Lldb-commits] [lldb] r347855 - Fix windows build broken by r347846

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu Nov 29 03:53:12 2018
New Revision: 347855

URL: http://llvm.org/viewvc/llvm-project?rev=347855=rev
Log:
Fix windows build broken by r347846

The changed order of includes caused compile errors on MSVC due to
snprintf macro definition. snprintf should available since VS2015, and
the rest of the code seems to be able to use snprintf just fine without
this macro, so this removes it from the lldb driver as well.

Modified:
lldb/trunk/tools/driver/Platform.h

Modified: lldb/trunk/tools/driver/Platform.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Platform.h?rev=347855=347854=347855=diff
==
--- lldb/trunk/tools/driver/Platform.h (original)
+++ lldb/trunk/tools/driver/Platform.h Thu Nov 29 03:53:12 2018
@@ -60,7 +60,6 @@ struct timeval {
   long tv_usec;
 };
 typedef long pid_t;
-#define snprintf _snprintf
 #define PATH_MAX MAX_PATH
 #endif
 


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

[Lldb-commits] [PATCH] D54914: Add a generic build script for building test inferiors

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D54914#1311492 , @zturner wrote:

> I think it would be good to use the way dotest works as a starting point.  
> You can specify --arch, and then you can run the test on multiple arches this 
> way by running dotest several times in succession, each with different arch 
> flags.
>
> I think a --triple option could be useful in limited scenarios, but I think 
> that most of the use cases will not need it.  Most tests will probably want 
> to specify nothing at all and let the lit configuration pass the correct 
> information through.  Actually, I think this is the same with the --arch flag 
> though.  Because as soon as you specify something, then it limits the ability 
> of the test to run over and over with different parameters.


I am not sure about their relative ratio, but yes, I agree that we have (or 
want to have) two kinds of tests. One would specify the target and the other 
would not.

> Perhaps we could support *both* a --triple and a --arch flag.  Maybe we can 
> make the script error if they're both specified.  This would give each test 
> the capability to be written in the simplest way possible.

Yes, I suppose that would work


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

https://reviews.llvm.org/D54914



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

[Lldb-commits] [lldb] r347846 - Remove getopt includes from the driver

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu Nov 29 02:45:41 2018
New Revision: 347846

URL: http://llvm.org/viewvc/llvm-project?rev=347846=rev
Log:
Remove getopt includes from the driver

They are not needed now that we use LLVMOption for command-line parsing
thank you, Jonas).  This also allows us to avoid linking of lldbHost
into the driver which was breaking liblldb encapsulation.

(Technically, there is still a lldb/Host/windows/windows.h include which
is needed on windows, but this is a header-only wrapper for ,
so it is not necessary to link lldbHost for that. But ideally, that
should go away too.)

Modified:
lldb/trunk/tools/driver/CMakeLists.txt
lldb/trunk/tools/driver/Platform.h

Modified: lldb/trunk/tools/driver/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/CMakeLists.txt?rev=347846=347845=347846=diff
==
--- lldb/trunk/tools/driver/CMakeLists.txt (original)
+++ lldb/trunk/tools/driver/CMakeLists.txt Thu Nov 29 02:45:41 2018
@@ -2,23 +2,12 @@ set(LLVM_TARGET_DEFINITIONS Options.td)
 tablegen(LLVM Options.inc -gen-opt-parser-defs)
 add_public_tablegen_target(LLDBOptionsTableGen)
 
-if ((CMAKE_SYSTEM_NAME MATCHES "Windows") OR
-(CMAKE_SYSTEM_NAME MATCHES "NetBSD" ))
-  # These targets do not have getopt support, so they rely on the one provided 
by
-  # liblldb. However, getopt is not a part of the liblldb interface, so we have
-  # to link against the constituent libraries manually. Note that this is
-  # extremely scary as it introduces ODR violations, and it should go away as
-  # soon as possible.
-  set(host_lib lldbHost)
-endif()
-
 add_lldb_tool(lldb
   Driver.cpp
   Platform.cpp
 
   LINK_LIBS
 liblldb
-${host_lib}
 
   LINK_COMPONENTS
 Option

Modified: lldb/trunk/tools/driver/Platform.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Platform.h?rev=347846=347845=347846=diff
==
--- lldb/trunk/tools/driver/Platform.h (original)
+++ lldb/trunk/tools/driver/Platform.h Thu Nov 29 02:45:41 2018
@@ -12,7 +12,6 @@
 
 #if defined(_WIN32)
 
-#include "lldb/Host/HostGetOpt.h"
 #include 
 #if defined(_MSC_VER)
 #include 
@@ -74,7 +73,6 @@ extern int tcsetattr(int fd, int optiona
 extern int tcgetattr(int fildes, struct termios *termios_p);
 
 #else
-#include "lldb/Host/HostGetOpt.h"
 #include 
 
 #include 


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

[Lldb-commits] [PATCH] D55038: [Reproducers] Change how reproducers are initialized.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I have a lot of comments, but I think they're mostly cosmetic. I think the 
general idea here is good.




Comment at: include/lldb/API/SBInitializerOptions.h:15
+#include "lldb/API/SBFileSpec.h"
+#include "lldb/Initialization/SystemInitializer.h"
+

You cannot include non-API headers from SB headers (cpp files are fine). 
`SystemInitializer::Options` needs to forward-declared. (I guess that means 
moving it out of the SystemInitializer class).



Comment at: include/lldb/API/SBInitializerOptions.h:17
+
+#include 
+

not needed?



Comment at: include/lldb/API/SBInitializerOptions.h:32
+
+  mutable std::unique_ptr 
m_opaque_up;
+};

I think this will make the copy-constructor of this class deleted, which will 
not play well with python. I think you'll need to declare your own copy 
operations here (something like SBExpressionOptions, I guess).

Also, why is this `mutable`? SBExpressionOptions seems to have that too, but 
it's not clear to me why would that be needed?



Comment at: include/lldb/Initialization/SystemInitializer.h:28
+
+  virtual void Initialize(Options options) = 0;
   virtual void Terminate() = 0;

`const Options &` ? (it contains a string so it's not trivial to copy).



Comment at: lit/Reproducer/TestGDBRemoteRepro.test:7
+
+# RUN: %clang %S/Inputs/simple.c -g -o %t.out --target=x86_64-apple-macosx
+# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %T/reproducer -- 
%t.out | FileCheck %s --check-prefix CHECK --check-prefix REPLAY

With  `--target` this test will not run on other platforms. This sounds like it 
should work on platforms using gdb-remote (i.e., mac & linux). Maybe remove the 
--target and set an appropriate REQUIRES directive.



Comment at: lit/Reproducer/TestGDBRemoteRepro.test:8
+# RUN: %clang %S/Inputs/simple.c -g -o %t.out --target=x86_64-apple-macosx
+# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture %T/reproducer -- 
%t.out | FileCheck %s --check-prefix CHECK --check-prefix REPLAY
+# RUN: %lldb -x -b -s %S/Inputs/GDBRemoteReplay.in --replay %T/reproducer -- 
%t.out | FileCheck %s --check-prefix CHECK --check-prefix REPLAY

`s/REPLAY/CAPTURE` ?



Comment at: scripts/interface/SBInitializerOptions.i:15
+public:
+SBInitializerOptions ();
+

Weird formatting.



Comment at: source/Initialization/SystemInitializerCommon.cpp:74
+
+  Reproducer::Initialize(mode, FileSpec(options.reproducer_path.c_str()));
   FileSystem::Initialize();

remove `.c_str()`



Comment at: source/Utility/Reproducer.cpp:41-42
+Reproducer::Reproducer(ReproducerMode mode, llvm::Optional root) {
+  // It's unfortunate that we have to do so much I/O here that can fail. The
+  // best we can do is not initialize the reproducer.
+  switch (mode) {

It should be possible to bubble this all the way up to the 
`SBDebugger::Initialize` call. Is there a reason to not do that?



Comment at: tools/driver/CMakeLists.txt:21
 liblldb
+lldbUtility
 ${host_lib}

This is wrong. The driver should only  use the public API exposed via liblldb. 
Why did you need to do that?



Comment at: unittests/Utility/ReproducerTest.cpp:39-43
+  llvm::Error SetCapture(bool b) { return Reproducer::SetCapture(b); }
+
+  llvm::Error SetReplay(llvm::Optional root) {
+return Reproducer::SetReplay(root);
+  }

You should be able to change the visibility of these via `using` directives. 
(`using Reproducer::SetCapture`).


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D55038



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

[Lldb-commits] [PATCH] D54751: [LLDB] - Fix setting the breakpoints when -gsplit-dwarf and DWARF 5 were used for building the executable.

[George Rimar via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB347842: [LLDB] - Fix setting the breakpoints when 
-gsplit-dwarf and DWARF 5 were used… (authored by grimar, committed by ).
Herald added subscribers: lldb-commits, teemperor, abidh.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D54751

Files:
  lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
  lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
  lit/Breakpoint/split-dwarf-5-addrbase.test
  source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp

Index: source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -307,8 +307,11 @@
 
 // m_die_array_mutex must be already held as read/write.
 void DWARFUnit::AddUnitDIE(const DWARFDebugInfoEntry _die) {
-  SetAddrBase(
-  cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_addr_base, 0));
+  dw_addr_t addr_base = cu_die.GetAttributeValueAsUnsigned(
+  m_dwarf, this, DW_AT_addr_base, LLDB_INVALID_ADDRESS);
+  if (addr_base != LLDB_INVALID_ADDRESS)
+SetAddrBase(addr_base);
+
   SetRangesBase(cu_die.GetAttributeValueAsUnsigned(m_dwarf, this,
DW_AT_rnglists_base, 0));
 
@@ -342,8 +345,15 @@
 
   m_dwo_symbol_file = std::move(dwo_symbol_file);
 
-  dw_addr_t addr_base =
-  cu_die.GetAttributeValueAsUnsigned(m_dwarf, this, DW_AT_GNU_addr_base, 0);
+  // Here for DWO CU we want to use the address base set in the skeleton unit
+  // (DW_AT_addr_base) if it is available and use the DW_AT_GNU_addr_base
+  // otherwise. We do that because pre-DWARF v5 could use the DW_AT_GNU_*
+  // attributes which were applicable to the DWO units. The corresponding
+  // DW_AT_* attributes standardized in DWARF v5 are also applicable to the main
+  // unit in contrast.
+  if (addr_base == LLDB_INVALID_ADDRESS)
+addr_base = cu_die.GetAttributeValueAsUnsigned(m_dwarf, this,
+   DW_AT_GNU_addr_base, 0);
   dwo_cu->SetAddrBase(addr_base);
 
   dw_addr_t ranges_base = cu_die.GetAttributeValueAsUnsigned(
Index: lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
===
--- lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
+++ lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
@@ -0,0 +1,35 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_REL
+  Machine: EM_X86_64
+Sections:
+  - Name:.debug_loc.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: ''
+  - Name:.debug_str_offsets.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 250009002C0034003C0040004500
+  - Name:.debug_str.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE, SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x0001
+Content: 746573742E64776F00636C616E672076657273696F6E20382E302E3020287472756E6B203334373239392900746573742E6363005F5A3362617A760062617A006D61696E00696E7400
+  - Name:.debug_info.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 360005000508E93484C441B7E84A0100010400020200060001560304010103011C00015605010435000406050400
+  - Name:.debug_abbrev.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 011101B04225252513050325022E00111B120640186E2503253A0B3B0B3F19032E00111B1206401803253A0B3B0B49133F1904240003253E0B0B0B00
+Symbols: {}
+DynamicSymbols:  {}
+...
Index: lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
===
--- lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
+++ lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
@@ -0,0 +1,61 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_X86_64
+  Entry:   0x00400440
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x00400440
+AddressAlign:0x0010
+Content: 

[Lldb-commits] [lldb] r347842 - [LLDB] - Fix setting the breakpoints when -gsplit-dwarf and DWARF 5 were used for building the executable.

[George Rimar via lldb-commits]

Author: grimar
Date: Thu Nov 29 00:16:07 2018
New Revision: 347842

URL: http://llvm.org/viewvc/llvm-project?rev=347842=rev
Log:
[LLDB] - Fix setting the breakpoints when -gsplit-dwarf and DWARF 5 were used 
for building the executable.

The issue happens because starting from DWARF v5
DW_AT_addr_base attribute should be used
instead of DW_AT_GNU_addr_base. LLDB does not do that and
we end up reading the .debug_addr header as section content
(as addresses) instead of skipping it and reading the real addresses.
Then LLDB is unable to match 2 similar locations and
thinks they are different.

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

Added:
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
lldb/trunk/lit/Breakpoint/split-dwarf-5-addrbase.test
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp

Added: lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml?rev=347842=auto
==
--- lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml (added)
+++ lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.dwo.yaml Thu Nov 29 
00:16:07 2018
@@ -0,0 +1,35 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_REL
+  Machine: EM_X86_64
+Sections:
+  - Name:.debug_loc.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: ''
+  - Name:.debug_str_offsets.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
250009002C0034003C0040004500
+  - Name:.debug_str.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE, SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x0001
+Content: 
746573742E64776F00636C616E672076657273696F6E20382E302E3020287472756E6B203334373239392900746573742E6363005F5A3362617A760062617A006D61696E00696E7400
+  - Name:.debug_info.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
360005000508E93484C441B7E84A0100010400020200060001560304010103011C00015605010435000406050400
+  - Name:.debug_abbrev.dwo
+Type:SHT_PROGBITS
+Flags:   [ SHF_EXCLUDE ]
+AddressAlign:0x0001
+Content: 
011101B04225252513050325022E00111B120640186E2503253A0B3B0B3F19032E00111B1206401803253A0B3B0B49133F1904240003253E0B0B0B00
+Symbols: {}
+DynamicSymbols:  {}
+...

Added: lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml?rev=347842=auto
==
--- lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml (added)
+++ lldb/trunk/lit/Breakpoint/Inputs/split-dwarf-5-addrbase.yaml Thu Nov 29 
00:16:07 2018
@@ -0,0 +1,61 @@
+--- !ELF
+FileHeader:  
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_X86_64
+  Entry:   0x00400440
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+Address: 0x00400440
+AddressAlign:0x0010
+Content: 
31ED4989D15E4889E24883E4F0505449C7C0C005400048C7C15005400048C7C730054000E8B7FFF4660F1F4455B820204000483D202040004889E57417B84885C0740D5DBF20204000FFE00F1F445DC3660F1F44BE20204000554881EE202040004889E548C1FE034889F048C1E83F4801C648D1FE7415B84885C0740B5DBF20204000FFE00F1F005DC3660F1F44803D391B007517554889E5E87EFFC605271B015DC30F1F44F3C30F1F4000662E0F1F8400554889E55DEB89660F1F8400554889E55DC3662E0F1F8400554889E54883EC10C745FCE8DCFF31C04883C4105DC30F1F4000415741564189FF415541544C8D25A61855488D2DA618534989F64989D54C29E54883EC0848C1FD03E86FFE4885ED742031DB0F1F84004C89EA4C89F64489FF41FF14DC4883C3014839EB75EA4883C4085B5D415C415D415E415FC390662E0F1F8400F3C3
+  - Name:.debug_str_offsets
+Type:SHT_PROGBITS
+AddressAlign:0x0001
+Content: 0C0005000900
+  - Name:.debug_str
+Type:SHT_PROGBITS
+Flags:   [ SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x0001
+Content: