[Lldb-commits] [lldb] r368249 - [Materializer] Remove wrong SetSizeAndAlignmentFromType().

2019-08-07 Thread Davide Italiano via lldb-commits
Author: davide
Date: Wed Aug  7 20:15:48 2019
New Revision: 368249

URL: http://llvm.org/viewvc/llvm-project?rev=368249=rev
Log:
[Materializer] Remove wrong SetSizeAndAlignmentFromType().

This function is unused.  It's also wrong, because it computes
the size and the alignment of the type without asking the runtime,
so it doesn't work for any language that has one (e.g. swift).

One could consider re-implementing this passing an execution scope
context, and modifying GetTypeBitAlign() to do the right thing,
but given there are no uses, it's not really useful.

Modified:
lldb/trunk/include/lldb/Expression/Materializer.h
lldb/trunk/source/Expression/Materializer.cpp

Modified: lldb/trunk/include/lldb/Expression/Materializer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/Materializer.h?rev=368249=368248=368249=diff
==
--- lldb/trunk/include/lldb/Expression/Materializer.h (original)
+++ lldb/trunk/include/lldb/Expression/Materializer.h Wed Aug  7 20:15:48 2019
@@ -115,8 +115,6 @@ public:
 void SetOffset(uint32_t offset) { m_offset = offset; }
 
   protected:
-void SetSizeAndAlignmentFromType(CompilerType );
-
 uint32_t m_alignment;
 uint32_t m_size;
 uint32_t m_offset;

Modified: lldb/trunk/source/Expression/Materializer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/Materializer.cpp?rev=368249=368248=368249=diff
==
--- lldb/trunk/source/Expression/Materializer.cpp (original)
+++ lldb/trunk/source/Expression/Materializer.cpp Wed Aug  7 20:15:48 2019
@@ -45,20 +45,6 @@ uint32_t Materializer::AddStructMember(E
   return ret;
 }
 
-void Materializer::Entity::SetSizeAndAlignmentFromType(CompilerType ) {
-  if (llvm::Optional size = type.GetByteSize(nullptr))
-m_size = *size;
-
-  uint32_t bit_alignment = type.GetTypeBitAlign();
-
-  if (bit_alignment % 8) {
-bit_alignment += 8;
-bit_alignment &= ~((uint32_t)0x111u);
-  }
-
-  m_alignment = bit_alignment / 8;
-}
-
 class EntityPersistentVariable : public Materializer::Entity {
 public:
   EntityPersistentVariable(lldb::ExpressionVariableSP _variable_sp,


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


[Lldb-commits] [lldb] r368243 - [Utility] Remove unused function 'GetMatchSpanningIndices'

2019-08-07 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Wed Aug  7 18:44:03 2019
New Revision: 368243

URL: http://llvm.org/viewvc/llvm-project?rev=368243=rev
Log:
[Utility] Remove unused function 'GetMatchSpanningIndices'

Modified:
lldb/trunk/include/lldb/Utility/RegularExpression.h
lldb/trunk/source/Utility/RegularExpression.cpp

Modified: lldb/trunk/include/lldb/Utility/RegularExpression.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/RegularExpression.h?rev=368243=368242=368243=diff
==
--- lldb/trunk/include/lldb/Utility/RegularExpression.h (original)
+++ lldb/trunk/include/lldb/Utility/RegularExpression.h Wed Aug  7 18:44:03 2019
@@ -83,10 +83,6 @@ public:
 bool GetMatchAtIndex(llvm::StringRef s, uint32_t idx,
  llvm::StringRef _str) const;
 
-bool GetMatchSpanningIndices(llvm::StringRef s, uint32_t idx1,
- uint32_t idx2,
- llvm::StringRef _str) const;
-
   protected:
 std::vector
 m_matches; ///< Where parenthesized subexpressions results are stored

Modified: lldb/trunk/source/Utility/RegularExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/RegularExpression.cpp?rev=368243=368242=368243=diff
==
--- lldb/trunk/source/Utility/RegularExpression.cpp (original)
+++ lldb/trunk/source/Utility/RegularExpression.cpp Wed Aug  7 18:44:03 2019
@@ -126,23 +126,6 @@ bool RegularExpression::Match::GetMatchA
   return false;
 }
 
-bool RegularExpression::Match::GetMatchSpanningIndices(
-llvm::StringRef s, uint32_t idx1, uint32_t idx2,
-llvm::StringRef _str) const {
-  if (idx1 < m_matches.size() && idx2 < m_matches.size()) {
-if (m_matches[idx1].rm_so == m_matches[idx2].rm_eo) {
-  // Matched the empty string...
-  match_str = llvm::StringRef();
-  return true;
-} else if (m_matches[idx1].rm_so < m_matches[idx2].rm_eo) {
-  match_str = s.substr(m_matches[idx1].rm_so,
-   m_matches[idx2].rm_eo - m_matches[idx1].rm_so);
-  return true;
-}
-  }
-  return false;
-}
-
 // Returns true if the regular expression compiled and is ready for execution.
 bool RegularExpression::IsValid() const { return m_comp_err == 0; }
 


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


[Lldb-commits] [PATCH] D65493: Modernize atomic detection and usage

2019-08-07 Thread Michael Spencer via Phabricator via lldb-commits
Bigcheese added a comment.

This looks like a good simplification, but I think `call_once` could be 
simplified more.




Comment at: llvm/cmake/modules/CheckAtomic.cmake:46
+  if (NOT HAVE_ATOMICS_WITH_LIB)
+   message(FATAL_ERROR "Host compiler must support atomic!")
   endif()

Indentation?



Comment at: llvm/cmake/modules/CheckAtomic.cmake:75
 
-## TODO: This define is only used for the legacy atomic operations in
-## llvm's Atomic.h, which should be replaced.  Other code simply
-## assumes C++11  works.
-CHECK_CXX_SOURCE_COMPILES("
-#ifdef _MSC_VER
-#include 
-#endif
-int main() {
-#ifdef _MSC_VER
-volatile LONG val = 1;
-MemoryBarrier();
-InterlockedCompareExchange(, 0, 1);
-InterlockedIncrement();
-InterlockedDecrement();
-#else
-volatile unsigned long val = 1;
-__sync_synchronize();
-__sync_val_compare_and_swap(, 1, 0);
-__sync_add_and_fetch(, 1);
-__sync_sub_and_fetch(, 1);
-#endif
-return 0;
-  }
-" LLVM_HAS_ATOMICS)
-
 if( NOT LLVM_HAS_ATOMICS )
   message(STATUS "Warning: LLVM will be built thread-unsafe because atomic 
builtins are missing")

Does anything else set `LLVM_HAS_ATOMICS`?



Comment at: llvm/include/llvm/Support/Threading.h:111
+  std::atomic_thread_fence(std::memory_order_seq_cst);
   TsanIgnoreWritesBegin();
   TsanHappensBefore();

Not sure we still need the tsan hooks when using `std::atomic`.



Comment at: llvm/include/llvm/Support/Threading.h:118
+  InitStatus tmp = flag.status;
+  std::atomic_thread_fence(std::memory_order_seq_cst);
   while (tmp != Done) {

Do we actually need thread fences here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65493



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


[Lldb-commits] [lldb] r368233 - [Docs] Fix (incorrect) code highlighting

2019-08-07 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Wed Aug  7 16:12:40 2019
New Revision: 368233

URL: http://llvm.org/viewvc/llvm-project?rev=368233=rev
Log:
[Docs] Fix (incorrect) code highlighting

Modified:
lldb/trunk/docs/use/symbolication.rst

Modified: lldb/trunk/docs/use/symbolication.rst
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/use/symbolication.rst?rev=368233=368232=368233=diff
==
--- lldb/trunk/docs/use/symbolication.rst (original)
+++ lldb/trunk/docs/use/symbolication.rst Wed Aug  7 16:12:40 2019
@@ -15,7 +15,7 @@ other symbolication programs:
 
 The simplest form of symbolication is to load an executable:
 
-::
+.. code-block:: text
 
(lldb) target create --no-dependents --arch x86_64 /tmp/a.out
 
@@ -30,7 +30,7 @@ Using the ``image list`` command will sh
 associated with the current target. As expected, we currently only have a
 single binary:
 
-::
+.. code-block:: text
 
(lldb) image list
[  0] 73431214-6B76-3489-9557-5075F03E36B4 0x0001 /tmp/a.out
@@ -38,7 +38,7 @@ single binary:
 
 Now we can look up an address:
 
-::
+.. code-block:: text
 
(lldb) image lookup --address 0x10aa3
  Address: a.out[0x00010aa3] (a.out.__TEXT.__text + 131)
@@ -51,7 +51,7 @@ address refers to a virtual address as d
 If we didn't use the ``--no-dependents`` option with ``target create``, we
 would have loaded all dependent shared libraries:
 
-::
+.. code-block:: text
 
(lldb) image list
[  0] 73431214-6B76-3489-9557-5075F03E36B4 0x0001 /tmp/a.out
@@ -64,7 +64,7 @@ would have loaded all dependent shared l
 Now if we do a lookup using a file address, this can result in multiple matches
 since most shared libraries have a virtual address space that starts at zero:
 
-::
+.. code-block:: text
 
(lldb) image lookup -a 0x1000
  Address: a.out[0x1000] (a.out.__PAGEZERO + 4096)
@@ -82,7 +82,7 @@ since most shared libraries have a virtu
 To avoid getting multiple file address matches, you can specify the name of the
 shared library to limit the search:
 
-::
+.. code-block:: text
 
(lldb) image lookup -a 0x1000 a.out
  Address: a.out[0x1000] (a.out.__PAGEZERO + 4096)
@@ -101,7 +101,7 @@ load --slide`` command allows us to set
 Below is an example of sliding all sections in a.out by adding 0x123000 to each
 section's file address:
 
-::
+.. code-block:: text
 
(lldb) target create --no-dependents --arch x86_64 /tmp/a.out
(lldb) target modules load --file a.out --slide 0x123000
@@ -116,7 +116,7 @@ segment with ``target modules load secti
 calculations. To specify the load addresses of sections we can specify one or
 more section name + address pairs in the ``target modules load`` command:
 
-::
+.. code-block:: text
 
(lldb) target create --no-dependents --arch x86_64 /tmp/a.out
(lldb) target modules load --file a.out __TEXT 0x100123000
@@ -126,7 +126,7 @@ defined where sections have been loaded
 now use load addresses so we don't have to do any math on the addresses in the
 crashlog backtraces, we can just use the raw addresses:
 
-::
+.. code-block:: text
 
(lldb) image lookup --address 0x100123aa3
  Address: a.out[0x00010aa3] (a.out.__TEXT.__text + 131)
@@ -142,7 +142,7 @@ one of the shared libraries, then add mo
 
 Lets say we have a Darwin crash log that contains the following images:
 
-::
+.. code-block:: text
 
Binary Images:
   0x1 -0x10ff7  
/tmp/a.out
@@ -153,7 +153,7 @@ Lets say we have a Darwin crash log that
 First we create the target using the main executable and then add any extra
 shared libraries we want:
 
-::
+.. code-block:: text
 
(lldb) target create --no-dependents --arch x86_64 /tmp/a.out
(lldb) target modules add /usr/lib/system/libsystem_c.dylib
@@ -165,7 +165,7 @@ If you have debug symbols in standalone
 you can specify their paths using the --symfile option for the ``target 
create``
 (recent LLDB releases only) and ``target modules add`` commands:
 
-::
+.. code-block:: text
 
(lldb) target create --no-dependents --arch x86_64 /tmp/a.out --symfile 
/tmp/a.out.dSYM
(lldb) target modules add /usr/lib/system/libsystem_c.dylib --symfile 
/build/server/a/libsystem_c.dylib.dSYM
@@ -176,7 +176,7 @@ Then we set the load addresses for each
 load addresses above and below) using the first address from the Binary Images
 section for each image:
 
-::
+.. code-block:: text
 
(lldb) target modules load --file a.out 0x1
(lldb) target modules load --file libsystem_c.dylib 0x7fff83f32000
@@ -189,7 +189,7 @@ using ``image lookup`` with the raw back
 
 Given the following raw backtrace:
 
-::
+.. code-block:: text
 
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff8a1e6d46 __kill + 10
@@ -200,7 +200,7 @@ Given the following raw backtrace:
 
 We can now symbolicate the 

[Lldb-commits] [PATCH] D65910: Remove unused and undocumented data_offset parameter

2019-08-07 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl created this revision.
aprantl added reviewers: jingham, clayborg, labath, jasonmolenda.
Herald added a project: LLDB.
aprantl updated this revision to Diff 214024.

Value::GetValueAsData() takes an undocumented parameter called data_offset that 
is always 0. I couldn't figure out what it is supposed to be used for and it is 
never used, so here's a patch to remove it.


https://reviews.llvm.org/D65910

Files:
  lldb/include/lldb/Core/Value.h
  lldb/source/Core/Value.cpp
  lldb/source/Core/ValueObject.cpp
  lldb/source/Core/ValueObjectCast.cpp
  lldb/source/Core/ValueObjectChild.cpp
  lldb/source/Core/ValueObjectConstResult.cpp
  lldb/source/Core/ValueObjectDynamicValue.cpp
  lldb/source/Core/ValueObjectMemory.cpp
  lldb/source/Core/ValueObjectSyntheticFilter.cpp
  lldb/source/Core/ValueObjectVariable.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp

Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
@@ -543,7 +543,7 @@
 Status error;
 DataExtractor data;
 error = argument_values.GetValueAtIndex(0)->GetValueAsData(_ctx, data,
-   0, nullptr);
+   nullptr);
 lldb::offset_t offset = 0;
 lldb::addr_t region_addr = data.GetPointer();
 
Index: lldb/source/Core/ValueObjectVariable.cpp
===
--- lldb/source/Core/ValueObjectVariable.cpp
+++ lldb/source/Core/ValueObjectVariable.cpp
@@ -221,7 +221,7 @@
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
 m_error =
-m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 break;
 
   case Value::eValueTypeFileAddress:
@@ -250,7 +250,7 @@
   Value value(m_value);
   value.SetContext(Value::eContextTypeVariable, variable);
   m_error =
-  value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  value.GetValueAsData(_ctx, m_data, GetModule().get());
 
   SetValueDidChange(value_type != old_value.GetValueType() ||
 m_value.GetScalar() != old_value.GetScalar());
Index: lldb/source/Core/ValueObjectSyntheticFilter.cpp
===
--- lldb/source/Core/ValueObjectSyntheticFilter.cpp
+++ lldb/source/Core/ValueObjectSyntheticFilter.cpp
@@ -320,7 +320,7 @@
 void ValueObjectSynthetic::CopyValueData(ValueObject *source) {
   m_value = (source->UpdateValueIfNeeded(), source->GetValue());
   ExecutionContext exe_ctx(GetExecutionContextRef());
-  m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 }
 
 bool ValueObjectSynthetic::CanProvideValue() {
Index: lldb/source/Core/ValueObjectMemory.cpp
===
--- lldb/source/Core/ValueObjectMemory.cpp
+++ lldb/source/Core/ValueObjectMemory.cpp
@@ -168,7 +168,7 @@
 case Value::eValueTypeScalar:
   // The variable value is in the Scalar value inside the m_value. We can
   // point our m_data right to it.
-  m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
   break;
 
 case Value::eValueTypeFileAddress:
@@ -209,7 +209,7 @@
   value.SetCompilerType(m_compiler_type);
 }
 
-m_error = value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = value.GetValueAsData(_ctx, m_data, GetModule().get());
   }
   break;
 }
Index: lldb/source/Core/ValueObjectDynamicValue.cpp
===
--- lldb/source/Core/ValueObjectDynamicValue.cpp
+++ lldb/source/Core/ValueObjectDynamicValue.cpp
@@ -199,7 +199,7 @@
 ClearDynamicTypeInformation();
 m_dynamic_type_info.Clear();
 m_value = m_parent->GetValue();
-m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 return m_error.Success();
   }
 
@@ -249,7 +249,7 @@
   if (m_address.IsValid() && m_dynamic_type_info) {
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
-m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 if 

[Lldb-commits] [PATCH] D65910: Remove unused and undocumented data_offset parameter

2019-08-07 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl updated this revision to Diff 214024.

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

https://reviews.llvm.org/D65910

Files:
  lldb/include/lldb/Core/Value.h
  lldb/source/Core/Value.cpp
  lldb/source/Core/ValueObject.cpp
  lldb/source/Core/ValueObjectCast.cpp
  lldb/source/Core/ValueObjectChild.cpp
  lldb/source/Core/ValueObjectConstResult.cpp
  lldb/source/Core/ValueObjectDynamicValue.cpp
  lldb/source/Core/ValueObjectMemory.cpp
  lldb/source/Core/ValueObjectSyntheticFilter.cpp
  lldb/source/Core/ValueObjectVariable.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp

Index: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
===
--- lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
+++ lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp
@@ -543,7 +543,7 @@
 Status error;
 DataExtractor data;
 error = argument_values.GetValueAtIndex(0)->GetValueAsData(_ctx, data,
-   0, nullptr);
+   nullptr);
 lldb::offset_t offset = 0;
 lldb::addr_t region_addr = data.GetPointer();
 
Index: lldb/source/Core/ValueObjectVariable.cpp
===
--- lldb/source/Core/ValueObjectVariable.cpp
+++ lldb/source/Core/ValueObjectVariable.cpp
@@ -221,7 +221,7 @@
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
 m_error =
-m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 break;
 
   case Value::eValueTypeFileAddress:
@@ -250,7 +250,7 @@
   Value value(m_value);
   value.SetContext(Value::eContextTypeVariable, variable);
   m_error =
-  value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  value.GetValueAsData(_ctx, m_data, GetModule().get());
 
   SetValueDidChange(value_type != old_value.GetValueType() ||
 m_value.GetScalar() != old_value.GetScalar());
Index: lldb/source/Core/ValueObjectSyntheticFilter.cpp
===
--- lldb/source/Core/ValueObjectSyntheticFilter.cpp
+++ lldb/source/Core/ValueObjectSyntheticFilter.cpp
@@ -320,7 +320,7 @@
 void ValueObjectSynthetic::CopyValueData(ValueObject *source) {
   m_value = (source->UpdateValueIfNeeded(), source->GetValue());
   ExecutionContext exe_ctx(GetExecutionContextRef());
-  m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 }
 
 bool ValueObjectSynthetic::CanProvideValue() {
Index: lldb/source/Core/ValueObjectMemory.cpp
===
--- lldb/source/Core/ValueObjectMemory.cpp
+++ lldb/source/Core/ValueObjectMemory.cpp
@@ -168,7 +168,7 @@
 case Value::eValueTypeScalar:
   // The variable value is in the Scalar value inside the m_value. We can
   // point our m_data right to it.
-  m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+  m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
   break;
 
 case Value::eValueTypeFileAddress:
@@ -209,7 +209,7 @@
   value.SetCompilerType(m_compiler_type);
 }
 
-m_error = value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = value.GetValueAsData(_ctx, m_data, GetModule().get());
   }
   break;
 }
Index: lldb/source/Core/ValueObjectDynamicValue.cpp
===
--- lldb/source/Core/ValueObjectDynamicValue.cpp
+++ lldb/source/Core/ValueObjectDynamicValue.cpp
@@ -199,7 +199,7 @@
 ClearDynamicTypeInformation();
 m_dynamic_type_info.Clear();
 m_value = m_parent->GetValue();
-m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 return m_error.Success();
   }
 
@@ -249,7 +249,7 @@
   if (m_address.IsValid() && m_dynamic_type_info) {
 // The variable value is in the Scalar value inside the m_value. We can
 // point our m_data right to it.
-m_error = m_value.GetValueAsData(_ctx, m_data, 0, GetModule().get());
+m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
 if (m_error.Success()) {
   if (!CanProvideValue()) {
 // this value object represents an aggregate type whose children have
Index: lldb/source/Core/ValueObjectConstResult.cpp
===
--- 

[Lldb-commits] [PATCH] D65492: Adjust a ValueObjectChild's offset when the child is a bitfield

2019-08-07 Thread Phabricator via Phabricator via lldb-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368226: Adjust a ValueObjectChilds offset when the 
child is a bitfield (authored by adrian, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65492?vs=212476=214021#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65492

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
  lldb/trunk/source/Core/ValueObjectChild.cpp


Index: 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
@@ -146,6 +146,9 @@
 '(uint8_t:1) b17 = \'\\0\'',
 ])
 
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+
 
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
@@ -90,6 +90,14 @@
 packed.b = 10;
 packed.c = 0x7112233;
 
+struct LargePackedBits {
+unsigned long a: 36;
+unsigned long b: 36;
+} __attribute__((packed));
+
+struct LargePackedBits large_packed =
+  (struct LargePackedBits){ 0xc, 0xd };
+
 return 0;    Set break point at this line.
 
 }
Index: lldb/trunk/source/Core/ValueObjectChild.cpp
===
--- lldb/trunk/source/Core/ValueObjectChild.cpp
+++ lldb/trunk/source/Core/ValueObjectChild.cpp
@@ -175,6 +175,30 @@
 // Set this object's scalar value to the address of its value by
 // adding its byte offset to the parent address
 m_value.GetScalar() += GetByteOffset();
+
+// If a bitfield doesn't fit into the child_byte_size'd
+// window at child_byte_offset, move the window forward
+// until it fits.  The problem here is that Value has no
+// notion of bitfields and thus the Value's DataExtractor
+// is sized like the bitfields CompilerType; a sequence of
+// bitfields, however, can be larger than their underlying
+// type.
+if (m_bitfield_bit_offset) {
+  const bool thread_and_frame_only_if_stopped = true;
+  ExecutionContext exe_ctx(GetExecutionContextRef().Lock(
+  thread_and_frame_only_if_stopped));
+  if (auto type_bit_size = GetCompilerType().GetBitSize(
+  exe_ctx.GetBestExecutionContextScope())) {
+uint64_t bitfield_end =
+m_bitfield_bit_size + m_bitfield_bit_offset;
+if (bitfield_end > *type_bit_size) {
+  uint64_t overhang_bytes =
+  (bitfield_end - *type_bit_size + 7) / 8;
+  m_value.GetScalar() += overhang_bytes;
+  m_bitfield_bit_offset -= overhang_bytes * 8;
+}
+  }
+}
   }
 } break;
 


Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
@@ -146,6 +146,9 @@
 '(uint8_t:1) b17 = \'\\0\'',
 ])
 
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 0x000deee"])
+
 
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
@@ -90,6 +90,14 @@
 packed.b = 10;
 packed.c = 0x7112233;
 
+struct LargePackedBits {
+unsigned long a: 36;
+unsigned long b: 36;
+} __attribute__((packed));
+
+struct LargePackedBits large_packed =
+  (struct LargePackedBits){ 

[Lldb-commits] [lldb] r368226 - Adjust a ValueObjectChild's offset when the child is a bitfield

2019-08-07 Thread Adrian Prantl via lldb-commits
Author: adrian
Date: Wed Aug  7 15:40:05 2019
New Revision: 368226

URL: http://llvm.org/viewvc/llvm-project?rev=368226=rev
Log:
Adjust a ValueObjectChild's offset when the child is a bitfield

If a bitfield doesn't fit into the child_byte_size'd window at
child_byte_offset, move the window forward until it fits.  The problem
here is that Value has no notion of bitfields and thus the Value's
DataExtractor is sized like the bitfields CompilerType; a sequence of
bitfields, however, can be larger than their underlying type.

This was not in the big-endian-derived DWARF 2 bitfield attributes
because their offsets were counted from the end of the window, so they
always fit.

rdar://problem/53132189

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

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
lldb/trunk/source/Core/ValueObjectChild.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py?rev=368226=368225=368226=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py 
Wed Aug  7 15:40:05 2019
@@ -146,6 +146,9 @@ class BitfieldsTestCase(TestBase):
 '(uint8_t:1) b17 = \'\\0\'',
 ])
 
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+
 
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c?rev=368226=368225=368226=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/bitfields/main.c Wed Aug  
7 15:40:05 2019
@@ -90,6 +90,14 @@ int main (int argc, char const *argv[])
 packed.b = 10;
 packed.c = 0x7112233;
 
+struct LargePackedBits {
+unsigned long a: 36;
+unsigned long b: 36;
+} __attribute__((packed));
+
+struct LargePackedBits large_packed =
+  (struct LargePackedBits){ 0xc, 0xd };
+
 return 0;    Set break point at this line.
 
 }

Modified: lldb/trunk/source/Core/ValueObjectChild.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObjectChild.cpp?rev=368226=368225=368226=diff
==
--- lldb/trunk/source/Core/ValueObjectChild.cpp (original)
+++ lldb/trunk/source/Core/ValueObjectChild.cpp Wed Aug  7 15:40:05 2019
@@ -175,6 +175,30 @@ bool ValueObjectChild::UpdateValue() {
 // Set this object's scalar value to the address of its value by
 // adding its byte offset to the parent address
 m_value.GetScalar() += GetByteOffset();
+
+// If a bitfield doesn't fit into the child_byte_size'd
+// window at child_byte_offset, move the window forward
+// until it fits.  The problem here is that Value has no
+// notion of bitfields and thus the Value's DataExtractor
+// is sized like the bitfields CompilerType; a sequence of
+// bitfields, however, can be larger than their underlying
+// type.
+if (m_bitfield_bit_offset) {
+  const bool thread_and_frame_only_if_stopped = true;
+  ExecutionContext exe_ctx(GetExecutionContextRef().Lock(
+  thread_and_frame_only_if_stopped));
+  if (auto type_bit_size = GetCompilerType().GetBitSize(
+  exe_ctx.GetBestExecutionContextScope())) {
+uint64_t bitfield_end =
+m_bitfield_bit_size + m_bitfield_bit_offset;
+if (bitfield_end > *type_bit_size) {
+  uint64_t overhang_bytes =
+  (bitfield_end - *type_bit_size + 7) / 8;
+  m_value.GetScalar() += overhang_bytes;
+  m_bitfield_bit_offset -= overhang_bytes * 8;
+}
+  }
+}
   }
 } break;
 


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


[Lldb-commits] [lldb] r368208 - [CommandObject] Remove unused function

2019-08-07 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Wed Aug  7 13:56:17 2019
New Revision: 368208

URL: http://llvm.org/viewvc/llvm-project?rev=368208=rev
Log:
[CommandObject] Remove unused function

Modified:
lldb/trunk/source/Commands/CommandObjectCommands.cpp

Modified: lldb/trunk/source/Commands/CommandObjectCommands.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectCommands.cpp?rev=368208=368207=368208=diff
==
--- lldb/trunk/source/Commands/CommandObjectCommands.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectCommands.cpp Wed Aug  7 13:56:17 
2019
@@ -1296,8 +1296,6 @@ public:
 
   bool IsRemovable() const override { return true; }
 
-  StructuredData::GenericSP GetImplementingObject() { return m_cmd_obj_sp; }
-
   ScriptedCommandSynchronicity GetSynchronicity() { return m_synchro; }
 
   llvm::StringRef GetHelp() override {


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


[Lldb-commits] [lldb] r368205 - [Symbol] Remove commented out code from CompileUnit

2019-08-07 Thread Alex Langford via lldb-commits
Author: xiaobai
Date: Wed Aug  7 13:51:21 2019
New Revision: 368205

URL: http://llvm.org/viewvc/llvm-project?rev=368205=rev
Log:
[Symbol] Remove commented out code from CompileUnit

Modified:
lldb/trunk/source/Symbol/CompileUnit.cpp

Modified: lldb/trunk/source/Symbol/CompileUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/CompileUnit.cpp?rev=368205=368204=368205=diff
==
--- lldb/trunk/source/Symbol/CompileUnit.cpp (original)
+++ lldb/trunk/source/Symbol/CompileUnit.cpp Wed Aug  7 13:51:21 2019
@@ -119,49 +119,6 @@ void CompileUnit::AddFunction(FunctionSP
   m_functions_by_uid[funcSP->GetID()] = funcSP;
 }
 
-// Find functions using the Mangled::Tokens token list. This function currently
-// implements an interactive approach designed to find all instances of certain
-// functions. It isn't designed to the quickest way to lookup functions as it
-// will need to iterate through all functions and see if they match, though it
-// does provide a powerful and context sensitive way to search for all
-// functions with a certain name, all functions in a namespace, or all
-// functions of a template type. See Mangled::Tokens::Parse() comments for more
-// information.
-//
-// The function prototype will need to change to return a list of results. It
-// was originally used to help debug the Mangled class and the
-// Mangled::Tokens::MatchesQuery() function and it currently will print out a
-// list of matching results for the functions that are currently in this
-// compile unit.
-//
-// A FindFunctions method should be called prior to this that takes
-// a regular function name (const char * or ConstString as a parameter) before
-// resorting to this slower but more complete function. The other FindFunctions
-// method should be able to take advantage of any accelerator tables available
-// in the debug information (which is parsed by the SymbolFile parser plug-ins
-// and registered with each Module).
-// void
-// CompileUnit::FindFunctions(const Mangled::Tokens& tokens)
-//{
-//  if (!m_functions.empty())
-//  {
-//  Stream s(stdout);
-//  std::vector::const_iterator pos;
-//  std::vector::const_iterator end = m_functions.end();
-//  for (pos = m_functions.begin(); pos != end; ++pos)
-//  {
-//  const ConstString& demangled = (*pos)->Mangled().Demangled();
-//  if (demangled)
-//  {
-//  const Mangled::Tokens& func_tokens =
-//  (*pos)->Mangled().GetTokens();
-//  if (func_tokens.MatchesQuery (tokens))
-//  s << "demangled MATCH found: " << demangled << "\n";
-//  }
-//  }
-//  }
-//}
-
 FunctionSP CompileUnit::FindFunctionByUID(lldb::user_id_t func_uid) {
   auto it = m_functions_by_uid.find(func_uid);
   if (it == m_functions_by_uid.end())


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


[Lldb-commits] [PATCH] D65784: [lldb] delete "--platform-path" option from "target create"

2019-08-07 Thread Wanyi Ye via Phabricator via lldb-commits
kusmour added a comment.

In D65784#1616118 , @jasonmolenda 
wrote:

> Yeah, it's not currently hooked up to anything; I'm returning to 
> remote-platform testing soon, if we've lost some necessary functionality I 
> can re-add it, but this option right now isn't doing anything.


Thank you for your reply. Would  you like to merge this change? I can abandon 
it if you are going to work on this.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65784



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


[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

2019-08-07 Thread Joseph Tremoulet via Phabricator via lldb-commits
JosephTremoulet marked an inline comment as done.
JosephTremoulet added inline comments.



Comment at: lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:1760
+void RegisterContextLLDB::PropagateTrapHandlerFlag(
+lldb::UnwindPlanSP unwind_plan) {
+  if (unwind_plan->GetUnwindPlanForSignalTrap() != eLazyBoolYes) {

jasonmolenda wrote:
> clayborg wrote:
> > JosephTremoulet wrote:
> > > I'm a bit ambivalent about adding this part -- the downside is that it's 
> > > not concretely helping today, because if an eh_frame record has the 'S' 
> > > flag in its augmentation (which is what 
> > > `unwind_Plan->GetUnwindPlanForSignalTrap()` reports), we'll have already 
> > > decremented pc and generated unwind plans based on the prior function 
> > > when initializing the register context.  But the upside is that this 
> > > connects the dots between the otherwise-unused bit on the unwind plan and 
> > > the frame type, and will be in place should we subsequently add code to 
> > > try the second function's unwind plan as a fallback.
> > I will let Jason comment on this one.
> Yeah, this was my impression of the S augmentation flag in the eh_frame too 
> -- we can't really use it in lldb today without forcing a scan of eh_frame 
> entries the first time we unwind a function from that Module, and that would 
> be unfortunate.  But I like to see the flag being parsed and recorded; at 
> some point in the future we may find a good way to use it.
> Yeah, this was my impression of the S augmentation flag in the eh_frame too 
> -- we can't really use it in lldb today without forcing a scan of eh_frame 
> entries the first time we unwind a function from that Module

"Thinking out lout" a bit... we could consider doing the check only when the pc 
is at the very start of a function -- in that case, either it's one of these 
signal frames where it's worth paying the price to check eh_frame, or it's a 
call at the end of the previous function... am I understanding correctly that 
the non-signal case is specifically when a noreturn non-tail call gets laid out 
at the end of a function and there's no alignment padding between it and the 
next function?  I'd naively think that's an uncommon case, is there reason to 
believe otherwise?  I don't think this will be a high enough priority for me to 
actually investigate any time soon, but if I were going to investigate, do we 
have some standard test suite for assessing that sort of thing (either 
statically how often that code pattern happens or dynamically what slowdown is 
observed from a particular lldb source change)?

Thanks!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64993



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368199: Add support for deterministically linked binaries on 
macOS to lldb. (authored by nico, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65826?vs=213962=213967#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65826

Files:
  lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
+++ lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can 
still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -o "breakpoint set -f %s -l 11" -o run -o exit | FileCheck %s
+// CHECK: stop reason = breakpoint
+
+
+int main() { return 0; }


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
+++ lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -o "breakpoint set -f %s -l 11" -o run -o exit | FileCheck %s
+// CHECK: stop reason = breakpoint
+
+
+int main() { return 0; }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r368199 - Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Nico Weber via lldb-commits
Author: nico
Date: Wed Aug  7 12:29:04 2019
New Revision: 368199

URL: http://llvm.org/viewvc/llvm-project?rev=368199=rev
Log:
Add support for deterministically linked binaries on macOS to lldb.

When ld64 links a binary deterministically using the flag ZERO_AR_DATE,
it sets a timestamp of 0 for N_OSO members in the symtab section, rather
than the usual last modified date of the object file. Prior to this
patch, lldb would compare the timestamp from the N_OSO member against
the last modified date of the object file, and skip loading the object
file if there was a mismatch. This patch updates the logic to ignore the
timestamp check if the N_OSO member has timestamp 0.

The original logic was added in https://reviews.llvm.org/rL181631 as a
safety check to avoid problems when debugging if the object file was out
of date. This was prior to the introduction of deterministic build in
ld64. lld still doesn't support deterministic build.

Other code in llvm already relies on and uses the assumption that a
timestamp of 0 means deterministic build. For example, commit
9ccfddc39d4d27f9b16fcc72ab30d483151d6d08 adds similar timestamp checking
logic to dsymutil, but special cases timestamp 0. Likewise, commit
0d1bb79a0413f221432a7b1d0d2d10c84c4bbb99 adds a long comment describing
deterministic archive, which mostly uses timestamp 0 for determinism.

Patch from Erik Chen !

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

Added:
lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp

Added: lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp?rev=368199=auto
==
--- lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp (added)
+++ lldb/trunk/lit/SymbolFile/DWARF/deterministic-build.cpp Wed Aug  7 12:29:04 
2019
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can 
still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -o "breakpoint set -f %s -l 11" -o run -o exit | FileCheck %s
+// CHECK: stop reason = breakpoint
+
+
+int main() { return 0; }

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp?rev=368199=368198=368199=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp 
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp Wed 
Aug  7 12:29:04 2019
@@ -420,7 +420,11 @@ Module *SymbolFileDWARFDebugMap::GetModu
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"


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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Erik Chen via Phabricator via lldb-commits
erikchen added a comment.

I do not have commit access. Can someone land the change for me? Thanks.


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

https://reviews.llvm.org/D65826



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

Thanks, this LGTM!


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

https://reviews.llvm.org/D65826



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Erik Chen via Phabricator via lldb-commits
erikchen marked 3 inline comments as done.
erikchen added inline comments.



Comment at: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp:6
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -s %S/Inputs/deterministic-build.lldbinit -o exit | FileCheck 
%s
+// CHECK: int main() { return 0; }

labath wrote:
> erikchen wrote:
> > JDevlieghere wrote:
> > > If you check for `stop reason = breakpoint` instead of the source line, 
> > > you don't have to work around the comments getting printed. You wouldn't 
> > > even need an  input file anymore either.  
> > > 
> > > ```
> > > // RUN: %lldb %t -o "breakpoint set -name main" -o "run"  -o "exit" | 
> > > FileCheck %s
> > > // CHECK: stop reason = breakpoint
> > > ```
> > I'm sorry but I don't understand how that would work. Even if object file 
> > symbols aren't loaded, lldb is still able to set a breakpoint at main, e.g.:
> > 
> >  /Users/erikchen/projects/llvm-project/build/bin/lldb --no-lldbinit -S 
> > /Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init 
> > /Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp
> >  -o "breakpoint set -name main" -o "run"  -o "exit"
> > (lldb) command source -s 0 
> > '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'
> > Executing commands in 
> > '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'.
> > (lldb) # LLDB init file for the LIT tests.
> > (lldb) settings set symbols.enable-external-lookup false
> > (lldb) settings set plugin.process.gdb-remote.packet-timeout 60
> > (lldb) settings set interpreter.echo-comment-commands false
> > (lldb) target create 
> > "/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp"
> > Current executable set to 
> > '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
> >  (x86_64).
> > (lldb) breakpoint set -name main
> > error: deterministic-build.cpp.tmp debug map object file 
> > '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp.o'
> >  has changed (actual time is 2019-08-07 11:40:55.0, debug map time 
> > is 1969-12-31 16:00:00.0) since this executable was linked, file 
> > will be ignored
> > Breakpoint 1: where = deterministic-build.cpp.tmp`main, address = 
> > 0x00010fa0
> > (lldb) run
> > Process 18131 stopped
> > * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> > frame #0: 0x00010fa0 deterministic-build.cpp.tmp`main
> > deterministic-build.cpp.tmp`main:
> > ->  0x10fa0 <+0>: pushq  %rbp
> > 0x10fa1 <+1>: movq   %rsp, %rbp
> > 0x10fa4 <+4>: xorl   %eax, %eax
> > 0x10fa6 <+6>: movl   $0x0, -0x4(%rbp)
> > 
> > Process 18131 launched: 
> > '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
> >  (x86_64)
> > (lldb) exit
> > 
> Maybe you could set a file+line breakpoint instead of function one. That 
> would only work if line tables get parsed (which live in the .o file if I 
> know my MachO correctly). That way you wouldn't even have to run the process, 
> which means this test might one day work on other systems too (if/when lld is 
> able to link MachO files reasonably).
that worked, thanks. I've updated the patch.


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

https://reviews.llvm.org/D65826



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Erik Chen via Phabricator via lldb-commits
erikchen updated this revision to Diff 213962.

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

https://reviews.llvm.org/D65826

Files:
  lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can 
still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -o "breakpoint set -f %s -l 11" -o run -o exit | FileCheck %s
+// CHECK: stop reason = breakpoint
+
+
+int main() { return 0; }


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -o "breakpoint set -f %s -l 11" -o run -o exit | FileCheck %s
+// CHECK: stop reason = breakpoint
+
+
+int main() { return 0; }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp:6
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -s %S/Inputs/deterministic-build.lldbinit -o exit | FileCheck 
%s
+// CHECK: int main() { return 0; }

erikchen wrote:
> JDevlieghere wrote:
> > If you check for `stop reason = breakpoint` instead of the source line, you 
> > don't have to work around the comments getting printed. You wouldn't even 
> > need an  input file anymore either.  
> > 
> > ```
> > // RUN: %lldb %t -o "breakpoint set -name main" -o "run"  -o "exit" | 
> > FileCheck %s
> > // CHECK: stop reason = breakpoint
> > ```
> I'm sorry but I don't understand how that would work. Even if object file 
> symbols aren't loaded, lldb is still able to set a breakpoint at main, e.g.:
> 
>  /Users/erikchen/projects/llvm-project/build/bin/lldb --no-lldbinit -S 
> /Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init 
> /Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp
>  -o "breakpoint set -name main" -o "run"  -o "exit"
> (lldb) command source -s 0 
> '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'
> Executing commands in 
> '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'.
> (lldb) # LLDB init file for the LIT tests.
> (lldb) settings set symbols.enable-external-lookup false
> (lldb) settings set plugin.process.gdb-remote.packet-timeout 60
> (lldb) settings set interpreter.echo-comment-commands false
> (lldb) target create 
> "/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp"
> Current executable set to 
> '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
>  (x86_64).
> (lldb) breakpoint set -name main
> error: deterministic-build.cpp.tmp debug map object file 
> '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp.o'
>  has changed (actual time is 2019-08-07 11:40:55.0, debug map time is 
> 1969-12-31 16:00:00.0) since this executable was linked, file will be 
> ignored
> Breakpoint 1: where = deterministic-build.cpp.tmp`main, address = 
> 0x00010fa0
> (lldb) run
> Process 18131 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x00010fa0 deterministic-build.cpp.tmp`main
> deterministic-build.cpp.tmp`main:
> ->  0x10fa0 <+0>: pushq  %rbp
> 0x10fa1 <+1>: movq   %rsp, %rbp
> 0x10fa4 <+4>: xorl   %eax, %eax
> 0x10fa6 <+6>: movl   $0x0, -0x4(%rbp)
> 
> Process 18131 launched: 
> '/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
>  (x86_64)
> (lldb) exit
> 
Maybe you could set a file+line breakpoint instead of function one. That would 
only work if line tables get parsed (which live in the .o file if I know my 
MachO correctly). That way you wouldn't even have to run the process, which 
means this test might one day work on other systems too (if/when lld is able to 
link MachO files reasonably).


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

https://reviews.llvm.org/D65826



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Erik Chen via Phabricator via lldb-commits
erikchen marked an inline comment as done.
erikchen added inline comments.



Comment at: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp:6
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -s %S/Inputs/deterministic-build.lldbinit -o exit | FileCheck 
%s
+// CHECK: int main() { return 0; }

JDevlieghere wrote:
> If you check for `stop reason = breakpoint` instead of the source line, you 
> don't have to work around the comments getting printed. You wouldn't even 
> need an  input file anymore either.  
> 
> ```
> // RUN: %lldb %t -o "breakpoint set -name main" -o "run"  -o "exit" | 
> FileCheck %s
> // CHECK: stop reason = breakpoint
> ```
I'm sorry but I don't understand how that would work. Even if object file 
symbols aren't loaded, lldb is still able to set a breakpoint at main, e.g.:

 /Users/erikchen/projects/llvm-project/build/bin/lldb --no-lldbinit -S 
/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init 
/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp
 -o "breakpoint set -name main" -o "run"  -o "exit"
(lldb) command source -s 0 
'/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'
Executing commands in 
'/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/lit-lldb-init'.
(lldb) # LLDB init file for the LIT tests.
(lldb) settings set symbols.enable-external-lookup false
(lldb) settings set plugin.process.gdb-remote.packet-timeout 60
(lldb) settings set interpreter.echo-comment-commands false
(lldb) target create 
"/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp"
Current executable set to 
'/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
 (x86_64).
(lldb) breakpoint set -name main
error: deterministic-build.cpp.tmp debug map object file 
'/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp.o'
 has changed (actual time is 2019-08-07 11:40:55.0, debug map time is 
1969-12-31 16:00:00.0) since this executable was linked, file will be 
ignored
Breakpoint 1: where = deterministic-build.cpp.tmp`main, address = 
0x00010fa0
(lldb) run
Process 18131 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010fa0 deterministic-build.cpp.tmp`main
deterministic-build.cpp.tmp`main:
->  0x10fa0 <+0>: pushq  %rbp
0x10fa1 <+1>: movq   %rsp, %rbp
0x10fa4 <+4>: xorl   %eax, %eax
0x10fa6 <+6>: movl   $0x0, -0x4(%rbp)

Process 18131 launched: 
'/Users/erikchen/projects/llvm-project/build/tools/lldb/lit/SymbolFile/DWARF/Output/deterministic-build.cpp.tmp'
 (x86_64)
(lldb) exit



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

https://reviews.llvm.org/D65826



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


[Lldb-commits] [PATCH] D65826: Add support for deterministically linked binaries on macOS to lldb.

2019-08-07 Thread Erik Chen via Phabricator via lldb-commits
erikchen updated this revision to Diff 213960.
erikchen marked an inline comment as done.

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

https://reviews.llvm.org/D65826

Files:
  lldb/lit/SymbolFile/DWARF/Inputs/deterministic-build.lldbinit
  lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can 
still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -s %S/Inputs/deterministic-build.lldbinit -o exit | FileCheck 
%s
+// CHECK: int main() { return 0; }
+
+
+int main() { return 0; }
Index: lldb/lit/SymbolFile/DWARF/Inputs/deterministic-build.lldbinit
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/Inputs/deterministic-build.lldbinit
@@ -0,0 +1,7 @@
+# We intentionally don't want to pick up too many lines of context, since the
+# test file is also the source file, and that will pick up comments from the
+# test file.
+settings set stop-line-count-before 0
+settings set stop-line-count-after 1
+breakpoint set -name main
+run


Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -420,7 +420,11 @@
 // than the one from the CU.
 auto oso_mod_time = std::chrono::time_point_cast(
 FileSystem::Instance().GetModificationTime(oso_file));
-if (oso_mod_time != comp_unit_info->oso_mod_time) {
+// A timestamp of 0 means that the linker was in deterministic mode. In
+// that case, we should skip the check against the filesystem last
+// modification timestamp, since it will never match.
+if (comp_unit_info->oso_mod_time != llvm::sys::TimePoint<>() &&
+oso_mod_time != comp_unit_info->oso_mod_time) {
   obj_file->GetModule()->ReportError(
   "debug map object file '%s' has changed (actual time is "
   "%s, debug map time is %s"
Index: lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/deterministic-build.cpp
@@ -0,0 +1,11 @@
+// Test that binaries linked deterministically (N_OSO has timestamp 0) can still
+// have their object files loaded by lldb. Note that the env var ZERO_AR_DATE
+// requires the ld64 linker, which clang invokes by default.
+// REQUIRES: system-darwin
+// RUN: %clang %s -g -c -o %t.o
+// RUN: ZERO_AR_DATE=1 %clang %t.o -g -o %t
+// RUN: %lldb %t -s %S/Inputs/deterministic-build.lldbinit -o exit | FileCheck %s
+// CHECK: int main() { return 0; }
+
+
+int main() { return 0; }
Index: lldb/lit/SymbolFile/DWARF/Inputs/deterministic-build.lldbinit
===
--- /dev/null
+++ lldb/lit/SymbolFile/DWARF/Inputs/deterministic-build.lldbinit
@@ -0,0 +1,7 @@
+# We intentionally don't want to pick up too many lines of context, since the
+# test file is also the source file, and that will pick up comments from the
+# test file.
+settings set stop-line-count-before 0
+settings set stop-line-count-after 1
+breakpoint set -name main
+run
___
lldb-commits mailing list
lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D65864: Remove Module::GetSymbolVendor

2019-08-07 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision.
clayborg added a comment.

Optional rename in inline comments, but looks good.




Comment at: include/lldb/Core/Module.h:1006
   std::atomic m_did_load_objfile{false};
-  std::atomic m_did_load_symbol_vendor{false};
+  std::atomic m_did_load_symbol_file{false};
   std::atomic m_did_set_uuid{false};

maybe name "m_did_load_symfile"?


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

https://reviews.llvm.org/D65864



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


[Lldb-commits] [PATCH] D65872: [lldb][NFC] Check in test case for testing virtual function calls in pointers and references.

2019-08-07 Thread Davide Italiano via Phabricator via lldb-commits
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

I seem to remember there was a bug where you run the expression twice and the 
second time it crashes/it's not evaluated correctly [at least this is what I 
remember talking to Lang ~18 months ago].
If that works, yay for more coverage!


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65872



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


[Lldb-commits] [lldb] r368182 - [Driver] Expand the executable path in the target create output

2019-08-07 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Wed Aug  7 09:21:40 2019
New Revision: 368182

URL: http://llvm.org/viewvc/llvm-project?rev=368182=rev
Log:
[Driver] Expand the executable path in the target create output

Resolve the path in the target create output. This is nice when passing
relative paths to the lldb command line driver.

  $ lldb ./binary
  (lldb) target create "./binary"
  Current executable set to '/absolute/path/to/binary' (x86_64).

This change only affects the target create output and does not change
the debugger's behavior. It doesn't resolve symbolic links so it won't
cause confusing when debugging something like clang++ that's symlinked
to clang.

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

Added:
lldb/trunk/lit/Driver/TestTarget.test
Modified:
lldb/trunk/source/Commands/CommandObjectTarget.cpp

Added: lldb/trunk/lit/Driver/TestTarget.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Driver/TestTarget.test?rev=368182=auto
==
--- lldb/trunk/lit/Driver/TestTarget.test (added)
+++ lldb/trunk/lit/Driver/TestTarget.test Wed Aug  7 09:21:40 2019
@@ -0,0 +1,7 @@
+# Make sure lldb resolves the target path.
+# RUN: mkdir -p %t/foo
+# RUN: cd %t/foo
+# RUN: %clang %p/Inputs/hello.c -g -o a.out
+# RUN: %lldb -b a.out | FileCheck %s
+
+# CHECK: Current executable set to '{{.*}}foo{{[/]+}}a.out'

Modified: lldb/trunk/source/Commands/CommandObjectTarget.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectTarget.cpp?rev=368182=368181=368182=diff
==
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp Wed Aug  7 09:21:40 2019
@@ -450,7 +450,8 @@ protected:
   }
 } else {
   result.AppendMessageWithFormat(
-  "Current executable set to '%s' (%s).\n", file_path,
+  "Current executable set to '%s' (%s).\n",
+  file_spec.GetPath().c_str(),
   target_sp->GetArchitecture().GetArchitectureName());
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
 }


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


[Lldb-commits] [PATCH] D65611: [Driver] Expand the executable path in the target create output

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368182: [Driver] Expand the executable path in the target 
create output (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65611?vs=213640=213924#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65611

Files:
  lldb/trunk/lit/Driver/TestTarget.test
  lldb/trunk/source/Commands/CommandObjectTarget.cpp


Index: lldb/trunk/lit/Driver/TestTarget.test
===
--- lldb/trunk/lit/Driver/TestTarget.test
+++ lldb/trunk/lit/Driver/TestTarget.test
@@ -0,0 +1,7 @@
+# Make sure lldb resolves the target path.
+# RUN: mkdir -p %t/foo
+# RUN: cd %t/foo
+# RUN: %clang %p/Inputs/hello.c -g -o a.out
+# RUN: %lldb -b a.out | FileCheck %s
+
+# CHECK: Current executable set to '{{.*}}foo{{[/]+}}a.out'
Index: lldb/trunk/source/Commands/CommandObjectTarget.cpp
===
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp
@@ -450,7 +450,8 @@
   }
 } else {
   result.AppendMessageWithFormat(
-  "Current executable set to '%s' (%s).\n", file_path,
+  "Current executable set to '%s' (%s).\n",
+  file_spec.GetPath().c_str(),
   target_sp->GetArchitecture().GetArchitectureName());
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
 }


Index: lldb/trunk/lit/Driver/TestTarget.test
===
--- lldb/trunk/lit/Driver/TestTarget.test
+++ lldb/trunk/lit/Driver/TestTarget.test
@@ -0,0 +1,7 @@
+# Make sure lldb resolves the target path.
+# RUN: mkdir -p %t/foo
+# RUN: cd %t/foo
+# RUN: %clang %p/Inputs/hello.c -g -o a.out
+# RUN: %lldb -b a.out | FileCheck %s
+
+# CHECK: Current executable set to '{{.*}}foo{{[/]+}}a.out'
Index: lldb/trunk/source/Commands/CommandObjectTarget.cpp
===
--- lldb/trunk/source/Commands/CommandObjectTarget.cpp
+++ lldb/trunk/source/Commands/CommandObjectTarget.cpp
@@ -450,7 +450,8 @@
   }
 } else {
   result.AppendMessageWithFormat(
-  "Current executable set to '%s' (%s).\n", file_path,
+  "Current executable set to '%s' (%s).\n",
+  file_spec.GetPath().c_str(),
   target_sp->GetArchitecture().GetArchitectureName());
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D65874: [lldb][CMake] Disable modules in Xcode projects

2019-08-07 Thread Davide Italiano via Phabricator via lldb-commits
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

You might want to check with Argyrios, maybe file a rdar against SourceKit.
Otherwise, this is fine to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65874



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


[Lldb-commits] [PATCH] D48704: [ExecutionContext] Return the target/process byte order.

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368181: [ExecutionContext] Return the target/process byte 
order. (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D48704?vs=213922=213923#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D48704

Files:
  lldb/trunk/source/Target/ExecutionContext.cpp
  lldb/trunk/unittests/Target/CMakeLists.txt
  lldb/trunk/unittests/Target/ExecutionContextTest.cpp

Index: lldb/trunk/unittests/Target/CMakeLists.txt
===
--- lldb/trunk/unittests/Target/CMakeLists.txt
+++ lldb/trunk/unittests/Target/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(TargetTests
+  ExecutionContextTest.cpp
   MemoryRegionInfoTest.cpp
   ModuleCacheTest.cpp
   PathMappingListTest.cpp
@@ -7,10 +8,11 @@
   LINK_LIBS
   lldbCore
   lldbHost
-  lldbSymbol
-  lldbUtility
   lldbPluginObjectFileELF
+  lldbPluginPlatformLinux
   lldbPluginSymbolFileSymtab
+  lldbSymbol
+  lldbUtility
   lldbUtilityHelpers
 LINK_COMPONENTS
   Support
Index: lldb/trunk/unittests/Target/ExecutionContextTest.cpp
===
--- lldb/trunk/unittests/Target/ExecutionContextTest.cpp
+++ lldb/trunk/unittests/Target/ExecutionContextTest.cpp
@@ -0,0 +1,120 @@
+//===-- ExecutionContextTest.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Target/ExecutionContext.h"
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/Endian.h"
+#include "lldb/Utility/Reproducer.h"
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+#include "lldb/lldb-private-enumerations.h"
+#include "lldb/lldb-private.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+namespace {
+class ExecutionContextTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+platform_linux::PlatformLinux::Initialize();
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+
+class DummyProcess : public Process {
+public:
+  using Process::Process;
+
+  virtual bool CanDebug(lldb::TargetSP target, bool plugin_specified_by_name) {
+return true;
+  }
+  virtual Status DoDestroy() { return {}; }
+  virtual void RefreshStateAfterStop() {}
+  virtual size_t DoReadMemory(lldb::addr_t vm_addr, void *buf, size_t size,
+  Status ) {
+return 0;
+  }
+  virtual bool UpdateThreadList(ThreadList _thread_list,
+ThreadList _thread_list) {
+return false;
+  }
+  virtual ConstString GetPluginName() { return ConstString("Dummy"); }
+  virtual uint32_t GetPluginVersion() { return 0; }
+};
+} // namespace
+
+TEST_F(ExecutionContextTest, GetByteOrder) {
+  ExecutionContext exe_ctx(nullptr, nullptr, nullptr);
+  EXPECT_EQ(endian::InlHostByteOrder(), exe_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderTarget) {
+  ArchSpec arch("powerpc64-pc-linux");
+
+  Platform::SetHostPlatform(
+  platform_linux::PlatformLinux::CreateInstance(true, ));
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  ASSERT_TRUE(debugger_sp);
+
+  TargetSP target_sp;
+  PlatformSP platform_sp;
+  Status error = debugger_sp->GetTargetList().CreateTarget(
+  *debugger_sp, "", arch, eLoadDependentsNo, platform_sp, target_sp);
+  ASSERT_TRUE(target_sp);
+  ASSERT_TRUE(target_sp->GetArchitecture().IsValid());
+  ASSERT_TRUE(platform_sp);
+
+  ExecutionContext target_ctx(target_sp, false);
+  EXPECT_EQ(target_sp->GetArchitecture().GetByteOrder(),
+target_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderProcess) {
+  ArchSpec arch("powerpc64-pc-linux");
+
+  Platform::SetHostPlatform(
+  platform_linux::PlatformLinux::CreateInstance(true, ));
+
+  

[Lldb-commits] [PATCH] D48704: [ExecutionContext] Return the target/process byte order.

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere marked 2 inline comments as done.
JDevlieghere added inline comments.



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:77
+TEST_F(ExecutionContextTest, GetByteOrderTarget) {
+  ArchSpec arch = Target::GetDefaultArchitecture();
+  arch.SetTriple("armv7-pc-apple");

labath wrote:
> I don't understand this.. Why do you fetch the ArchSpec via 
> `Target::GetDefaultArchitecture()` and then immediately overwrite it on the 
> next line? Can this line just be deleted?
Yep, I uploaded an old version of the patch. This and the triple should've 
already been fixed. 



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:124
+  ExecutionContext process_ctx(process_sp);
+  EXPECT_EQ(process_sp->GetByteOrder(), process_ctx.GetByteOrder());
+}

labath wrote:
> It doesn't look like the presence of a process will change what 
> ExecutionContext::GetByteOrder returns, as it checks the target first. OTOH, 
> I don't know why would the byte order of a process be ever different from the 
> byte order of its target...
Yeah, I think the logic in the implementation is redundant, this is more of a 
test to prevent regressions in case the implementation would change in the 
future. 


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

https://reviews.llvm.org/D48704



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


[Lldb-commits] [lldb] r368181 - [ExecutionContext] Return the target/process byte order.

2019-08-07 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Wed Aug  7 09:09:35 2019
New Revision: 368181

URL: http://llvm.org/viewvc/llvm-project?rev=368181=rev
Log:
[ExecutionContext] Return the target/process byte order.

Currently ExecutionContext::GetByteOrder() always returns the host byte
order. This seems like a simple mistake: the return keyword appears to
have been omitted by accident. This patch fixes that and adds a unit
test.

Bugreport: https://llvm.org/PR37950

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

Added:
lldb/trunk/unittests/Target/ExecutionContextTest.cpp
Modified:
lldb/trunk/source/Target/ExecutionContext.cpp
lldb/trunk/unittests/Target/CMakeLists.txt

Modified: lldb/trunk/source/Target/ExecutionContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ExecutionContext.cpp?rev=368181=368180=368181=diff
==
--- lldb/trunk/source/Target/ExecutionContext.cpp (original)
+++ lldb/trunk/source/Target/ExecutionContext.cpp Wed Aug  7 09:09:35 2019
@@ -183,9 +183,9 @@ uint32_t ExecutionContext::GetAddressByt
 
 lldb::ByteOrder ExecutionContext::GetByteOrder() const {
   if (m_target_sp && m_target_sp->GetArchitecture().IsValid())
-m_target_sp->GetArchitecture().GetByteOrder();
+return m_target_sp->GetArchitecture().GetByteOrder();
   if (m_process_sp)
-m_process_sp->GetByteOrder();
+return m_process_sp->GetByteOrder();
   return endian::InlHostByteOrder();
 }
 

Modified: lldb/trunk/unittests/Target/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Target/CMakeLists.txt?rev=368181=368180=368181=diff
==
--- lldb/trunk/unittests/Target/CMakeLists.txt (original)
+++ lldb/trunk/unittests/Target/CMakeLists.txt Wed Aug  7 09:09:35 2019
@@ -1,4 +1,5 @@
 add_lldb_unittest(TargetTests
+  ExecutionContextTest.cpp
   MemoryRegionInfoTest.cpp
   ModuleCacheTest.cpp
   PathMappingListTest.cpp
@@ -7,10 +8,11 @@ add_lldb_unittest(TargetTests
   LINK_LIBS
   lldbCore
   lldbHost
-  lldbSymbol
-  lldbUtility
   lldbPluginObjectFileELF
+  lldbPluginPlatformLinux
   lldbPluginSymbolFileSymtab
+  lldbSymbol
+  lldbUtility
   lldbUtilityHelpers
 LINK_COMPONENTS
   Support

Added: lldb/trunk/unittests/Target/ExecutionContextTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Target/ExecutionContextTest.cpp?rev=368181=auto
==
--- lldb/trunk/unittests/Target/ExecutionContextTest.cpp (added)
+++ lldb/trunk/unittests/Target/ExecutionContextTest.cpp Wed Aug  7 09:09:35 
2019
@@ -0,0 +1,120 @@
+//===-- ExecutionContextTest.cpp *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Target/ExecutionContext.h"
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/Endian.h"
+#include "lldb/Utility/Reproducer.h"
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+#include "lldb/lldb-private-enumerations.h"
+#include "lldb/lldb-private.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+namespace {
+class ExecutionContextTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+platform_linux::PlatformLinux::Initialize();
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+
+class DummyProcess : public Process {
+public:
+  using Process::Process;
+
+  virtual bool CanDebug(lldb::TargetSP target, bool plugin_specified_by_name) {
+return true;
+  }
+  virtual Status DoDestroy() { return {}; }
+  virtual void RefreshStateAfterStop() {}
+  virtual size_t DoReadMemory(lldb::addr_t vm_addr, void *buf, size_t size,
+  Status ) {
+return 0;
+  }
+  virtual bool UpdateThreadList(ThreadList _thread_list,
+ThreadList _thread_list) {
+return false;
+  }
+  virtual ConstString GetPluginName() { return ConstString("Dummy"); }
+  virtual uint32_t 

[Lldb-commits] [PATCH] D48704: [ExecutionContext] Return the target/process byte order.

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 213922.
JDevlieghere marked 5 inline comments as done.
JDevlieghere added a comment.

Code review feedback


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

https://reviews.llvm.org/D48704

Files:
  lldb/source/Target/ExecutionContext.cpp
  lldb/unittests/Target/CMakeLists.txt
  lldb/unittests/Target/ExecutionContextTest.cpp

Index: lldb/unittests/Target/ExecutionContextTest.cpp
===
--- /dev/null
+++ lldb/unittests/Target/ExecutionContextTest.cpp
@@ -0,0 +1,120 @@
+//===-- ExecutionContextTest.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Target/ExecutionContext.h"
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/Endian.h"
+#include "lldb/Utility/Reproducer.h"
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+#include "lldb/lldb-private-enumerations.h"
+#include "lldb/lldb-private.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+namespace {
+class ExecutionContextTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+platform_linux::PlatformLinux::Initialize();
+  }
+  void TearDown() override {
+platform_linux::PlatformLinux::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+  }
+};
+
+class DummyProcess : public Process {
+public:
+  using Process::Process;
+
+  virtual bool CanDebug(lldb::TargetSP target, bool plugin_specified_by_name) {
+return true;
+  }
+  virtual Status DoDestroy() { return {}; }
+  virtual void RefreshStateAfterStop() {}
+  virtual size_t DoReadMemory(lldb::addr_t vm_addr, void *buf, size_t size,
+  Status ) {
+return 0;
+  }
+  virtual bool UpdateThreadList(ThreadList _thread_list,
+ThreadList _thread_list) {
+return false;
+  }
+  virtual ConstString GetPluginName() { return ConstString("Dummy"); }
+  virtual uint32_t GetPluginVersion() { return 0; }
+};
+} // namespace
+
+TEST_F(ExecutionContextTest, GetByteOrder) {
+  ExecutionContext exe_ctx(nullptr, nullptr, nullptr);
+  EXPECT_EQ(endian::InlHostByteOrder(), exe_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderTarget) {
+  ArchSpec arch("powerpc64-pc-linux");
+
+  Platform::SetHostPlatform(
+  platform_linux::PlatformLinux::CreateInstance(true, ));
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  ASSERT_TRUE(debugger_sp);
+
+  TargetSP target_sp;
+  PlatformSP platform_sp;
+  Status error = debugger_sp->GetTargetList().CreateTarget(
+  *debugger_sp, "", arch, eLoadDependentsNo, platform_sp, target_sp);
+  ASSERT_TRUE(target_sp);
+  ASSERT_TRUE(target_sp->GetArchitecture().IsValid());
+  ASSERT_TRUE(platform_sp);
+
+  ExecutionContext target_ctx(target_sp, false);
+  EXPECT_EQ(target_sp->GetArchitecture().GetByteOrder(),
+target_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderProcess) {
+  ArchSpec arch("powerpc64-pc-linux");
+
+  Platform::SetHostPlatform(
+  platform_linux::PlatformLinux::CreateInstance(true, ));
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  ASSERT_TRUE(debugger_sp);
+
+  TargetSP target_sp;
+  PlatformSP platform_sp;
+  Status error = debugger_sp->GetTargetList().CreateTarget(
+  *debugger_sp, "", arch, eLoadDependentsNo, platform_sp, target_sp);
+  ASSERT_TRUE(target_sp);
+  ASSERT_TRUE(target_sp->GetArchitecture().IsValid());
+  ASSERT_TRUE(platform_sp);
+
+  ListenerSP listener_sp(Listener::MakeListener("dummy"));
+  ProcessSP process_sp = std::make_shared(target_sp, listener_sp);
+  ASSERT_TRUE(process_sp);
+
+  ExecutionContext process_ctx(process_sp);
+  EXPECT_EQ(process_sp->GetByteOrder(), process_ctx.GetByteOrder());
+}
Index: lldb/unittests/Target/CMakeLists.txt
===
--- lldb/unittests/Target/CMakeLists.txt
+++ lldb/unittests/Target/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(TargetTests
+  ExecutionContextTest.cpp
   MemoryRegionInfoTest.cpp
   ModuleCacheTest.cpp
   PathMappingListTest.cpp
@@ -7,10 +8,11 @@
   LINK_LIBS
  

[Lldb-commits] [PATCH] D65874: [lldb][CMake] Disable modules in Xcode projects

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz created this revision.
sgraenitz added reviewers: aprantl, jingham, davide, teemperor.
Herald added a subscriber: mgorny.
Herald added a project: LLDB.

Apparently, module-enabled builds clash with Xcode's analysis.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65874

Files:
  lldb/cmake/caches/Apple-lldb-Xcode.cmake


Index: lldb/cmake/caches/Apple-lldb-Xcode.cmake
===
--- lldb/cmake/caches/Apple-lldb-Xcode.cmake
+++ lldb/cmake/caches/Apple-lldb-Xcode.cmake
@@ -6,6 +6,9 @@
 
 set(LLDB_BUILD_FRAMEWORK ON CACHE BOOL "")
 
+# Apparently, module-enabled builds clash with Xcode's analysis.
+set(LLVM_ENABLE_MODULES OFF CACHE BOOL "" FORCE)
+
 # Print a warning with instructions, if we
 # build with Xcode and didn't use this cache.
 set(LLDB_EXPLICIT_XCODE_CACHE_USED ON CACHE INTERNAL "")


Index: lldb/cmake/caches/Apple-lldb-Xcode.cmake
===
--- lldb/cmake/caches/Apple-lldb-Xcode.cmake
+++ lldb/cmake/caches/Apple-lldb-Xcode.cmake
@@ -6,6 +6,9 @@
 
 set(LLDB_BUILD_FRAMEWORK ON CACHE BOOL "")
 
+# Apparently, module-enabled builds clash with Xcode's analysis.
+set(LLVM_ENABLE_MODULES OFF CACHE BOOL "" FORCE)
+
 # Print a warning with instructions, if we
 # build with Xcode and didn't use this cache.
 set(LLDB_EXPLICIT_XCODE_CACHE_USED ON CACHE INTERNAL "")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D65872: [lldb][NFC] Check in test case for testing virtual function calls in pointers and references.

2019-08-07 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor created this revision.
teemperor added a reviewer: lhames.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

rdar://38048657 says that the following test case was broken. It seems to have 
been fixed since then, so
this patch just adds the test case to our test suite to check for regressions.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65872

Files:
  lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/Makefile
  
lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/TestVirtualPtrVsRef.py
  lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/main.cpp


Index: lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/main.cpp
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/main.cpp
@@ -0,0 +1,19 @@
+class A {
+public:
+  virtual ~A() {}
+  virtual int Dump() { return 1; }
+};
+
+class B : public A {
+public:
+  virtual ~B() {}
+  virtual int Dump() { return 2; }
+};
+
+int main(int argc, char const *argv[], char const *envp[]) {
+  B ref;
+  A *ptr = 
+  ptr->Dump();
+  return 0; //%self.expect("p ref.Dump()", substrs=['(int)', ' = 2'])
+//%self.expect("p ptr->Dump()", substrs=['(int)', ' = 2'])
+}
Index: 
lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/TestVirtualPtrVsRef.py
===
--- /dev/null
+++ 
lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/TestVirtualPtrVsRef.py
@@ -0,0 +1,4 @@
+from lldbsuite.test import lldbinline
+from lldbsuite.test import decorators
+
+lldbinline.MakeInlineTest(__file__, globals())
Index: lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/Makefile
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/Makefile
@@ -0,0 +1,3 @@
+LEVEL = ../../../make
+CXX_SOURCES := main.cpp
+include $(LEVEL)/Makefile.rules


Index: lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/main.cpp
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/main.cpp
@@ -0,0 +1,19 @@
+class A {
+public:
+  virtual ~A() {}
+  virtual int Dump() { return 1; }
+};
+
+class B : public A {
+public:
+  virtual ~B() {}
+  virtual int Dump() { return 2; }
+};
+
+int main(int argc, char const *argv[], char const *envp[]) {
+  B ref;
+  A *ptr = 
+  ptr->Dump();
+  return 0; //%self.expect("p ref.Dump()", substrs=['(int)', ' = 2'])
+//%self.expect("p ptr->Dump()", substrs=['(int)', ' = 2'])
+}
Index: lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/TestVirtualPtrVsRef.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/TestVirtualPtrVsRef.py
@@ -0,0 +1,4 @@
+from lldbsuite.test import lldbinline
+from lldbsuite.test import decorators
+
+lldbinline.MakeInlineTest(__file__, globals())
Index: lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/Makefile
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/lang/cpp/virtual-ptr-vs-ref/Makefile
@@ -0,0 +1,3 @@
+LEVEL = ../../../make
+CXX_SOURCES := main.cpp
+include $(LEVEL)/Makefile.rules
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r368168 - ProcessElfCore: Remove linux and freebsd NT_*** constants

2019-08-07 Thread Pavel Labath via lldb-commits
Author: labath
Date: Wed Aug  7 06:12:59 2019
New Revision: 368168

URL: http://llvm.org/viewvc/llvm-project?rev=368168=rev
Log:
ProcessElfCore: Remove linux and freebsd NT_*** constants

These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD
and OpenBSD constants as-is, as they have no llvm counterparts.

Modified:
lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp
lldb/trunk/source/Plugins/Process/elf-core/RegisterUtilities.h

Modified: lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp?rev=368168=368167=368168=diff
==
--- lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp (original)
+++ lldb/trunk/source/Plugins/Process/elf-core/ProcessElfCore.cpp Wed Aug  7 
06:12:59 2019
@@ -33,6 +33,7 @@
 #include "ThreadElfCore.h"
 
 using namespace lldb_private;
+namespace ELF = llvm::ELF;
 
 ConstString ProcessElfCore::GetPluginNameStatic() {
   static ConstString g_name("elf-core");
@@ -521,8 +522,8 @@ llvm::Error ProcessElfCore::parseFreeBSD
 if (note.info.n_name != "FreeBSD")
   continue;
 
-if ((note.info.n_type == FREEBSD::NT_PRSTATUS && have_prstatus) ||
-(note.info.n_type == FREEBSD::NT_PRPSINFO && have_prpsinfo)) {
+if ((note.info.n_type == ELF::NT_PRSTATUS && have_prstatus) ||
+(note.info.n_type == ELF::NT_PRPSINFO && have_prpsinfo)) {
   assert(thread_data.gpregset.GetByteSize() > 0);
   // Add the new thread to thread list
   m_thread_data.push_back(thread_data);
@@ -532,19 +533,19 @@ llvm::Error ProcessElfCore::parseFreeBSD
 }
 
 switch (note.info.n_type) {
-case FREEBSD::NT_PRSTATUS:
+case ELF::NT_PRSTATUS:
   have_prstatus = true;
   ParseFreeBSDPrStatus(thread_data, note.data, GetArchitecture());
   break;
-case FREEBSD::NT_PRPSINFO:
+case ELF::NT_PRPSINFO:
   have_prpsinfo = true;
   break;
-case FREEBSD::NT_THRMISC: {
+case ELF::NT_FREEBSD_THRMISC: {
   lldb::offset_t offset = 0;
   thread_data.name = note.data.GetCStr(, 20);
   break;
 }
-case FREEBSD::NT_PROCSTAT_AUXV:
+case ELF::NT_FREEBSD_PROCSTAT_AUXV:
   // FIXME: FreeBSD sticks an int at the beginning of the note
   m_auxv = DataExtractor(note.data, 4, note.data.GetByteSize() - 4);
   break;
@@ -771,8 +772,8 @@ llvm::Error ProcessElfCore::parseLinuxNo
 if (note.info.n_name != "CORE" && note.info.n_name != "LINUX")
   continue;
 
-if ((note.info.n_type == LINUX::NT_PRSTATUS && have_prstatus) ||
-(note.info.n_type == LINUX::NT_PRPSINFO && have_prpsinfo)) {
+if ((note.info.n_type == ELF::NT_PRSTATUS && have_prstatus) ||
+(note.info.n_type == ELF::NT_PRPSINFO && have_prpsinfo)) {
   assert(thread_data.gpregset.GetByteSize() > 0);
   // Add the new thread to thread list
   m_thread_data.push_back(thread_data);
@@ -782,7 +783,7 @@ llvm::Error ProcessElfCore::parseLinuxNo
 }
 
 switch (note.info.n_type) {
-case LINUX::NT_PRSTATUS: {
+case ELF::NT_PRSTATUS: {
   have_prstatus = true;
   ELFLinuxPrStatus prstatus;
   Status status = prstatus.Parse(note.data, arch);
@@ -795,7 +796,7 @@ llvm::Error ProcessElfCore::parseLinuxNo
   thread_data.gpregset = DataExtractor(note.data, header_size, len);
   break;
 }
-case LINUX::NT_PRPSINFO: {
+case ELF::NT_PRPSINFO: {
   have_prpsinfo = true;
   ELFLinuxPrPsInfo prpsinfo;
   Status status = prpsinfo.Parse(note.data, arch);
@@ -805,7 +806,7 @@ llvm::Error ProcessElfCore::parseLinuxNo
   SetID(prpsinfo.pr_pid);
   break;
 }
-case LINUX::NT_SIGINFO: {
+case ELF::NT_SIGINFO: {
   ELFLinuxSigInfo siginfo;
   Status status = siginfo.Parse(note.data, arch);
   if (status.Fail())
@@ -813,7 +814,7 @@ llvm::Error ProcessElfCore::parseLinuxNo
   thread_data.signo = siginfo.si_signo;
   break;
 }
-case LINUX::NT_FILE: {
+case ELF::NT_FILE: {
   m_nt_file_entries.clear();
   lldb::offset_t offset = 0;
   const uint64_t count = note.data.GetAddress();
@@ -832,7 +833,7 @@ llvm::Error ProcessElfCore::parseLinuxNo
   }
   break;
 }
-case LINUX::NT_AUXV:
+case ELF::NT_AUXV:
   m_auxv = note.data;
   break;
 default:

Modified: lldb/trunk/source/Plugins/Process/elf-core/RegisterUtilities.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/elf-core/RegisterUtilities.h?rev=368168=368167=368168=diff
==
--- lldb/trunk/source/Plugins/Process/elf-core/RegisterUtilities.h (original)
+++ lldb/trunk/source/Plugins/Process/elf-core/RegisterUtilities.h Wed Aug  7 
06:12:59 2019
@@ -11,21 +11,11 @@
 
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
 #include 

[Lldb-commits] [PATCH] D65864: Remove Module::GetSymbolVendor

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: clayborg, JDevlieghere, jingham.
Herald added a subscriber: jfb.
Herald added a reviewer: jdoerfert.

This patch removes the GetSymbolVendor function, and the various
mentions of the SymbolVendor in the Module class. The implementation of
GetSymbolVendor is "inlined" into the GetSymbolFile class which I
created earlier.

After this patch, the SymbolVendor class still exists inside the Module
object, but only as an implementation detail -- a fancy holder for the
SymbolFile. That will be removed in the next patch.


https://reviews.llvm.org/D65864

Files:
  include/lldb/Core/Module.h
  source/Core/Module.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp

Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
@@ -41,7 +41,7 @@
 
 // Subclass lldb_private::Module so we can intercept the
 // "Module::GetObjectFile()" (so we can fixup the object file sections) and
-// also for "Module::GetSymbolVendor()" (so we can fixup the symbol file id.
+// also for "Module::GetSymbolFile()" (so we can fixup the symbol file id.
 
 const SymbolFileDWARFDebugMap::FileRangeMap &
 SymbolFileDWARFDebugMap::CompileUnitInfo::GetFileRangeMap(
@@ -173,12 +173,12 @@
 
   ~DebugMapModule() override = default;
 
-  SymbolVendor *
-  GetSymbolVendor(bool can_create = true,
-  lldb_private::Stream *feedback_strm = nullptr) override {
+  SymbolFile *
+  GetSymbolFile(bool can_create = true,
+lldb_private::Stream *feedback_strm = nullptr) override {
 // Scope for locker
 if (m_symfile_up.get() || !can_create)
-  return m_symfile_up.get();
+  return m_symfile_up ? m_symfile_up->GetSymbolFile() : nullptr;
 
 ModuleSP exe_module_sp(m_exe_module_wp.lock());
 if (exe_module_sp) {
@@ -186,30 +186,28 @@
   ObjectFile *oso_objfile = GetObjectFile();
   if (oso_objfile) {
 std::lock_guard guard(m_mutex);
-SymbolVendor *symbol_vendor =
-Module::GetSymbolVendor(can_create, feedback_strm);
-if (symbol_vendor) {
+if (SymbolFile *symfile =
+Module::GetSymbolFile(can_create, feedback_strm)) {
   // Set a pointer to this class to set our OSO DWARF file know that
   // the DWARF is being used along with a debug map and that it will
   // have the remapped sections that we do below.
   SymbolFileDWARF *oso_symfile =
-  SymbolFileDWARFDebugMap::GetSymbolFileAsSymbolFileDWARF(
-  symbol_vendor->GetSymbolFile());
+  SymbolFileDWARFDebugMap::GetSymbolFileAsSymbolFileDWARF(symfile);
 
   if (!oso_symfile)
 return nullptr;
 
   ObjectFile *exe_objfile = exe_module_sp->GetObjectFile();
-  SymbolVendor *exe_sym_vendor = exe_module_sp->GetSymbolVendor();
+  SymbolFile *exe_symfile = exe_module_sp->GetSymbolFile();
 
-  if (exe_objfile && exe_sym_vendor) {
+  if (exe_objfile && exe_symfile) {
 oso_symfile->SetDebugMapModule(exe_module_sp);
 // Set the ID of the symbol file DWARF to the index of the OSO
 // shifted left by 32 bits to provide a unique prefix for any
 // UserID's that get created in the symbol file.
 oso_symfile->SetID(((uint64_t)m_cu_idx + 1ull) << 32ull);
   }
-  return symbol_vendor;
+  return symfile;
 }
   }
 }
@@ -533,12 +531,8 @@
 
 SymbolFileDWARF *SymbolFileDWARFDebugMap::GetSymbolFileByCompUnitInfo(
 CompileUnitInfo *comp_unit_info) {
-  Module *oso_module = GetModuleByCompUnitInfo(comp_unit_info);
-  if (oso_module) {
-SymbolVendor *sym_vendor = oso_module->GetSymbolVendor();
-if (sym_vendor)
-  return GetSymbolFileAsSymbolFileDWARF(sym_vendor->GetSymbolFile());
-  }
+  if (Module *oso_module = GetModuleByCompUnitInfo(comp_unit_info))
+return GetSymbolFileAsSymbolFileDWARF(oso_module->GetSymbolFile());
   return nullptr;
 }
 
Index: source/Core/Module.cpp
===
--- source/Core/Module.cpp
+++ source/Core/Module.cpp
@@ -1037,28 +1037,21 @@
   return num_matches;
 }
 
-SymbolVendor *Module::GetSymbolVendor(bool can_create,
-  lldb_private::Stream *feedback_strm) {
-  if (!m_did_load_symbol_vendor.load()) {
+SymbolFile *Module::GetSymbolFile(bool can_create, Stream *feedback_strm) {
+  if (!m_did_load_symbol_file.load()) {
 std::lock_guard guard(m_mutex);
-if (!m_did_load_symbol_vendor.load() && can_create) {
+if (!m_did_load_symbol_file.load() && can_create) {
   ObjectFile *obj_file = GetObjectFile();
   if (obj_file != nullptr) {
 static Timer::Category 

[Lldb-commits] [PATCH] D65862: Remove xcode-specific Config.h

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz accepted this revision.
sgraenitz added a comment.
This revision is now accepted and ready to land.

Right


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

https://reviews.llvm.org/D65862



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


[Lldb-commits] [PATCH] D65862: Remove xcode-specific Config.h

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D65862#1618740 , @sgraenitz wrote:

> Originally introduced with D31969 . LGTM. 
> Maybe we can remove even more? (here or in future commits)


I don't see what more could be removed here. Most of that patch was about 
setting up the infrastructure to generate the Config.h in the first place 
(instead of a bunch of hand-maintained files). That is still it use.


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

https://reviews.llvm.org/D65862



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


[Lldb-commits] [PATCH] D65862: Remove xcode-specific Config.h

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

Originally introduced with D31969 . LGTM. 
Maybe we can remove even more?


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

https://reviews.llvm.org/D65862



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


[Lldb-commits] [lldb] r368159 - ObjectFileELF: Remove NT_*** constants

2019-08-07 Thread Pavel Labath via lldb-commits
Author: labath
Date: Wed Aug  7 05:13:48 2019
New Revision: 368159

URL: http://llvm.org/viewvc/llvm-project?rev=368159=rev
Log:
ObjectFileELF: Remove NT_*** constants

llvm now has definitions of those in BinaryFormat/ELF.h. Use those
instead.

Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=368159=368158=368159=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Wed Aug  7 
05:13:48 2019
@@ -29,10 +29,10 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/Timer.h"
-
 #include "llvm/ADT/IntervalMap.h"
 #include "llvm/ADT/PointerUnion.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Object/Decompressor.h"
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/JamCRC.h"
@@ -81,41 +81,6 @@ const elf_word LLDB_NT_GNU_ABI_OS_LINUX
 const elf_word LLDB_NT_GNU_ABI_OS_HURD = 0x01;
 const elf_word LLDB_NT_GNU_ABI_OS_SOLARIS = 0x02;
 
-// LLDB_NT_OWNER_CORE and LLDB_NT_OWNER_LINUX note contants
-#define NT_PRSTATUS 1
-#define NT_PRFPREG 2
-#define NT_PRPSINFO 3
-#define NT_TASKSTRUCT 4
-#define NT_AUXV 6
-#define NT_SIGINFO 0x53494749
-#define NT_FILE 0x46494c45
-#define NT_PRXFPREG 0x46e62b7f
-#define NT_PPC_VMX 0x100
-#define NT_PPC_SPE 0x101
-#define NT_PPC_VSX 0x102
-#define NT_386_TLS 0x200
-#define NT_386_IOPERM 0x201
-#define NT_X86_XSTATE 0x202
-#define NT_S390_HIGH_GPRS 0x300
-#define NT_S390_TIMER 0x301
-#define NT_S390_TODCMP 0x302
-#define NT_S390_TODPREG 0x303
-#define NT_S390_CTRS 0x304
-#define NT_S390_PREFIX 0x305
-#define NT_S390_LAST_BREAK 0x306
-#define NT_S390_SYSTEM_CALL 0x307
-#define NT_S390_TDB 0x308
-#define NT_S390_VXRS_LOW 0x309
-#define NT_S390_VXRS_HIGH 0x30a
-#define NT_ARM_VFP 0x400
-#define NT_ARM_TLS 0x401
-#define NT_ARM_HW_BREAK 0x402
-#define NT_ARM_HW_WATCH 0x403
-#define NT_ARM_SYSTEM_CALL 0x404
-#define NT_METAG_CBUF 0x500
-#define NT_METAG_RPIPE 0x501
-#define NT_METAG_TLS 0x502
-
 
//===--===//
 /// \class ELFRelocation
 /// Generic wrapper for ELFRel and ELFRela.


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


[Lldb-commits] [PATCH] D65862: Remove xcode-specific Config.h

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: sgraenitz, beanz.
Herald added a subscriber: mgorny.

Now that the xcode project is removed, we no longer need/use the
hand-maintained Config.h file, as everything is configured through
cmake.

This patch deletes that file and reverts some of the changes from
r300372, which were made to support this use case.


https://reviews.llvm.org/D65862

Files:
  cmake/modules/LLDBConfig.cmake
  include/lldb/Host/Config.h


Index: include/lldb/Host/Config.h
===
--- include/lldb/Host/Config.h
+++ /dev/null
@@ -1,38 +0,0 @@
-//===-- Config.h *- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#ifndef LLDB_HOST_CONFIG_H
-#define LLDB_HOST_CONFIG_H
- 
-#if defined(__APPLE__)
-
-// This block of code only exists to keep the Xcode project working in the
-// absence of a configuration step.
-#define LLDB_LIBDIR_SUFFIX ""
-
-#define LLDB_CONFIG_TERMIOS_SUPPORTED 1
-
-#define LLDB_EDITLINE_USE_WCHAR 1
-
-#define LLDB_HAVE_EL_RFUNC_T 1
-
-#define HAVE_SYS_EVENT_H 1
-
-#define HAVE_PPOLL 0
-
-#define HAVE_SIGACTION 1
-
-#define HAVE_LIBCOMPRESSION 1
-
-#else
-
-#error This file is only used by the Xcode build.
-
-#endif
-
-#endif // #ifndef LLDB_HOST_CONFIG_H
Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -333,8 +333,8 @@
 message(STATUS "LLDB version: ${LLDB_VERSION}")
 
 include_directories(BEFORE
-  ${CMAKE_CURRENT_SOURCE_DIR}/include
   ${CMAKE_CURRENT_BINARY_DIR}/include
+  ${CMAKE_CURRENT_SOURCE_DIR}/include
   )
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
@@ -345,7 +345,6 @@
 PATTERN "*.h"
 PATTERN ".svn" EXCLUDE
 PATTERN ".cmake" EXCLUDE
-PATTERN "Config.h" EXCLUDE
 )
 
   install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/


Index: include/lldb/Host/Config.h
===
--- include/lldb/Host/Config.h
+++ /dev/null
@@ -1,38 +0,0 @@
-//===-- Config.h *- C++ -*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#ifndef LLDB_HOST_CONFIG_H
-#define LLDB_HOST_CONFIG_H
- 
-#if defined(__APPLE__)
-
-// This block of code only exists to keep the Xcode project working in the
-// absence of a configuration step.
-#define LLDB_LIBDIR_SUFFIX ""
-
-#define LLDB_CONFIG_TERMIOS_SUPPORTED 1
-
-#define LLDB_EDITLINE_USE_WCHAR 1
-
-#define LLDB_HAVE_EL_RFUNC_T 1
-
-#define HAVE_SYS_EVENT_H 1
-
-#define HAVE_PPOLL 0
-
-#define HAVE_SIGACTION 1
-
-#define HAVE_LIBCOMPRESSION 1
-
-#else
-
-#error This file is only used by the Xcode build.
-
-#endif
-
-#endif // #ifndef LLDB_HOST_CONFIG_H
Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -333,8 +333,8 @@
 message(STATUS "LLDB version: ${LLDB_VERSION}")
 
 include_directories(BEFORE
-  ${CMAKE_CURRENT_SOURCE_DIR}/include
   ${CMAKE_CURRENT_BINARY_DIR}/include
+  ${CMAKE_CURRENT_SOURCE_DIR}/include
   )
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
@@ -345,7 +345,6 @@
 PATTERN "*.h"
 PATTERN ".svn" EXCLUDE
 PATTERN ".cmake" EXCLUDE
-PATTERN "Config.h" EXCLUDE
 )
 
   install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

In D65798#1618609 , @labath wrote:

> Making it so that the clang is automatically found it if happens to be next 
> to llvm seems like a reasonable thing to me. I have no idea what would be the 
> canonical cmake way to do that...


"the canonical cmake way" good question! It turns out that, providing another 
hint for `find_package(Clang ...)` does exactly that: it sets Clang_DIR to the 
first path where it found Clang. If we do not attach great importance to the 
status message, we could do:

  find_package(LLVM REQUIRED CONFIG HINTS ${LLVM_DIR} NO_CMAKE_FIND_ROOT_PATH)
  find_package(Clang REQUIRED CONFIG HINTS ${Clang_DIR} ${LLVM_DIR}/../clang 
NO_CMAKE_FIND_ROOT_PATH)
  
  # Clang_DIR is defined now even if the ${LLVM_DIR}/../clang fallback was used


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798



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


[Lldb-commits] [PATCH] D65789: A more robust way of testing debug_line parser near the end of module

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368154: A more robust way of testing debug_line parser near 
the end of module (authored by labath, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65789

Files:
  lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
  lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s


Index: lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
===
--- lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
+++ lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
@@ -0,0 +1,14 @@
+PHDRS {
+  text PT_LOAD;
+}
+SECTIONS {
+  .shstrtab : { *(.shstrtab) }
+  .debug_info   : { *(.debug_info  ) }
+  .debug_line   : { *(.debug_line  ) }
+  .debug_str: { *(.debug_str   ) }
+  .debug_abbrev : { *(.debug_abbrev) }
+
+  . = 0x201000;
+  .text : { *(.text .text.f) } :text
+  /DISCARD/ : { *(*) }
+}
Index: lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
===
--- lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
+++ lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
@@ -1,10 +1,14 @@
+# Test basics of debug_line parsing. This test uses a linker script which
+# ensures the code is placed at the end of a module to test the boundary
+# condition when the final end-of-sequence line table entry points to an 
address
+# that is outside the range of memory covered by the module.
+
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld --script=%S/Inputs/debug-line-basic.script %t.o -o %t
 # RUN: %lldb %t -o "image dump line-table -v a.c" -o exit | FileCheck %s
 
-
.text
.globl  _start
 _start:
@@ -35,9 +39,16 @@
.loc   2 1 0 is_stmt 0
 nop
 # CHECK-NEXT: 0x00201007: /tmp/c.c:1{{$}}
-
 # CHECK-NEXT: 0x00201008: /tmp/c.c:1, is_terminal_entry = TRUE{{$}}
 
+   .section.text.f,"ax",@progbits
+f:
+.loc   1 3 0 is_stmt 0
+nop
+# CHECK-NEXT: 0x00201008: /tmp/b.c:3{{$}}
+# CHECK-NEXT: 0x00201009: /tmp/b.c:3, is_terminal_entry = TRUE{{$}}
+
+
.section.debug_str,"MS",@progbits,1
 .Linfo_string1:
.asciz  "a.c"


Index: lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
===
--- lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
+++ lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
@@ -0,0 +1,14 @@
+PHDRS {
+  text PT_LOAD;
+}
+SECTIONS {
+  .shstrtab : { *(.shstrtab) }
+  .debug_info   : { *(.debug_info  ) }
+  .debug_line   : { *(.debug_line  ) }
+  .debug_str: { *(.debug_str   ) }
+  .debug_abbrev : { *(.debug_abbrev) }
+
+  . = 0x201000;
+  .text : { *(.text .text.f) } :text
+  /DISCARD/ : { *(*) }
+}
Index: lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
===
--- lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
+++ lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
@@ -1,10 +1,14 @@
+# Test basics of debug_line parsing. This test uses a linker script which
+# ensures the code is placed at the end of a module to test the boundary
+# condition when the final end-of-sequence line table entry points to an address
+# that is outside the range of memory covered by the module.
+
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld --script=%S/Inputs/debug-line-basic.script %t.o -o %t
 # RUN: %lldb %t -o "image dump line-table -v a.c" -o exit | FileCheck %s
 
-
 	.text
 	.globl	_start
 _start:
@@ -35,9 +39,16 @@
 	.loc   2 1 0 is_stmt 0
 nop
 # CHECK-NEXT: 0x00201007: /tmp/c.c:1{{$}}
-
 # CHECK-NEXT: 0x00201008: /tmp/c.c:1, is_terminal_entry = TRUE{{$}}
 
+	.section	.text.f,"ax",@progbits
+f:
+.loc   1 3 0 is_stmt 0
+nop
+# CHECK-NEXT: 0x00201008: /tmp/b.c:3{{$}}
+# CHECK-NEXT: 0x00201009: /tmp/b.c:3, is_terminal_entry = TRUE{{$}}
+
+
 	.section	.debug_str,"MS",@progbits,1
 .Linfo_string1:
 	.asciz	"a.c"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r368154 - A more robust way of testing debug_line parser near the end of module

2019-08-07 Thread Pavel Labath via lldb-commits
Author: labath
Date: Wed Aug  7 04:33:56 2019
New Revision: 368154

URL: http://llvm.org/viewvc/llvm-project?rev=368154=rev
Log:
A more robust way of testing debug_line parser near the end of module

Summary:
While removing -z separate-code makes lld produce place the code at the
end of a segment right now, it's possible that future changes to the
linker will change that, thereby removing the coverage for the changes
in r367983. This patch adds a linker script to one of the line table
tests, which ensures that the code (and its line table) will be placed
at the very end of a module.

Reviewers: MaskRay

Subscribers: lldb-commits

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

Added:
lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
Modified:
lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s

Added: lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script?rev=368154=auto
==
--- lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script (added)
+++ lldb/trunk/lit/SymbolFile/DWARF/Inputs/debug-line-basic.script Wed Aug  7 
04:33:56 2019
@@ -0,0 +1,14 @@
+PHDRS {
+  text PT_LOAD;
+}
+SECTIONS {
+  .shstrtab : { *(.shstrtab) }
+  .debug_info   : { *(.debug_info  ) }
+  .debug_line   : { *(.debug_line  ) }
+  .debug_str: { *(.debug_str   ) }
+  .debug_abbrev : { *(.debug_abbrev) }
+
+  . = 0x201000;
+  .text : { *(.text .text.f) } :text
+  /DISCARD/ : { *(*) }
+}

Modified: lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s?rev=368154=368153=368154=diff
==
--- lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s (original)
+++ lldb/trunk/lit/SymbolFile/DWARF/debug-line-basic.s Wed Aug  7 04:33:56 2019
@@ -1,10 +1,14 @@
+# Test basics of debug_line parsing. This test uses a linker script which
+# ensures the code is placed at the end of a module to test the boundary
+# condition when the final end-of-sequence line table entry points to an 
address
+# that is outside the range of memory covered by the module.
+
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld --script=%S/Inputs/debug-line-basic.script %t.o -o %t
 # RUN: %lldb %t -o "image dump line-table -v a.c" -o exit | FileCheck %s
 
-
.text
.globl  _start
 _start:
@@ -35,9 +39,16 @@ _start:
.loc   2 1 0 is_stmt 0
 nop
 # CHECK-NEXT: 0x00201007: /tmp/c.c:1{{$}}
-
 # CHECK-NEXT: 0x00201008: /tmp/c.c:1, is_terminal_entry = TRUE{{$}}
 
+   .section.text.f,"ax",@progbits
+f:
+.loc   1 3 0 is_stmt 0
+nop
+# CHECK-NEXT: 0x00201008: /tmp/b.c:3{{$}}
+# CHECK-NEXT: 0x00201009: /tmp/b.c:3, is_terminal_entry = TRUE{{$}}
+
+
.section.debug_str,"MS",@progbits,1
 .Linfo_string1:
.asciz  "a.c"


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


[Lldb-commits] [PATCH] D65789: A more robust way of testing debug_line parser near the end of module

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath updated this revision to Diff 213845.
labath added a comment.

- remove output section addresses


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

https://reviews.llvm.org/D65789

Files:
  lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
  lit/SymbolFile/DWARF/debug-line-basic.s


Index: lit/SymbolFile/DWARF/debug-line-basic.s
===
--- lit/SymbolFile/DWARF/debug-line-basic.s
+++ lit/SymbolFile/DWARF/debug-line-basic.s
@@ -1,10 +1,14 @@
+# Test basics of debug_line parsing. This test uses a linker script which
+# ensures the code is placed at the end of a module to test the boundary
+# condition when the final end-of-sequence line table entry points to an 
address
+# that is outside the range of memory covered by the module.
+
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld --script=%S/Inputs/debug-line-basic.script %t.o -o %t
 # RUN: %lldb %t -o "image dump line-table -v a.c" -o exit | FileCheck %s
 
-
.text
.globl  _start
 _start:
@@ -35,9 +39,16 @@
.loc   2 1 0 is_stmt 0
 nop
 # CHECK-NEXT: 0x00201007: /tmp/c.c:1{{$}}
-
 # CHECK-NEXT: 0x00201008: /tmp/c.c:1, is_terminal_entry = TRUE{{$}}
 
+   .section.text.f,"ax",@progbits
+f:
+.loc   1 3 0 is_stmt 0
+nop
+# CHECK-NEXT: 0x00201008: /tmp/b.c:3{{$}}
+# CHECK-NEXT: 0x00201009: /tmp/b.c:3, is_terminal_entry = TRUE{{$}}
+
+
.section.debug_str,"MS",@progbits,1
 .Linfo_string1:
.asciz  "a.c"
Index: lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
===
--- /dev/null
+++ lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
@@ -0,0 +1,14 @@
+PHDRS {
+  text PT_LOAD;
+}
+SECTIONS {
+  .shstrtab : { *(.shstrtab) }
+  .debug_info   : { *(.debug_info  ) }
+  .debug_line   : { *(.debug_line  ) }
+  .debug_str: { *(.debug_str   ) }
+  .debug_abbrev : { *(.debug_abbrev) }
+
+  . = 0x201000;
+  .text : { *(.text .text.f) } :text
+  /DISCARD/ : { *(*) }
+}


Index: lit/SymbolFile/DWARF/debug-line-basic.s
===
--- lit/SymbolFile/DWARF/debug-line-basic.s
+++ lit/SymbolFile/DWARF/debug-line-basic.s
@@ -1,10 +1,14 @@
+# Test basics of debug_line parsing. This test uses a linker script which
+# ensures the code is placed at the end of a module to test the boundary
+# condition when the final end-of-sequence line table entry points to an address
+# that is outside the range of memory covered by the module.
+
 # REQUIRES: lld, x86
 
 # RUN: llvm-mc -triple x86_64-pc-linux %s -filetype=obj > %t.o
-# RUN: ld.lld %t.o -o %t
+# RUN: ld.lld --script=%S/Inputs/debug-line-basic.script %t.o -o %t
 # RUN: %lldb %t -o "image dump line-table -v a.c" -o exit | FileCheck %s
 
-
 	.text
 	.globl	_start
 _start:
@@ -35,9 +39,16 @@
 	.loc   2 1 0 is_stmt 0
 nop
 # CHECK-NEXT: 0x00201007: /tmp/c.c:1{{$}}
-
 # CHECK-NEXT: 0x00201008: /tmp/c.c:1, is_terminal_entry = TRUE{{$}}
 
+	.section	.text.f,"ax",@progbits
+f:
+.loc   1 3 0 is_stmt 0
+nop
+# CHECK-NEXT: 0x00201008: /tmp/b.c:3{{$}}
+# CHECK-NEXT: 0x00201009: /tmp/b.c:3, is_terminal_entry = TRUE{{$}}
+
+
 	.section	.debug_str,"MS",@progbits,1
 .Linfo_string1:
 	.asciz	"a.c"
Index: lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
===
--- /dev/null
+++ lit/SymbolFile/DWARF/Inputs/debug-line-basic.script
@@ -0,0 +1,14 @@
+PHDRS {
+  text PT_LOAD;
+}
+SECTIONS {
+  .shstrtab : { *(.shstrtab) }
+  .debug_info   : { *(.debug_info  ) }
+  .debug_line   : { *(.debug_line  ) }
+  .debug_str: { *(.debug_str   ) }
+  .debug_abbrev : { *(.debug_abbrev) }
+
+  . = 0x201000;
+  .text : { *(.text .text.f) } :text
+  /DISCARD/ : { *(*) }
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz updated this revision to Diff 213842.
sgraenitz added a comment.

Update documentation to mention multiple provided build trees and the usage of 
`Clang_DIR`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798

Files:
  lldb/cmake/modules/LLDBStandalone.cmake
  lldb/docs/resources/build.rst


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -120,10 +120,11 @@
 *
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
@@ -139,15 +140,15 @@
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ninja \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   [] /path/to/llvm-project/lldb
   > ninja lldb
 
@@ -323,7 +324,6 @@
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,5 +1,11 @@
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
+# If Clang was built in one tree with LLVM, we can infer its CMake module 
directory.
+if(NOT Clang_DIR AND EXISTS ${LLVM_DIR}/../clang)
+  set(Clang_DIR ${LLVM_DIR}/../clang)
+  message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")
+endif()
+
 find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
 


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -120,10 +120,11 @@
 *
 
 This is another way to build LLDB. We can use the same source-tree as we
-checked out above, but now we will have two build-trees:
+checked out above, but now we will have multiple build-trees:
 
 * the main build-tree for LLDB in ``/path/to/lldb-build``
-* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+* one or more provided build-trees for LLVM and Clang; for simplicity we use a
+  single one in ``/path/to/llvm-build``
 
 Run CMake with ``-B`` pointing to a new directory for the provided
 build-tree\ :sup:`1` and the positional argument pointing to the ``llvm``
@@ -139,15 +140,15 @@
 
 Now run CMake a second time with ``-B`` pointing to a new directory for the
 main build-tree and the positional argument pointing to the ``lldb`` directory
-in the source-tree. In order to find the provided build-tree, the build-system
-needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
-case-sensitive!):
+in the source-tree. In order to find the provided build-tree, the build system
+looks for the path to its CMake modules in ``LLVM_DIR``. If you use a separate
+build directory for Clang, remember to pass its module path via ``Clang_DIR``
+(CMake variables are case-sensitive!):
 
 ::
 
   > cmake -B /path/to/lldb-build -G Ninja \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   [] /path/to/llvm-project/lldb
   > ninja lldb
 
@@ -323,7 +324,6 @@
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   

[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Making it so that the clang is automatically found it if happens to be next to 
llvm seems like a reasonable thing to me. I have no idea what would be the 
canonical cmake way to do that...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798



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


[Lldb-commits] [PATCH] D65566: [lldb][CMake] Workaround debugserver code-signing issue in generated Xcode project

2019-08-07 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368151: [lldb][CMake] Workaround debugserver code-signing 
issue in generated Xcode… (authored by stefan.graenitz, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65566?vs=212762=213838#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65566

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


Index: lldb/trunk/tools/debugserver/source/CMakeLists.txt
===
--- lldb/trunk/tools/debugserver/source/CMakeLists.txt
+++ lldb/trunk/tools/debugserver/source/CMakeLists.txt
@@ -208,6 +208,34 @@
   ENTITLEMENTS ${entitlements}
 )
 
+# Workaround for Xcode-specific code-signing behavior:
+# The XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY option causes debugserver to be copied
+# into the framework first and code-signed afterwards. Sign the copy manually.
+if (debugserver_codesign_identity AND LLDB_BUILD_FRAMEWORK AND
+CMAKE_GENERATOR STREQUAL "Xcode")
+  if(NOT CMAKE_CODESIGN_ALLOCATE)
+execute_process(
+  COMMAND xcrun -f codesign_allocate
+  OUTPUT_STRIP_TRAILING_WHITESPACE
+  OUTPUT_VARIABLE CMAKE_CODESIGN_ALLOCATE
+)
+  endif()
+  if(entitlements)
+set(pass_entitlements --entitlements ${entitlements})
+  endif()
+
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  set(copy_location 
${framework_build_dir}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources/debugserver)
+
+  add_custom_command(TARGET debugserver POST_BUILD
+COMMAND ${CMAKE_COMMAND} -E
+env CODESIGN_ALLOCATE=${CMAKE_CODESIGN_ALLOCATE}
+xcrun codesign -f -s ${debugserver_codesign_identity}
+${pass_entitlements} ${copy_location}
+COMMENT "Code-sign debugserver copy in the build-tree framework: 
${copy_location}"
+  )
+endif()
+
 set_target_properties(debugserver PROPERTIES FOLDER "lldb 
libraries/debugserver")
 
 if(IOS)


Index: lldb/trunk/tools/debugserver/source/CMakeLists.txt
===
--- lldb/trunk/tools/debugserver/source/CMakeLists.txt
+++ lldb/trunk/tools/debugserver/source/CMakeLists.txt
@@ -208,6 +208,34 @@
   ENTITLEMENTS ${entitlements}
 )
 
+# Workaround for Xcode-specific code-signing behavior:
+# The XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY option causes debugserver to be copied
+# into the framework first and code-signed afterwards. Sign the copy manually.
+if (debugserver_codesign_identity AND LLDB_BUILD_FRAMEWORK AND
+CMAKE_GENERATOR STREQUAL "Xcode")
+  if(NOT CMAKE_CODESIGN_ALLOCATE)
+execute_process(
+  COMMAND xcrun -f codesign_allocate
+  OUTPUT_STRIP_TRAILING_WHITESPACE
+  OUTPUT_VARIABLE CMAKE_CODESIGN_ALLOCATE
+)
+  endif()
+  if(entitlements)
+set(pass_entitlements --entitlements ${entitlements})
+  endif()
+
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  set(copy_location ${framework_build_dir}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources/debugserver)
+
+  add_custom_command(TARGET debugserver POST_BUILD
+COMMAND ${CMAKE_COMMAND} -E
+env CODESIGN_ALLOCATE=${CMAKE_CODESIGN_ALLOCATE}
+xcrun codesign -f -s ${debugserver_codesign_identity}
+${pass_entitlements} ${copy_location}
+COMMENT "Code-sign debugserver copy in the build-tree framework: ${copy_location}"
+  )
+endif()
+
 set_target_properties(debugserver PROPERTIES FOLDER "lldb libraries/debugserver")
 
 if(IOS)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r368151 - [lldb][CMake] Workaround debugserver code-signing issue in generated Xcode project

2019-08-07 Thread Stefan Granitz via lldb-commits
Author: stefan.graenitz
Date: Wed Aug  7 04:02:04 2019
New Revision: 368151

URL: http://llvm.org/viewvc/llvm-project?rev=368151=rev
Log:
[lldb][CMake] Workaround debugserver code-signing issue in generated Xcode 
project

Summary:
Explicitly code-sign the LLDB.framework copy of debugserver in the build-tree. 
This is necessary, because the Xcode-specific logic in `llvm_codesign` [1] has 
the side-effect that Xcode code-signs after post-build steps (here: after 
copying debugserver over into the framework). The special case for Xcode was 
necessary to avoid double-signing errors in the past (see D55116 and D55816).

[1] 
https://github.com/llvm/llvm-project/blob/36fb93982f0e/llvm/cmake/modules/AddLLVM.cmake#L1676

Reviewers: jingham, davide, JDevlieghere, teemperor

Reviewed By: JDevlieghere

Subscribers: beanz, mgorny, lldb-commits, #lldb

Tags: #lldb

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

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

Modified: lldb/trunk/tools/debugserver/source/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/CMakeLists.txt?rev=368151=368150=368151=diff
==
--- lldb/trunk/tools/debugserver/source/CMakeLists.txt (original)
+++ lldb/trunk/tools/debugserver/source/CMakeLists.txt Wed Aug  7 04:02:04 2019
@@ -208,6 +208,34 @@ add_lldb_tool(debugserver ADD_TO_FRAMEWO
   ENTITLEMENTS ${entitlements}
 )
 
+# Workaround for Xcode-specific code-signing behavior:
+# The XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY option causes debugserver to be copied
+# into the framework first and code-signed afterwards. Sign the copy manually.
+if (debugserver_codesign_identity AND LLDB_BUILD_FRAMEWORK AND
+CMAKE_GENERATOR STREQUAL "Xcode")
+  if(NOT CMAKE_CODESIGN_ALLOCATE)
+execute_process(
+  COMMAND xcrun -f codesign_allocate
+  OUTPUT_STRIP_TRAILING_WHITESPACE
+  OUTPUT_VARIABLE CMAKE_CODESIGN_ALLOCATE
+)
+  endif()
+  if(entitlements)
+set(pass_entitlements --entitlements ${entitlements})
+  endif()
+
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  set(copy_location 
${framework_build_dir}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources/debugserver)
+
+  add_custom_command(TARGET debugserver POST_BUILD
+COMMAND ${CMAKE_COMMAND} -E
+env CODESIGN_ALLOCATE=${CMAKE_CODESIGN_ALLOCATE}
+xcrun codesign -f -s ${debugserver_codesign_identity}
+${pass_entitlements} ${copy_location}
+COMMENT "Code-sign debugserver copy in the build-tree framework: 
${copy_location}"
+  )
+endif()
+
 set_target_properties(debugserver PROPERTIES FOLDER "lldb 
libraries/debugserver")
 
 if(IOS)


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


[Lldb-commits] [lldb] r368150 - [lldb][NFC] Remove commented out code in ClangASTContext::AddMethodToCXXRecordType

2019-08-07 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Wed Aug  7 03:59:34 2019
New Revision: 368150

URL: http://llvm.org/viewvc/llvm-project?rev=368150=rev
Log:
[lldb][NFC] Remove commented out code in 
ClangASTContext::AddMethodToCXXRecordType

Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=368150=368149=368150=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Wed Aug  7 03:59:34 2019
@@ -8330,24 +8330,6 @@ clang::CXXMethodDecl *ClangASTContext::A
   VerifyDecl(cxx_method_decl);
 #endif
 
-  //printf ("decl->isPolymorphic() = %i\n",
-  //cxx_record_decl->isPolymorphic());
-  //printf ("decl->isAggregate()   = %i\n",
-  //cxx_record_decl->isAggregate());
-  //printf ("decl->isPOD() = %i\n",
-  //cxx_record_decl->isPOD());
-  //printf ("decl->isEmpty()   = %i\n",
-  //cxx_record_decl->isEmpty());
-  //printf ("decl->isAbstract()= %i\n",
-  //cxx_record_decl->isAbstract());
-  //printf ("decl->hasTrivialConstructor() = %i\n",
-  //cxx_record_decl->hasTrivialConstructor());
-  //printf ("decl->hasTrivialCopyConstructor() = %i\n",
-  //cxx_record_decl->hasTrivialCopyConstructor());
-  //printf ("decl->hasTrivialCopyAssignment()  = %i\n",
-  //cxx_record_decl->hasTrivialCopyAssignment());
-  //printf ("decl->hasTrivialDestructor()  = %i\n",
-  //cxx_record_decl->hasTrivialDestructor());
   return cxx_method_decl;
 }
 


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


[Lldb-commits] [lldb] r368148 - [lldb][CMake] Fix one more detail in r368066

2019-08-07 Thread Stefan Granitz via lldb-commits
Author: stefan.graenitz
Date: Wed Aug  7 03:47:49 2019
New Revision: 368148

URL: http://llvm.org/viewvc/llvm-project?rev=368148=rev
Log:
[lldb][CMake] Fix one more detail in r368066

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

Modified:
lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake

Modified: lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake?rev=368148=368147=368148=diff
==
--- lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake (original)
+++ lldb/trunk/cmake/caches/Apple-lldb-Xcode.cmake Wed Aug  7 03:47:49 2019
@@ -1,6 +1,6 @@
 include(${CMAKE_CURRENT_LIST_DIR}/Apple-lldb-base.cmake)
 
-set(CMAKE_GENERATOR Xcode)
+set(CMAKE_GENERATOR Xcode CACHE STRING "")
 set(CMAKE_OSX_DEPLOYMENT_TARGET 10.11 CACHE STRING "")
 set(CMAKE_XCODE_GENERATE_SCHEME ON CACHE BOOL "")
 


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


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added inline comments.



Comment at: lldb/cmake/modules/LLDBStandalone.cmake:6
+  # next to LLVM's module directory.
+  set(Clang_DIR ${LLVM_DIR}/../clang)
+  message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")

labath wrote:
> sgraenitz wrote:
> > compnerd wrote:
> > > sgraenitz wrote:
> > > > compnerd wrote:
> > > > > What happens in the standalone clang build scenario?  Can I ask what 
> > > > > is the motivation for this change?  I think it is better to require 
> > > > > that the user pass the path, as that is an explicit dependency of 
> > > > > LLDB.
> > > > I don't think there's any side-effects on Clang standalone builds. Is 
> > > > that what you mean with "standalone clang build scenario"?
> > > > 
> > > > I would like top prevent people from writing custom build scripts on 
> > > > top of CMake. Passing a number of very similar paths to CMake, e.g. 
> > > > each time we want to generate a Xcode project for development, this 
> > > > option seems to become compelling quickly. This patch makes standalone 
> > > > configurations simpler. Basically, it provides a default value. I 
> > > > doesn't cut down functionality.
> > > > 
> > > > You can still explicitly pass any path you want. This branch will then 
> > > > not be taken.
> > > I think that the build fragmentation has caused a larger problem, and I 
> > > would like to avoid that.  The standalone build scenario is:
> > > 
> > > build/llvm
> > > build/clang
> > > build/lldb
> > > 
> > > In this case, `../clang` does not exist (`../../clang/lib/cmake/clang` 
> > > does).  I think what I would suggest instead is adding a cache file that 
> > > has the configuration parameters setup already.
> > For the scenario you describe, can you point me to any documentation that 
> > describes it or a bot that builds it?
> > 
> > > I think what I would suggest instead is adding a cache file that has the 
> > > configuration parameters setup already.
> > 
> > How would your cache file look like?
> > For the scenario you describe, can you point me to any documentation that 
> > describes it or a bot that builds it?
> 
> I think a lot of linux distributions which want to provide llvm,clang,etc. as 
> separate packages build in this way. And those that don't, they'd probably 
> want to build it that way, but they can't do it because it doesn't work for 
> them for one reason or another (the standalone builds are always a bit 
> behind, because the devs usually just build everything monolithically). I 
> know at least gentoo builds llvm, clang and lldb standalone. Maybe @mgorny 
> has a better overview of what other distros do...
Fair enough. So, in this case we just can't make a reasonable guess right?

Maybe we can still simplify the scenario for a single provided build-tree with 
LLVM and Clang? How could we do it?
I changed the comment and the condition to only infer the directory if it 
exists. Is that acceptable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798



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


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798



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


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz updated this revision to Diff 213834.
sgraenitz added a comment.

Change comment and condition to only infer Clang_DIR if it exists.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798

Files:
  lldb/cmake/modules/LLDBStandalone.cmake
  lldb/docs/resources/build.rst


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -323,7 +323,6 @@
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,5 +1,11 @@
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
+# If Clang was built in one tree with LLVM, we can infer its CMake module 
directory.
+if(NOT Clang_DIR AND EXISTS ${LLVM_DIR}/../clang)
+  set(Clang_DIR ${LLVM_DIR}/../clang)
+  message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")
+endif()
+
 find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" 
NO_CMAKE_FIND_ROOT_PATH)
 


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -323,7 +323,6 @@
   > cmake -B /path/to/lldb-build \
   -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake \
   -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
-  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
   llvm-project/lldb
   > open lldb.xcodeproj
   > cmake --build /path/to/lldb-build --target check-lldb
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,5 +1,11 @@
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
+# If Clang was built in one tree with LLVM, we can infer its CMake module directory.
+if(NOT Clang_DIR AND EXISTS ${LLVM_DIR}/../clang)
+  set(Clang_DIR ${LLVM_DIR}/../clang)
+  message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")
+endif()
+
 find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 find_package(Clang REQUIRED CONFIG HINTS "${Clang_DIR}" NO_CMAKE_FIND_ROOT_PATH)
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r368143 - [lldb][NFC] Fix typo in 368066

2019-08-07 Thread Stefan Granitz via lldb-commits
Author: stefan.graenitz
Date: Wed Aug  7 03:03:11 2019
New Revision: 368143

URL: http://llvm.org/viewvc/llvm-project?rev=368143=rev
Log:
[lldb][NFC] Fix typo in 368066

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

Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=368143=368142=368143=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Wed Aug  7 03:03:11 2019
@@ -75,7 +75,7 @@ if(APPLE AND CMAKE_GENERATOR STREQUAL Xc
   if(NOT LLDB_EXPLICIT_XCODE_CACHE_USED)
 message(WARNING
   "When building with Xcode, we recommend using the corresponding cache 
script. "
-  "If this was a mistake, clean your lean build directory and re-run CMake 
with:\n"
+  "If this was a mistake, clean your build directory and re-run CMake 
with:\n"
   "  -C ${CMAKE_SOURCE_DIR}/cmake/caches/Apple-lldb-Xcode.cmake\n"
   "See: 
https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject\n;)
   endif()


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


[Lldb-commits] [PATCH] D61565: Ignore generated @import statements in the expression evaluator

2019-08-07 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor updated this revision to Diff 213803.
teemperor retitled this revision from "Ignore generated @import statements in 
the expression evaluator to fix import-std-module tests on macOS" to "Ignore 
generated @import statements in the expression evaluator".
teemperor edited the summary of this revision.

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

https://reviews.llvm.org/D61565

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -105,16 +105,26 @@
 class ClangExpressionParser::LLDBPreprocessorCallbacks : public PPCallbacks {
   ClangModulesDeclVendor _decl_vendor;
   ClangPersistentVariables _persistent_vars;
+  clang::SourceManager _source_mgr;
   StreamString m_error_stream;
   bool m_has_errors = false;
 
 public:
   LLDBPreprocessorCallbacks(ClangModulesDeclVendor _vendor,
-ClangPersistentVariables _vars)
-  : m_decl_vendor(decl_vendor), m_persistent_vars(persistent_vars) {}
+ClangPersistentVariables _vars,
+clang::SourceManager _mgr)
+  : m_decl_vendor(decl_vendor), m_persistent_vars(persistent_vars),
+m_source_mgr(source_mgr) {}
 
   void moduleImport(SourceLocation import_location, clang::ModuleIdPath path,
 const clang::Module * /*null*/) override {
+// Ignore modules that are imported in the wrapper code as these are not
+// loaded by the user.
+llvm::StringRef filename =
+m_source_mgr.getPresumedLoc(import_location).getFilename();
+if (filename == "")
+  return;
+
 SourceModule module;
 
 for (const std::pair  : path)
@@ -572,8 +582,8 @@
 llvm::cast(
 target_sp->GetPersistentExpressionStateForLanguage(
 lldb::eLanguageTypeC));
-std::unique_ptr pp_callbacks(
-new LLDBPreprocessorCallbacks(*decl_vendor, *clang_persistent_vars));
+std::unique_ptr pp_callbacks(new LLDBPreprocessorCallbacks(
+*decl_vendor, *clang_persistent_vars, m_compiler->getSourceManager()));
 m_pp_callbacks =
 static_cast(pp_callbacks.get());
 m_compiler->getPreprocessor().addPPCallbacks(std::move(pp_callbacks));


Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -105,16 +105,26 @@
 class ClangExpressionParser::LLDBPreprocessorCallbacks : public PPCallbacks {
   ClangModulesDeclVendor _decl_vendor;
   ClangPersistentVariables _persistent_vars;
+  clang::SourceManager _source_mgr;
   StreamString m_error_stream;
   bool m_has_errors = false;
 
 public:
   LLDBPreprocessorCallbacks(ClangModulesDeclVendor _vendor,
-ClangPersistentVariables _vars)
-  : m_decl_vendor(decl_vendor), m_persistent_vars(persistent_vars) {}
+ClangPersistentVariables _vars,
+clang::SourceManager _mgr)
+  : m_decl_vendor(decl_vendor), m_persistent_vars(persistent_vars),
+m_source_mgr(source_mgr) {}
 
   void moduleImport(SourceLocation import_location, clang::ModuleIdPath path,
 const clang::Module * /*null*/) override {
+// Ignore modules that are imported in the wrapper code as these are not
+// loaded by the user.
+llvm::StringRef filename =
+m_source_mgr.getPresumedLoc(import_location).getFilename();
+if (filename == "")
+  return;
+
 SourceModule module;
 
 for (const std::pair  : path)
@@ -572,8 +582,8 @@
 llvm::cast(
 target_sp->GetPersistentExpressionStateForLanguage(
 lldb::eLanguageTypeC));
-std::unique_ptr pp_callbacks(
-new LLDBPreprocessorCallbacks(*decl_vendor, *clang_persistent_vars));
+std::unique_ptr pp_callbacks(new LLDBPreprocessorCallbacks(
+*decl_vendor, *clang_persistent_vars, m_compiler->getSourceManager()));
 m_pp_callbacks =
 static_cast(pp_callbacks.get());
 m_compiler->getPreprocessor().addPPCallbacks(std::move(pp_callbacks));
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D61565: Ignore generated @import statements in the expression evaluator

2019-08-07 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor marked 3 inline comments as done.
teemperor added a comment.

- Moved from macro to source file name filtering. No longer enable the tests 
with this patch as we still have the include path bug to fix.




Comment at: 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:141
+// loaded by the user. We can stop here as we only care about user-loaded
+// modules.
+if (!m_entered_expr)

aprantl wrote:
> Just to make sure I'm understanding:
> 
> `expr @import Foo` will still work, but it will import Foo into the 
> expression rather than into the context from which we ASTImport definitions?
Yeah, we only filter our own generated imports that are non-permanent and only 
for one expression.


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

https://reviews.llvm.org/D61565



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


[Lldb-commits] [PATCH] D48704: [ExecutionContext] Return the target/process byte order.

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.

Thanks for setting this up. The infrastructure is a bit overkill for a simple 
test like this, but hopefully this can be useful for other tests too. I have a 
bunch of comments, but hopefully none of them are major, so if you agree with 
all of them, just fire away..




Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:40-43
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+platform_linux::PlatformLinux::Terminate();

call terminate in reverse order?



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:77
+TEST_F(ExecutionContextTest, GetByteOrderTarget) {
+  ArchSpec arch = Target::GetDefaultArchitecture();
+  arch.SetTriple("armv7-pc-apple");

I don't understand this.. Why do you fetch the ArchSpec via 
`Target::GetDefaultArchitecture()` and then immediately overwrite it on the 
next line? Can this line just be deleted?



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:78
+  ArchSpec arch = Target::GetDefaultArchitecture();
+  arch.SetTriple("armv7-pc-apple");
+

It looks weird to have an apple triple with a linux platform. I am assuming you 
use the linux platform because it can be compiled everywhere, but in that case, 
maybe you could use a linux triple too? Maybe also use a big-endian triple in 
one of the tests to catch regressions regardless of the endianness of the host?



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:85
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  EXPECT_TRUE(debugger_sp);
+

change EXPECT_TRUE to ASSERT_TRUE. There's no point in continuing the test if 
this is false, as it will just crash anyway...



Comment at: lldb/unittests/Target/ExecutionContextTest.cpp:124
+  ExecutionContext process_ctx(process_sp);
+  EXPECT_EQ(process_sp->GetByteOrder(), process_ctx.GetByteOrder());
+}

It doesn't look like the presence of a process will change what 
ExecutionContext::GetByteOrder returns, as it checks the target first. OTOH, I 
don't know why would the byte order of a process be ever different from the 
byte order of its target...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D48704



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


[Lldb-commits] [PATCH] D48704: [LLDB] Fix for "Bug 37950: ExecutionContext::GetByteOrder() always returns endian::InlHostByteOrder()"

2019-08-07 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 213797.
JDevlieghere added a comment.
Herald added a subscriber: mgorny.

Add unit test


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D48704

Files:
  lldb/source/Target/ExecutionContext.cpp
  lldb/unittests/Target/CMakeLists.txt
  lldb/unittests/Target/ExecutionContextTest.cpp

Index: lldb/unittests/Target/ExecutionContextTest.cpp
===
--- /dev/null
+++ lldb/unittests/Target/ExecutionContextTest.cpp
@@ -0,0 +1,125 @@
+//===-- ExecutionContextTest.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Target/ExecutionContext.h"
+#include "Plugins/Platform/Linux/PlatformLinux.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Target/Platform.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/Endian.h"
+#include "lldb/Utility/Reproducer.h"
+#include "lldb/lldb-enumerations.h"
+#include "lldb/lldb-forward.h"
+#include "lldb/lldb-private-enumerations.h"
+#include "lldb/lldb-private.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb_private::repro;
+using namespace lldb;
+
+class ExecutionContextTest : public ::testing::Test {
+public:
+  void SetUp() override {
+llvm::cantFail(Reproducer::Initialize(ReproducerMode::Off, llvm::None));
+FileSystem::Initialize();
+HostInfo::Initialize();
+platform_linux::PlatformLinux::Initialize();
+  }
+  void TearDown() override {
+HostInfo::Terminate();
+FileSystem::Terminate();
+Reproducer::Terminate();
+platform_linux::PlatformLinux::Terminate();
+  }
+};
+
+class DummyProcess : public Process {
+public:
+  using Process::Process;
+
+  virtual bool CanDebug(lldb::TargetSP target, bool plugin_specified_by_name) {
+return true;
+  }
+  virtual Status DoDestroy() { return {}; }
+  virtual void RefreshStateAfterStop() {}
+
+  virtual size_t DoReadMemory(lldb::addr_t vm_addr, void *buf, size_t size,
+  Status ) {
+return 0;
+  }
+
+  virtual bool UpdateThreadList(ThreadList _thread_list,
+ThreadList _thread_list) {
+return false;
+  }
+
+  virtual ConstString GetPluginName() { return ConstString("Dummy"); }
+  virtual uint32_t GetPluginVersion() { return 0; }
+};
+
+TEST_F(ExecutionContextTest, GetByteOrder) {
+  ExecutionContext exe_ctx(nullptr, nullptr, nullptr);
+  EXPECT_EQ(endian::InlHostByteOrder(), exe_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderTarget) {
+  ArchSpec arch = Target::GetDefaultArchitecture();
+  arch.SetTriple("armv7-pc-apple");
+
+  PlatformSP platform =
+  platform_linux::PlatformLinux::CreateInstance(true, );
+  Platform::SetHostPlatform(platform);
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  EXPECT_TRUE(debugger_sp);
+
+  TargetSP target_sp;
+  PlatformSP platform_sp;
+  Status error = debugger_sp->GetTargetList().CreateTarget(
+  *debugger_sp, "", arch, eLoadDependentsNo, platform_sp, target_sp);
+  EXPECT_TRUE(target_sp);
+  EXPECT_TRUE(target_sp->GetArchitecture().IsValid());
+  EXPECT_TRUE(platform_sp);
+
+  ExecutionContext target_ctx(target_sp, false);
+  EXPECT_EQ(target_sp->GetArchitecture().GetByteOrder(),
+target_ctx.GetByteOrder());
+}
+
+TEST_F(ExecutionContextTest, GetByteOrderProcess) {
+  ArchSpec arch = Target::GetDefaultArchitecture();
+  arch.SetTriple("armv7-pc-apple");
+
+  PlatformSP platform =
+  platform_linux::PlatformLinux::CreateInstance(true, );
+  Platform::SetHostPlatform(platform);
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  EXPECT_TRUE(debugger_sp);
+
+  TargetSP target_sp;
+  PlatformSP platform_sp;
+  Status error = debugger_sp->GetTargetList().CreateTarget(
+  *debugger_sp, "", arch, eLoadDependentsNo, platform_sp, target_sp);
+  EXPECT_TRUE(target_sp);
+  EXPECT_TRUE(target_sp->GetArchitecture().IsValid());
+  EXPECT_TRUE(platform_sp);
+
+  ListenerSP listener_sp(Listener::MakeListener("dummy"));
+  ProcessSP process_sp = std::make_shared(target_sp, listener_sp);
+  EXPECT_TRUE(process_sp);
+
+  ExecutionContext process_ctx(process_sp);
+  EXPECT_EQ(process_sp->GetByteOrder(), process_ctx.GetByteOrder());
+}
Index: lldb/unittests/Target/CMakeLists.txt
===
--- lldb/unittests/Target/CMakeLists.txt
+++ lldb/unittests/Target/CMakeLists.txt
@@ -1,4 +1,5 @@
 

[Lldb-commits] [PATCH] D65822: Detect HAVE_SYS_TYPES_H in lldb

2019-08-07 Thread Haibo Huang via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368125: Detect HAVE_SYS_TYPES_H in lldb (authored by hhb, 
committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65822?vs=213726=213796#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65822

Files:
  lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake
  lldb/trunk/include/lldb/Host/Config.h.cmake
  lldb/trunk/include/lldb/Host/windows/PosixApi.h
  lldb/trunk/source/Expression/UserExpression.cpp
  lldb/trunk/source/Expression/UtilityFunction.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
  lldb/trunk/tools/driver/Platform.h

Index: lldb/trunk/include/lldb/Host/windows/PosixApi.h
===
--- lldb/trunk/include/lldb/Host/windows/PosixApi.h
+++ lldb/trunk/include/lldb/Host/windows/PosixApi.h
@@ -9,6 +9,7 @@
 #ifndef liblldb_Host_windows_PosixApi_h
 #define liblldb_Host_windows_PosixApi_h
 
+#include "lldb/Host/Config.h"
 #include "llvm/Support/Compiler.h"
 #if !defined(_WIN32)
 #error "windows/PosixApi.h being #included on non Windows system!"
@@ -45,14 +46,14 @@
 #define S_IRWXG 0
 #define S_IRWXO 0
 
-#ifdef __MINGW32__
+#if HAVE_SYS_TYPES_H
 // pyconfig.h typedefs this.  We require python headers to be included before
 // any LLDB headers, but there's no way to prevent python's pid_t definition
 // from leaking, so this is the best option.
 #ifndef NO_PID_T
 #include 
 #endif
-#endif // __MINGW32__
+#endif // HAVE_SYS_TYPES_H
 
 #ifdef _MSC_VER
 
Index: lldb/trunk/include/lldb/Host/Config.h.cmake
===
--- lldb/trunk/include/lldb/Host/Config.h.cmake
+++ lldb/trunk/include/lldb/Host/Config.h.cmake
@@ -19,6 +19,8 @@
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 
+#cmakedefine01 HAVE_SYS_TYPES_H
+
 #cmakedefine01 HAVE_SYS_EVENT_H
 
 #cmakedefine01 HAVE_PPOLL
Index: lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake
@@ -12,6 +12,7 @@
 check_cxx_symbol_exists(accept4 "sys/socket.h" HAVE_ACCEPT4)
 
 check_include_file(termios.h HAVE_TERMIOS_H)
+check_include_file("sys/types.h" HAVE_SYS_TYPES_H)
 check_include_files("sys/types.h;sys/event.h" HAVE_SYS_EVENT_H)
 
 check_cxx_symbol_exists(process_vm_readv "sys/uio.h" HAVE_PROCESS_VM_READV)
Index: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "lldb/Host/Config.h"
+
 #include "ClangUtilityFunction.h"
 #include "ClangExpressionDeclMap.h"
 #include "ClangExpressionParser.h"
Index: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "lldb/Host/Config.h"
+
 #include 
 #if HAVE_SYS_TYPES_H
 #include 
Index: lldb/trunk/source/Expression/UtilityFunction.cpp
===
--- lldb/trunk/source/Expression/UtilityFunction.cpp
+++ lldb/trunk/source/Expression/UtilityFunction.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "lldb/Host/Config.h"
+
 #include 
 #if HAVE_SYS_TYPES_H
 #include 
Index: lldb/trunk/source/Expression/UserExpression.cpp
===
--- lldb/trunk/source/Expression/UserExpression.cpp
+++ lldb/trunk/source/Expression/UserExpression.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "lldb/Host/Config.h"
+
 #include 
 #if HAVE_SYS_TYPES_H
 #include 
Index: lldb/trunk/tools/driver/Platform.h
===
--- lldb/trunk/tools/driver/Platform.h
+++ lldb/trunk/tools/driver/Platform.h
@@ -9,6 +9,8 @@
 #ifndef lldb_Platform_h_
 #define lldb_Platform_h_
 
+#include "lldb/Host/Config.h"
+
 #if defined(_WIN32)
 
 #include 
___
lldb-commits mailing list

[Lldb-commits] [PATCH] D65822: Detect HAVE_SYS_TYPES_H in lldb

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

Woops, this is quite embarrassing. :/

One day we should audit these to check which of these files really needs to 
include this header, but since there are at least some files that definitely 
need it, adding the cmake check is the right way to go...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65822



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


[Lldb-commits] [PATCH] D65798: [lldb][CMake] Infer `Clang_DIR` if not passed explicitly

2019-08-07 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/cmake/modules/LLDBStandalone.cmake:6
+  # next to LLVM's module directory.
+  set(Clang_DIR ${LLVM_DIR}/../clang)
+  message(STATUS "Inferred Clang_DIR: ${Clang_DIR}")

sgraenitz wrote:
> compnerd wrote:
> > sgraenitz wrote:
> > > compnerd wrote:
> > > > What happens in the standalone clang build scenario?  Can I ask what is 
> > > > the motivation for this change?  I think it is better to require that 
> > > > the user pass the path, as that is an explicit dependency of LLDB.
> > > I don't think there's any side-effects on Clang standalone builds. Is 
> > > that what you mean with "standalone clang build scenario"?
> > > 
> > > I would like top prevent people from writing custom build scripts on top 
> > > of CMake. Passing a number of very similar paths to CMake, e.g. each time 
> > > we want to generate a Xcode project for development, this option seems to 
> > > become compelling quickly. This patch makes standalone configurations 
> > > simpler. Basically, it provides a default value. I doesn't cut down 
> > > functionality.
> > > 
> > > You can still explicitly pass any path you want. This branch will then 
> > > not be taken.
> > I think that the build fragmentation has caused a larger problem, and I 
> > would like to avoid that.  The standalone build scenario is:
> > 
> > build/llvm
> > build/clang
> > build/lldb
> > 
> > In this case, `../clang` does not exist (`../../clang/lib/cmake/clang` 
> > does).  I think what I would suggest instead is adding a cache file that 
> > has the configuration parameters setup already.
> For the scenario you describe, can you point me to any documentation that 
> describes it or a bot that builds it?
> 
> > I think what I would suggest instead is adding a cache file that has the 
> > configuration parameters setup already.
> 
> How would your cache file look like?
> For the scenario you describe, can you point me to any documentation that 
> describes it or a bot that builds it?

I think a lot of linux distributions which want to provide llvm,clang,etc. as 
separate packages build in this way. And those that don't, they'd probably want 
to build it that way, but they can't do it because it doesn't work for them for 
one reason or another (the standalone builds are always a bit behind, because 
the devs usually just build everything monolithically). I know at least gentoo 
builds llvm, clang and lldb standalone. Maybe @mgorny has a better overview of 
what other distros do...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65798



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