[Lldb-commits] [PATCH] D42488: Remove ObjectFile usage from HostLinux::GetProcessInfo

[Pavel Labath via Phabricator via lldb-commits]

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

Ok, so the issue was a subsequent MergeFrom(HostArchitecture) call which was
overwriting the invalid ArchSpec I was returning here. I think this was present
there to fill in the bits we could not get from the ObjectFile (like some
environment details). Since now I am returning the ArchSpec I get from HostInfo,
the merge will become a no-op in the success case and produce garbage in case
the detection fails -- so I just remove the merge call.


https://reviews.llvm.org/D42488

Files:
  include/lldb/Host/common/NativeProcessProtocol.h
  include/lldb/Utility/ArchSpec.h
  source/Host/CMakeLists.txt
  source/Host/common/NativeProcessProtocol.cpp
  source/Host/linux/Host.cpp
  source/Plugins/Process/Linux/NativeProcessLinux.cpp
  source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
  source/Utility/ArchSpec.cpp
  unittests/Host/linux/HostTest.cpp

Index: unittests/Host/linux/HostTest.cpp
===
--- unittests/Host/linux/HostTest.cpp
+++ unittests/Host/linux/HostTest.cpp
@@ -45,4 +45,8 @@
 
   ASSERT_TRUE(Info.GroupIDIsValid());
   EXPECT_EQ(getegid(), Info.GetGroupID());
+
+  EXPECT_TRUE(Info.GetArchitecture().IsValid());
+  EXPECT_EQ(HostInfo::GetArchitecture(HostInfo::eArchKindDefault),
+Info.GetArchitecture());
 }
Index: source/Utility/ArchSpec.cpp
===
--- source/Utility/ArchSpec.cpp
+++ source/Utility/ArchSpec.cpp
@@ -1416,6 +1416,11 @@
   return lhs_core < rhs_core;
 }
 
+
+bool lldb_private::operator==(const ArchSpec &lhs, const ArchSpec &rhs) {
+  return lhs.GetCore() == rhs.GetCore();
+}
+
 bool ArchSpec::IsFullySpecifiedTriple() const {
   const auto &user_specified_triple = GetTriple();
 
Index: source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
===
--- source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
+++ source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
@@ -93,17 +93,19 @@
   }
   LLDB_LOG(log, "inferior started, now in stopped state");
 
-  ArchSpec arch;
-  if ((status = ResolveProcessArchitecture(pid, arch)).Fail())
-return status.ToError();
+  ProcessInstanceInfo Info;
+  if (!Host::GetProcessInfo(pid, Info)) {
+return llvm::make_error("Cannot get process architecture",
+ llvm::inconvertibleErrorCode());
+  }
 
   // Set the architecture to the exe architecture.
   LLDB_LOG(log, "pid = {0:x}, detected architecture {1}", pid,
-   arch.GetArchitectureName());
+   Info.GetArchitecture().GetArchitectureName());
 
   std::unique_ptr process_up(new NativeProcessNetBSD(
   pid, launch_info.GetPTY().ReleaseMasterFileDescriptor(), native_delegate,
-  arch, mainloop));
+  Info.GetArchitecture(), mainloop));
 
   status = process_up->ReinitializeThreads();
   if (status.Fail())
@@ -124,13 +126,14 @@
   LLDB_LOG(log, "pid = {0:x}", pid);
 
   // Retrieve the architecture for the running process.
-  ArchSpec arch;
-  Status status = ResolveProcessArchitecture(pid, arch);
-  if (!status.Success())
-return status.ToError();
+  ProcessInstanceInfo Info;
+  if (!Host::GetProcessInfo(pid, Info)) {
+return llvm::make_error("Cannot get process architecture",
+ llvm::inconvertibleErrorCode());
+  }
 
-  std::unique_ptr process_up(
-  new NativeProcessNetBSD(pid, -1, native_delegate, arch, mainloop));
+  std::unique_ptr process_up(new NativeProcessNetBSD(
+  pid, -1, native_delegate, Info.GetArchitecture(), mainloop));
 
   status = process_up->Attach();
   if (!status.Success())
Index: source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -26,7 +26,6 @@
 #include "lldb/Core/EmulateInstruction.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/RegisterValue.h"
-#include "lldb/Utility/State.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/HostProcess.h"
 #include "lldb/Host/PseudoTerminal.h"
@@ -41,6 +40,7 @@
 #include "lldb/Target/ProcessLaunchInfo.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/LLDBAssert.h"
+#include "lldb/Utility/State.h"
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/StringExtractor.h"
 #include "llvm/Support/Errno.h"
@@ -245,13 +245,15 @@
   }
   LLDB_LOG(log, "inferior started, now in stopped state");
 
-  ArchSpec arch;
-  if ((status = ResolveProcessArchitecture(pid, arch)).Fail())
-return status.ToError();
+  ProcessInstanceInfo Info;
+  if (!Host::GetProcessInfo(pid, Info)) {
+return llvm::make_error("Cannot get process architecture",
+ llvm::inconvertibleErrorCode());
+  }
 
  

[Lldb-commits] [PATCH] D31451: New C++ function name parsing logic

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

This code is processing demangled names. Since you say (I could not get my 
demangler to process it either) the symbol demangles to a multi-megabyte name, 
we can probably make the cutoff even longer then 1000 bytes.

OTOH, if we abort demangling of such names in the first place, then this code 
will not even get used.


Repository:
  rL LLVM

https://reviews.llvm.org/D31451



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

[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior

[Pavel Labath via Phabricator via lldb-commits]

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

This is great. Thank you for doing this. I think we're ready to wrap this up.


https://reviews.llvm.org/D42195



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

[Lldb-commits] [PATCH] D31451: New C++ function name parsing logic

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In https://reviews.llvm.org/D31451#987537, @labath wrote:

> This code is processing demangled names. Since you say (I could not get my 
> demangler to process it either) the symbol demangles to a multi-megabyte 
> name, we can probably make the cutoff even longer then 1000 bytes.


Problem is we don't have a cutoff when using the libc++ demangler. There is no 
such features. c++filt just calls into the system 
(abi::__cxa_demangle(mangled_name, NULL, NULL, NULL)) demangler. We seem to now 
try our fast demangler, and then fall back to "llvm::itaniumDemangle(...)".

We would switch over to using llvm::itaniumDemangle() all the time and then we 
could modify this call to have a max length. I believe the code inside 
llvm::itaniumDemangle is currently an exact local copy of 
abi::__cxa_demangle(), so it would involve some maintenance as they try to keep 
in sync with abi::__cxa_demangle() if we modify it...

> OTOH, if we abort demangling of such names in the first place, then this code 
> will not even get used.

The main question is how do we know what we should demangle and what we 
shouldn't _before_ we try to demangle it. No easy answer to that.


Repository:
  rL LLVM

https://reviews.llvm.org/D31451



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

[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.

Thanks for iterating on this. This will be great.


https://reviews.llvm.org/D42195



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

[Lldb-commits] [PATCH] D42488: Remove ObjectFile usage from HostLinux::GetProcessInfo

[Kamil Rytarowski via Phabricator via lldb-commits]

krytarowski added a comment.

Looks fine.


https://reviews.llvm.org/D42488



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

[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior

[Owen Shaw via Phabricator via lldb-commits]

owenpshaw added a comment.

Thanks for the help!  Someone with commit access will need to land it.


https://reviews.llvm.org/D42195



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

[Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

Author: vedantk
Date: Thu Jan 25 10:01:27 2018
New Revision: 323450

URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
Log:
Use test-specific module caches to avoid stale header conflicts

Stale global module caches cause problems for the bots. The modules
become invalid when clang headers are updated by version control, and
tests which use these modules fail to compile, e.g:

  fatal error: file '.../__stddef_max_align_t.h' has been modified since the 
module file '/var/.../Darwin.pcm' was built
  note: please rebuild precompiled header '/var/.../Darwin.pcm'

Eventually we should transition to having just a single module cache to speed
tests up. This patch should be just enough to fix the spurious bot failures due
to stale caches.

rdar://36479805, also related to llvm.org/PR36048

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/Makefile

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py
lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py?rev=323450&r1=323449&r2=323450&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
 Thu Jan 25 10:01:27 2018
@@ -26,6 +26,8 @@ class CppDataFormatterTestCase(TestBase)
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr24462: Data formatters have problems on Windows")
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py?rev=323450&r1=323449&r2=323450&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
 Thu Jan 25 10:01:27 2018
@@ -9,6 +9,7 @@ import os
 import time
 import lldb
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
 
 
@@ -22,6 +23,8 @@ class GlobalsDataFormatterTestCase(TestB
 # Find the line number to break at.
 self.line = line_number('main.cpp', '// Set break point at this line.')
 
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py?rev=323450&r1=323449&r2=323450&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/tes

[Lldb-commits] [PATCH] D42277: Use test-specific module caches to avoid stale header conflicts

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL323450: Use test-specific module caches to avoid stale 
header conflicts (authored by vedantk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D42277?vs=131000&id=131475#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42277

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py
  lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules

Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
@@ -31,6 +31,8 @@
  '// Set fourth break point at this line.')
 
 @add_test_categories(["libc++"])
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
@@ -18,6 +18,8 @@
 mydir = TestBase.compute_mydir(__file__)
 
 @add_test_categories(["libc++"])
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
@@ -26,6 +26,8 @@
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr24462: Data formatters have problems on Windows")
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
@@ -9,6 +9,7 @@
 import time
 import lldb
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
 
 
@@ -22,6 +23,8 @@
 # Find the line number to break at.
 self.line = line_number('main.cpp', '// Set break point at this line.')
 
+@skipIf(debug_info="gmodules",
+bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
 def test_wi

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Davide Italiano via lldb-commits]

The bot started failing recently, and this commit seems the most likely culprit.

http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/


Can you please take a look, Vedant?

Thanks,

--
Davide

On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
 wrote:
> Author: vedantk
> Date: Thu Jan 25 10:01:27 2018
> New Revision: 323450
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
> Log:
> Use test-specific module caches to avoid stale header conflicts
>
> Stale global module caches cause problems for the bots. The modules
> become invalid when clang headers are updated by version control, and
> tests which use these modules fail to compile, e.g:
>
>   fatal error: file '.../__stddef_max_align_t.h' has been modified since the 
> module file '/var/.../Darwin.pcm' was built
>   note: please rebuild precompiled header '/var/.../Darwin.pcm'
>
> Eventually we should transition to having just a single module cache to speed
> tests up. This patch should be just enough to fix the spurious bot failures 
> due
> to stale caches.
>
> rdar://36479805, also related to llvm.org/PR36048
>
> Differential Revision: https://reviews.llvm.org/D42277
>
> Modified:
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/Makefile
> 
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py
> lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py?rev=323450&r1=323449&r2=323450&view=diff
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>  (original)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>  Thu Jan 25 10:01:27 2018
> @@ -26,6 +26,8 @@ class CppDataFormatterTestCase(TestBase)
>  @expectedFailureAll(
>  oslist=["windows"],
>  bugnumber="llvm.org/pr24462: Data formatters have problems on 
> Windows")
> +@skipIf(debug_info="gmodules",
> +bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
>  def test_with_run_command(self):
>  """Test that that file and class static variables display 
> correctly."""
>  self.build()
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py?rev=323450&r1=323449&r2=323450&view=diff
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>  (original)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>  Thu Jan 25 10:01:27 2018
> @@ -9,6 +9,7 @@ import os
>  import time
>  import lldb
>  from lldbsuite.test.lldbtest import *
> +from lldbsuite.test.decorators import *
>  import lldbsuite.test.lldbutil as lldbutil
>
>
> @@ -22,6 +23,8 @@ class GlobalsDataFormatterTestCase(TestB
>  # Find the line number to break at.
>  self.line = line_number('main.cpp', '// Set break point at this 
> line.')
>
> +@skipIf(debug_info="gmodules",
> +bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
>  def test_with_run_command(self):
>  """Test that that file and class static variables display 
> correctly."""
>  self.build()
>
> Modified: 
> lldb/

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

Taking a look. It may be another instance of a test not actually running with 
-fmodules in the -gmodules configuration.

vedant

> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
> 
> The bot started failing recently, and this commit seems the most likely 
> culprit.
> 
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
> 
> 
> Can you please take a look, Vedant?
> 
> Thanks,
> 
> --
> Davide
> 
> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>  wrote:
>> Author: vedantk
>> Date: Thu Jan 25 10:01:27 2018
>> New Revision: 323450
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
>> Log:
>> Use test-specific module caches to avoid stale header conflicts
>> 
>> Stale global module caches cause problems for the bots. The modules
>> become invalid when clang headers are updated by version control, and
>> tests which use these modules fail to compile, e.g:
>> 
>>  fatal error: file '.../__stddef_max_align_t.h' has been modified since the 
>> module file '/var/.../Darwin.pcm' was built
>>  note: please rebuild precompiled header '/var/.../Darwin.pcm'
>> 
>> Eventually we should transition to having just a single module cache to speed
>> tests up. This patch should be just enough to fix the spurious bot failures 
>> due
>> to stale caches.
>> 
>> rdar://36479805, also related to llvm.org/PR36048
>> 
>> Differential Revision: https://reviews.llvm.org/D42277
>> 
>> Modified:
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/Makefile
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py
>>lldb/trunk/packages/Python/lldbsuite/test/make/Makefile.rules
>> 
>> Modified: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py?rev=323450&r1=323449&r2=323450&view=diff
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>>  Thu Jan 25 10:01:27 2018
>> @@ -26,6 +26,8 @@ class CppDataFormatterTestCase(TestBase)
>> @expectedFailureAll(
>> oslist=["windows"],
>> bugnumber="llvm.org/pr24462: Data formatters have problems on 
>> Windows")
>> +@skipIf(debug_info="gmodules",
>> +bugnumber="https://bugs.llvm.org/show_bug.cgi?id=36048";)
>> def test_with_run_command(self):
>> """Test that that file and class static variables display 
>> correctly."""
>> self.build()
>> 
>> Modified: 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py?rev=323450&r1=323449&r2=323450&view=diff
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>>  Thu Jan 25 10:01:27 2018
>> @@ -9,6 +9,7 @@ import os
>> import time
>> import lldb
>> from lldbsuite.test.lldbtest import *
>> +from lldbsuite.test.decorators import *
>> import lldbsuite.test.lldbutil as lldbutil
>> 
>> 
>> @@ -22,6 +23,8 @@ class GlobalsDataFormatterTestCase(TestB
>> # Find the line number to break at.
>> self.line = line_number('main.cpp', '// Set break point at th

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

The test passes locally, but the cmake job is failing in the exact same way as 
the Xcode one. Based on the error, it looks like the compiler invocation has 
failed.

.. and, aha!, here is the failed invocation:

green-dragon-23:non-overlapping-index-variable-i buildslave$ make MAKE_DSYM=NO 
MAKE_GMODULES=YES ARCH=x86_64 
CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0  
-std=c++11 -g -O0 -fno-builtin -arch x86_64  
-I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
 -include 
/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
 
-I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
  -fno-limit-debug-info   -fmodules -gmodules -fmodules-cache-path=module-cache 
--driver-mode=g++ -c -o main.o main.cpp
main.cpp:27:9: error: no matching constructor for initialization of 'Point'
point(0, 0)
^ 
/usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit copy 
constructor) not viable: requires 1 argument, but 2 were provided
struct Point {
   ^
/usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit move 
constructor) not viable: requires 1 argument, but 2 were provided
/usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit 
default constructor) not viable: requires 0 arguments, but 2 were provided
main.cpp:36:23: error: no member named 'x' in 'Point'
ptr[i]->point.x = i;
~ ^
main.cpp:37:23: error: no member named 'y' in 'Point'
ptr[i]->point.y = i+1;
~ ^
main.cpp:47:77: error: no member named 'x' in 'Point'
printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id, ptr[i]->point.x, 
ptr[i]->point.y);
  ~ ^
main.cpp:47:94: error: no member named 'y' in 'Point'
printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id, ptr[i]->point.x, 
ptr[i]->point.y);
   
~ ^
5 errors generated.
make: *** [main.o] Error 1

It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!

vedant

> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
> 
> Taking a look. It may be another instance of a test not actually running with 
> -fmodules in the -gmodules configuration.
> 
> vedant
> 
>> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>> 
>> The bot started failing recently, and this commit seems the most likely 
>> culprit.
>> 
>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>> 
>> 
>> Can you please take a look, Vedant?
>> 
>> Thanks,
>> 
>> --
>> Davide
>> 
>> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>>  wrote:
>>> Author: vedantk
>>> Date: Thu Jan 25 10:01:27 2018
>>> New Revision: 323450
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
>>> Log:
>>> Use test-specific module caches to avoid stale header conflicts
>>> 
>>> Stale global module caches cause problems for the bots. The modules
>>> become invalid when clang headers are updated by version control, and
>>> tests which use these modules fail to compile, e.g:
>>> 
>>> fatal error: file '.../__stddef_max_align_t.h' has been modified since the 
>>> module file '/var/.../Darwin.pcm' was built
>>> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>>> 
>>> Eventually we should transition to having just a single module cache to 
>>> speed
>>> tests up. This patch should be just enough to fix the spurious bot failures 
>>> due
>>> to stale caches.
>>> 
>>> rdar://36479805, also related to llvm.org/PR36048
>>> 
>>> Differential Revision: https://reviews.llvm.org/D42277
>>> 
>>> Modified:
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
>>>   
>>> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-i

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

We *could* x-fail this test on older OS's, but ISTM that we don't need this 
test to printf at all, so let's just remove the #include?

vedant

> On Jan 25, 2018, at 1:14 PM, Vedant Kumar  wrote:
> 
> The test passes locally, but the cmake job is failing in the exact same way 
> as the Xcode one. Based on the error, it looks like the compiler invocation 
> has failed.
> 
> .. and, aha!, here is the failed invocation:
> 
> green-dragon-23:non-overlapping-index-variable-i buildslave$ make 
> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64 
> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0  
> -std=c++11 -g -O0 -fno-builtin -arch x86_64  
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
>  -include 
> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
>  
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
>   -fno-limit-debug-info   -fmodules -gmodules 
> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
> point(0, 0)
> ^ 
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit copy 
> constructor) not viable: requires 1 argument, but 2 were provided
> struct Point {
>^
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit move 
> constructor) not viable: requires 1 argument, but 2 were provided
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit 
> default constructor) not viable: requires 0 arguments, but 2 were provided
> main.cpp:36:23: error: no member named 'x' in 'Point'
> ptr[i]->point.x = i;
> ~ ^
> main.cpp:37:23: error: no member named 'y' in 'Point'
> ptr[i]->point.y = i+1;
> ~ ^
> main.cpp:47:77: error: no member named 'x' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id, 
> ptr[i]->point.x, ptr[i]->point.y);
>   ~ ^
> main.cpp:47:94: error: no member named 'y' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id, 
> ptr[i]->point.x, ptr[i]->point.y);
>   
>  ~ ^
> 5 errors generated.
> make: *** [main.o] Error 1
> 
> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
> 
> vedant
> 
>> On Jan 25, 2018, at 1:02 PM, Vedant Kumar > > wrote:
>> 
>> Taking a look. It may be another instance of a test not actually running 
>> with -fmodules in the -gmodules configuration.
>> 
>> vedant
>> 
>>> On Jan 25, 2018, at 12:40 PM, Davide Italiano >> > wrote:
>>> 
>>> The bot started failing recently, and this commit seems the most likely 
>>> culprit.
>>> 
>>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/ 
>>> 
>>> 
>>> 
>>> Can you please take a look, Vedant?
>>> 
>>> Thanks,
>>> 
>>> --
>>> Davide
>>> 
>>> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>>>  wrote:
 Author: vedantk
 Date: Thu Jan 25 10:01:27 2018
 New Revision: 323450
 
 URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
 Log:
 Use test-specific module caches to avoid stale header conflicts
 
 Stale global module caches cause problems for the bots. The modules
 become invalid when clang headers are updated by version control, and
 tests which use these modules fail to compile, e.g:
 
 fatal error: file '.../__stddef_max_align_t.h' has been modified since the 
 module file '/var/.../Darwin.pcm' was built
 note: please rebuild precompiled header '/var/.../Darwin.pcm'
 
 Eventually we should transition to having just a single module cache to 
 speed
 tests up. This patch should be just enough to fix the spurious bot 
 failures due
 to stale caches.
 
 rdar://36479805, also related to llvm.org/PR36048
 
 Differential Revision: https://reviews.llvm.org/D42277
 
 Modified:
   
 lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
   
 lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
   
 lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
   
 lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormat

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Davide Italiano via lldb-commits]

I see, thanks.
It looks like this is illformed C++, I'll take a look.

Thanks,

--
Davide

On Thu, Jan 25, 2018 at 1:14 PM, Vedant Kumar  wrote:
> The test passes locally, but the cmake job is failing in the exact same way
> as the Xcode one. Based on the error, it looks like the compiler invocation
> has failed.
>
> .. and, aha!, here is the failed invocation:
>
> green-dragon-23:non-overlapping-index-variable-i buildslave$ make
> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64
> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0
> -std=c++11 -g -O0 -fno-builtin -arch x86_64
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
> -include
> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
> -fno-limit-debug-info   -fmodules -gmodules
> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
> point(0, 0)
> ^ 
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> copy constructor) not viable: requires 1 argument, but 2 were provided
> struct Point {
>^
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> move constructor) not viable: requires 1 argument, but 2 were provided
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> default constructor) not viable: requires 0 arguments, but 2 were provided
> main.cpp:36:23: error: no member named 'x' in 'Point'
> ptr[i]->point.x = i;
> ~ ^
> main.cpp:37:23: error: no member named 'y' in 'Point'
> ptr[i]->point.y = i+1;
> ~ ^
> main.cpp:47:77: error: no member named 'x' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
>   ~
> ^
> main.cpp:47:94: error: no member named 'y' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
>
> ~ ^
> 5 errors generated.
> make: *** [main.o] Error 1
>
> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
>
> vedant
>
> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
>
> Taking a look. It may be another instance of a test not actually running
> with -fmodules in the -gmodules configuration.
>
> vedant
>
> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>
> The bot started failing recently, and this commit seems the most likely
> culprit.
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>
>
> Can you please take a look, Vedant?
>
> Thanks,
>
> --
> Davide
>
> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>  wrote:
>
> Author: vedantk
> Date: Thu Jan 25 10:01:27 2018
> New Revision: 323450
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
> Log:
> Use test-specific module caches to avoid stale header conflicts
>
> Stale global module caches cause problems for the bots. The modules
> become invalid when clang headers are updated by version control, and
> tests which use these modules fail to compile, e.g:
>
> fatal error: file '.../__stddef_max_align_t.h' has been modified since the
> module file '/var/.../Darwin.pcm' was built
> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>
> Eventually we should transition to having just a single module cache to
> speed
> tests up. This patch should be just enough to fix the spurious bot failures
> due
> to stale caches.
>
> rdar://36479805, also related to llvm.org/PR36048
>
> Differential Revision: https://reviews.llvm.org/D42277
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/TestIncompleteModules.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-inline-functi

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Davide Italiano via lldb-commits]

yes, sure, I think that's the right thing to do.

--
Davide

On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar  wrote:
> We *could* x-fail this test on older OS's, but ISTM that we don't need this
> test to printf at all, so let's just remove the #include?
>
> vedant
>
> On Jan 25, 2018, at 1:14 PM, Vedant Kumar  wrote:
>
> The test passes locally, but the cmake job is failing in the exact same way
> as the Xcode one. Based on the error, it looks like the compiler invocation
> has failed.
>
> .. and, aha!, here is the failed invocation:
>
> green-dragon-23:non-overlapping-index-variable-i buildslave$ make
> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64
> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0
> -std=c++11 -g -O0 -fno-builtin -arch x86_64
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
> -include
> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
> -fno-limit-debug-info   -fmodules -gmodules
> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
> point(0, 0)
> ^ 
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> copy constructor) not viable: requires 1 argument, but 2 were provided
> struct Point {
>^
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> move constructor) not viable: requires 1 argument, but 2 were provided
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> default constructor) not viable: requires 0 arguments, but 2 were provided
> main.cpp:36:23: error: no member named 'x' in 'Point'
> ptr[i]->point.x = i;
> ~ ^
> main.cpp:37:23: error: no member named 'y' in 'Point'
> ptr[i]->point.y = i+1;
> ~ ^
> main.cpp:47:77: error: no member named 'x' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
>   ~
> ^
> main.cpp:47:94: error: no member named 'y' in 'Point'
> printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
>
> ~ ^
> 5 errors generated.
> make: *** [main.o] Error 1
>
> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
>
> vedant
>
> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
>
> Taking a look. It may be another instance of a test not actually running
> with -fmodules in the -gmodules configuration.
>
> vedant
>
> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>
> The bot started failing recently, and this commit seems the most likely
> culprit.
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>
>
> Can you please take a look, Vedant?
>
> Thanks,
>
> --
> Davide
>
> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>  wrote:
>
> Author: vedantk
> Date: Thu Jan 25 10:01:27 2018
> New Revision: 323450
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
> Log:
> Use test-specific module caches to avoid stale header conflicts
>
> Stale global module caches cause problems for the bots. The modules
> become invalid when clang headers are updated by version control, and
> tests which use these modules fail to compile, e.g:
>
> fatal error: file '.../__stddef_max_align_t.h' has been modified since the
> module file '/var/.../Darwin.pcm' was built
> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>
> Eventually we should transition to having just a single module cache to
> speed
> tests up. This patch should be just enough to fix the spurious bot failures
> due
> to stale caches.
>
> rdar://36479805, also related to llvm.org/PR36048
>
> Differential Revision: https://reviews.llvm.org/D42277
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/Makefile
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-auto-import/TestModulesAutoImport.py
>
> lldb/trunk/packages/Python/lldbsuite/test/lang/objc/modules-incomplete/Makefile
>

[Lldb-commits] [lldb] r323467 - [test] Fix a test that never compiled under -fmodules

[Vedant Kumar via lldb-commits]

Author: vedantk
Date: Thu Jan 25 13:20:29 2018
New Revision: 323467

URL: http://llvm.org/viewvc/llvm-project?rev=323467&view=rev
Log:
[test] Fix a test that never compiled under -fmodules

This test #include's stdio.h, which, on at least two bots results in a
module import of MacTypes.h (due to weird SDK layering issues), which
causes the test to fail to compile.

Just don't #include stdio.h, as it's not needed for the test.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/non-overlapping-index-variable-i/main.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/non-overlapping-index-variable-i/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/non-overlapping-index-variable-i/main.cpp?rev=323467&r1=323466&r2=323467&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/non-overlapping-index-variable-i/main.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/non-overlapping-index-variable-i/main.cpp
 Thu Jan 25 13:20:29 2018
@@ -6,7 +6,6 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-#include 
 
 class Point {
 public:
@@ -37,15 +36,11 @@ int main(int argc, char const *argv[]) {
 ptr[i]->point.y = i+1;
 }
 
-printf("Finished populating data.\n");
 for (int i = 0; i < 1000; ++i) {
 bool dump = argc > 1; // Set breakpoint here.
   // Evaluate a couple of expressions (2*1000 = 
2000 exprs):
   // expr ptr[i]->point.x
   // expr ptr[i]->point.y
-if (dump) {
-printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id, ptr[i]->point.x, 
ptr[i]->point.y);
-}
 }
 return 0;
 }


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

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

Done, r323467

> On Jan 25, 2018, at 1:20 PM, Davide Italiano  wrote:
> 
> yes, sure, I think that's the right thing to do.
> 
> --
> Davide
> 
> On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar  wrote:
>> We *could* x-fail this test on older OS's, but ISTM that we don't need this
>> test to printf at all, so let's just remove the #include?
>> 
>> vedant
>> 
>> On Jan 25, 2018, at 1:14 PM, Vedant Kumar  wrote:
>> 
>> The test passes locally, but the cmake job is failing in the exact same way
>> as the Xcode one. Based on the error, it looks like the compiler invocation
>> has failed.
>> 
>> .. and, aha!, here is the failed invocation:
>> 
>> green-dragon-23:non-overlapping-index-variable-i buildslave$ make
>> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64
>> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
>> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0
>> -std=c++11 -g -O0 -fno-builtin -arch x86_64
>> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
>> -include
>> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
>> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
>> -fno-limit-debug-info   -fmodules -gmodules
>> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
>> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
>>point(0, 0)
>>^ 
>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>> copy constructor) not viable: requires 1 argument, but 2 were provided
>> struct Point {
>>   ^
>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>> move constructor) not viable: requires 1 argument, but 2 were provided
>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>> default constructor) not viable: requires 0 arguments, but 2 were provided
>> main.cpp:36:23: error: no member named 'x' in 'Point'
>>ptr[i]->point.x = i;
>>~ ^
>> main.cpp:37:23: error: no member named 'y' in 'Point'
>>ptr[i]->point.y = i+1;
>>~ ^
>> main.cpp:47:77: error: no member named 'x' in 'Point'
>>printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
>> ptr[i]->point.x, ptr[i]->point.y);
>>  ~
>> ^
>> main.cpp:47:94: error: no member named 'y' in 'Point'
>>printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
>> ptr[i]->point.x, ptr[i]->point.y);
>> 
>> ~ ^
>> 5 errors generated.
>> make: *** [main.o] Error 1
>> 
>> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
>> 
>> vedant
>> 
>> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
>> 
>> Taking a look. It may be another instance of a test not actually running
>> with -fmodules in the -gmodules configuration.
>> 
>> vedant
>> 
>> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>> 
>> The bot started failing recently, and this commit seems the most likely
>> culprit.
>> 
>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>> 
>> 
>> Can you please take a look, Vedant?
>> 
>> Thanks,
>> 
>> --
>> Davide
>> 
>> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>>  wrote:
>> 
>> Author: vedantk
>> Date: Thu Jan 25 10:01:27 2018
>> New Revision: 323450
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
>> Log:
>> Use test-specific module caches to avoid stale header conflicts
>> 
>> Stale global module caches cause problems for the bots. The modules
>> become invalid when clang headers are updated by version control, and
>> tests which use these modules fail to compile, e.g:
>> 
>> fatal error: file '.../__stddef_max_align_t.h' has been modified since the
>> module file '/var/.../Darwin.pcm' was built
>> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>> 
>> Eventually we should transition to having just a single module cache to
>> speed
>> tests up. This patch should be just enough to fix the spurious bot failures
>> due
>> to stale caches.
>> 
>> rdar://36479805, also related to llvm.org/PR36048
>> 
>> Differential Revision: https://reviews.llvm.org/D42277
>> 
>> Modified:
>> 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>> 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>> 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>> 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>> 
>> lldb/trunk/packages/Python/lldbsuite/test

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Vedant Kumar via lldb-commits]

Green: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4760/console 


> On Jan 25, 2018, at 1:22 PM, Vedant Kumar  wrote:
> 
> Done, r323467
> 
>> On Jan 25, 2018, at 1:20 PM, Davide Italiano  wrote:
>> 
>> yes, sure, I think that's the right thing to do.
>> 
>> --
>> Davide
>> 
>> On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar  wrote:
>>> We *could* x-fail this test on older OS's, but ISTM that we don't need this
>>> test to printf at all, so let's just remove the #include?
>>> 
>>> vedant
>>> 
>>> On Jan 25, 2018, at 1:14 PM, Vedant Kumar  wrote:
>>> 
>>> The test passes locally, but the cmake job is failing in the exact same way
>>> as the Xcode one. Based on the error, it looks like the compiler invocation
>>> has failed.
>>> 
>>> .. and, aha!, here is the failed invocation:
>>> 
>>> green-dragon-23:non-overlapping-index-variable-i buildslave$ make
>>> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64
>>> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
>>> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0
>>> -std=c++11 -g -O0 -fno-builtin -arch x86_64
>>> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
>>> -include
>>> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
>>> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
>>> -fno-limit-debug-info   -fmodules -gmodules
>>> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
>>> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
>>>   point(0, 0)
>>>   ^ 
>>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>>> copy constructor) not viable: requires 1 argument, but 2 were provided
>>> struct Point {
>>>  ^
>>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>>> move constructor) not viable: requires 1 argument, but 2 were provided
>>> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
>>> default constructor) not viable: requires 0 arguments, but 2 were provided
>>> main.cpp:36:23: error: no member named 'x' in 'Point'
>>>   ptr[i]->point.x = i;
>>>   ~ ^
>>> main.cpp:37:23: error: no member named 'y' in 'Point'
>>>   ptr[i]->point.y = i+1;
>>>   ~ ^
>>> main.cpp:47:77: error: no member named 'x' in 'Point'
>>>   printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
>>> ptr[i]->point.x, ptr[i]->point.y);
>>> ~
>>> ^
>>> main.cpp:47:94: error: no member named 'y' in 'Point'
>>>   printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
>>> ptr[i]->point.x, ptr[i]->point.y);
>>> 
>>> ~ ^
>>> 5 errors generated.
>>> make: *** [main.o] Error 1
>>> 
>>> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
>>> 
>>> vedant
>>> 
>>> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
>>> 
>>> Taking a look. It may be another instance of a test not actually running
>>> with -fmodules in the -gmodules configuration.
>>> 
>>> vedant
>>> 
>>> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>>> 
>>> The bot started failing recently, and this commit seems the most likely
>>> culprit.
>>> 
>>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>>> 
>>> 
>>> Can you please take a look, Vedant?
>>> 
>>> Thanks,
>>> 
>>> --
>>> Davide
>>> 
>>> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>>>  wrote:
>>> 
>>> Author: vedantk
>>> Date: Thu Jan 25 10:01:27 2018
>>> New Revision: 323450
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
>>> Log:
>>> Use test-specific module caches to avoid stale header conflicts
>>> 
>>> Stale global module caches cause problems for the bots. The modules
>>> become invalid when clang headers are updated by version control, and
>>> tests which use these modules fail to compile, e.g:
>>> 
>>> fatal error: file '.../__stddef_max_align_t.h' has been modified since the
>>> module file '/var/.../Darwin.pcm' was built
>>> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>>> 
>>> Eventually we should transition to having just a single module cache to
>>> speed
>>> tests up. This patch should be just enough to fix the spurious bot failures
>>> due
>>> to stale caches.
>>> 
>>> rdar://36479805, also related to llvm.org/PR36048
>>> 
>>> Differential Revision: https://reviews.llvm.org/D42277
>>> 
>>> Modified:
>>> 
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>>> 
>>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>>> 
>>> lldb/tr

Re: [Lldb-commits] [lldb] r323450 - Use test-specific module caches to avoid stale header conflicts

[Davide Italiano via lldb-commits]

Cheer on!

On Thu, Jan 25, 2018 at 2:04 PM, Vedant Kumar  wrote:
> Green: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/4760/console
>
> On Jan 25, 2018, at 1:22 PM, Vedant Kumar  wrote:
>
> Done, r323467
>
> On Jan 25, 2018, at 1:20 PM, Davide Italiano  wrote:
>
> yes, sure, I think that's the right thing to do.
>
> --
> Davide
>
> On Thu, Jan 25, 2018 at 1:16 PM, Vedant Kumar  wrote:
>
> We *could* x-fail this test on older OS's, but ISTM that we don't need this
> test to printf at all, so let's just remove the #include?
>
> vedant
>
> On Jan 25, 2018, at 1:14 PM, Vedant Kumar  wrote:
>
> The test passes locally, but the cmake job is failing in the exact same way
> as the Xcode one. Based on the error, it looks like the compiler invocation
> has failed.
>
> .. and, aha!, here is the failed invocation:
>
> green-dragon-23:non-overlapping-index-variable-i buildslave$ make
> MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64
> CC="/Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0"
> /Users/buildslave/jenkins/workspace/lldb-cmake/host-compiler/bin/clang-7.0
> -std=c++11 -g -O0 -fno-builtin -arch x86_64
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/../../../../../include
> -include
> /Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/test_common.h
> -I/Users/buildslave/jenkins/workspace/lldb-cmake/src/llvm/tools/lldb/packages/Python/lldbsuite/test/make/
> -fno-limit-debug-info   -fmodules -gmodules
> -fmodules-cache-path=module-cache --driver-mode=g++ -c -o main.o main.cpp
> main.cpp:27:9: error: no matching constructor for initialization of 'Point'
>   point(0, 0)
>   ^ 
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> copy constructor) not viable: requires 1 argument, but 2 were provided
> struct Point {
>  ^
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> move constructor) not viable: requires 1 argument, but 2 were provided
> /usr/include/MacTypes.h:538:8: note: candidate constructor (the implicit
> default constructor) not viable: requires 0 arguments, but 2 were provided
> main.cpp:36:23: error: no member named 'x' in 'Point'
>   ptr[i]->point.x = i;
>   ~ ^
> main.cpp:37:23: error: no member named 'y' in 'Point'
>   ptr[i]->point.y = i+1;
>   ~ ^
> main.cpp:47:77: error: no member named 'x' in 'Point'
>   printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
> ~
> ^
> main.cpp:47:94: error: no member named 'y' in 'Point'
>   printf("data[%d] = %d (%d, %d)\n", i, ptr[i]->id,
> ptr[i]->point.x, ptr[i]->point.y);
>
> ~ ^
> 5 errors generated.
> make: *** [main.o] Error 1
>
> It looks like we're picking up "struct Point" from /usr/include/MacTypes.h!
>
> vedant
>
> On Jan 25, 2018, at 1:02 PM, Vedant Kumar  wrote:
>
> Taking a look. It may be another instance of a test not actually running
> with -fmodules in the -gmodules configuration.
>
> vedant
>
> On Jan 25, 2018, at 12:40 PM, Davide Italiano  wrote:
>
> The bot started failing recently, and this commit seems the most likely
> culprit.
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4513/
>
>
> Can you please take a look, Vedant?
>
> Thanks,
>
> --
> Davide
>
> On Thu, Jan 25, 2018 at 10:01 AM, Vedant Kumar via lldb-commits
>  wrote:
>
> Author: vedantk
> Date: Thu Jan 25 10:01:27 2018
> New Revision: 323450
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323450&view=rev
> Log:
> Use test-specific module caches to avoid stale header conflicts
>
> Stale global module caches cause problems for the bots. The modules
> become invalid when clang headers are updated by version control, and
> tests which use these modules fail to compile, e.g:
>
> fatal error: file '.../__stddef_max_align_t.h' has been modified since the
> module file '/var/.../Darwin.pcm' was built
> note: please rebuild precompiled header '/var/.../Darwin.pcm'
>
> Eventually we should transition to having just a single module cache to
> speed
> tests up. This patch should be just enough to fix the spurious bot failures
> due
> to stale caches.
>
> rdar://36479805, also related to llvm.org/PR36048
>
> Differential Revision: https://reviews.llvm.org/D42277
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-globals/TestDataFormatterGlobals.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.py
>
> ll

[Lldb-commits] [PATCH] D42281: WIP: compile the LLDB tests out-of-tree

[Jim Ingham via Phabricator via lldb-commits]

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

This looks good to me.  I think it would be cleaner if there were a 
getSourceFileSpec equivalent to getBuildArtifact.

I had a few inline trivial questions.

Also, before you forget all the things you had to do, you need to write down 
the new rules in the README.testsuite.  Might also be good to put a brief note 
in the sample_test testcases, since I imagine folks are just going to copy that 
and put it somewhere to make new tests, so reminding them there might not be a 
bad idea.




Comment at: 
packages/Python/lldbsuite/test/api/check_public_api_headers/TestPublicAPIHeaders.py:46
 self.line_to_break = line_number(
-self.source, '// Set breakpoint here.')
+self.getBuildArtifact(self.source), '// Set breakpoint here.')
 

Why do you have to call getBuildArtifact on the main source file?



Comment at: 
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_set_restart/TestBreakpointSetRestart.py:35-37
 self.BREAKPOINT_TEXT, lldb.SBFileSpec(
 os.path.join(
+self.getSourceDir(), 'main.cpp')))

This is beginning to show up a bunch.  Maybe TestBase should have:

  def getSourceFileSpec( filename):
fileSpec = lldb.SBFileSpec()
fileSpec.SetDirectory(self.getSourceDir())
fileSpec.SetFilename(filename)
return fileSpec



Comment at: 
packages/Python/lldbsuite/test/functionalities/exec/TestExec.py:47-48
 if self.getArchitecture() == 'x86_64':
-source = os.path.join(os.getcwd(), "main.cpp")
-o_file = os.path.join(os.getcwd(), "main.o")
+source = os.path.join(self.getSourceDir(), "main.cpp")
+o_file = self.getBuildArtifact("main.o")
 execute_command(

Maybe also a TestBase getSourcePath(filename) that returns a string?  That 
might be easier to read.



Comment at: packages/Python/lldbsuite/test/plugins/builder_base.py:224-232
+#  #import traceback
+#  # traceback.print_stack()
+#  commands = []
+#  if os.path.isfile("Makefile"):
+#  commands.append(getMake("") + ["clean", getCmdLine(dictionary)])
+#   
+#  runBuildCommands(commands, sender=sender)

Probably can delete this now...



Comment at: packages/Python/lldbsuite/test/types/AbstractBase.py:37-38
 self.exe_name = self.testMethodName
-self.golden_filename = os.path.join(os.getcwd(), "golden-output.txt")
+self.golden_filename = os.path.join(self.getBuildDir(),
+"golden-output.txt")
 

Why isn't this getBuildArtifact("golden-output.txt")?


https://reviews.llvm.org/D42281



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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

[Alexander Shaposhnikov via Phabricator via lldb-commits]

alexshap created this revision.
alexshap added reviewers: tberghammer, labath, clayborg.
Herald added subscribers: llvm-commits, JDevlieghere, aprantl.

A small test where the issue is easy to reproduce:

a.cpp:

  int f() {
return 1;
  }

b.cpp:

  extern int f();
  void g() {
 int y = 14;
 int x = f();
  }
  int main() {
 g();
 return 0;
  }

g++ -O0 -g -gsplit-dwarf -c a.cpp -o a.o // with fission
g++ -O0 -g -c b.cpp -o b.o  // without fission
g++ a.o b.o -o main.exe   // the order matters

run lldb
br set --name g  // WORKS FINE
run  // WORKS FINE
frame variable// DOESN'T WORK

So the problem is the following:
on Linux dwarf->GetID() returns 0 (unless dwarf is an instance of 
SymbolFileDWARFDwo),

> the higher 32 bits of  the returned by DIERef::GetUID(SymbolFileDWARF *dwarf) 
> uid do not encode cu_offset.


What happens next - in the constructor of DIERef the incorrect value of 
cu_offset is extracted from uid and propagates further.
For example, inside SymbolFileDWARF::ParseVariablesForContext there is a call 
DWARFDIE function_die = info->GetDIE(DIERef(sc.function->GetID(), this))

- and because of the "broken" cu_offset (inside DIERef) the method GetDIE 
returns an invalid DWARFDIE.

I don't like the proposed fix myself, maybe you have better ideas how to 
address the issue. 
Partially the complexity stems from the fact that DIERefs are used in many 
places => they need to contain the correct cu_offset.
Next, it's important to keep in mind that one file may contain several 
compilation units => fixing SymbolFileDWARF::GetID doesn't seem to be an 
option. Anyway - suggestions are very welcome, maybe I'm missing smth.

Test plan: make check-lldb


Repository:
  rL LLVM

https://reviews.llvm.org/D42563

Files:
  source/Plugins/SymbolFile/DWARF/DIERef.cpp


Index: source/Plugins/SymbolFile/DWARF/DIERef.cpp
===
--- source/Plugins/SymbolFile/DWARF/DIERef.cpp
+++ source/Plugins/SymbolFile/DWARF/DIERef.cpp
@@ -13,6 +13,7 @@
 #include "DWARFFormValue.h"
 #include "SymbolFileDWARF.h"
 #include "SymbolFileDWARFDebugMap.h"
+#include "lldb/Symbol/ObjectFile.h"
 
 DIERef::DIERef()
 : cu_offset(DW_INVALID_OFFSET), die_offset(DW_INVALID_OFFSET) {}
@@ -57,16 +58,21 @@
 }
 
 lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const {
-  //--
-  // Each SymbolFileDWARF will set its ID to what is expected.
-  //
-  // SymbolFileDWARF, when used for DWARF with .o files on MacOSX, has the
-  // ID set to the compile unit index.
-  //
-  // SymbolFileDWARFDwo sets the ID to the compile unit offset.
-  //--
-  if (dwarf && die_offset != DW_INVALID_OFFSET)
-return dwarf->GetID() | die_offset;
-  else
+  if (!dwarf || die_offset == DW_INVALID_OFFSET)
 return LLDB_INVALID_UID;
+
+  // For ELF targets the higher 32 bits of the returned id encode cu_offset
+  // which is used, for example, by DIERef.
+  lldb_private::ArchSpec arch;
+  if (dwarf->GetObjectFile()->GetArchitecture(arch) &&
+  arch.GetTriple().isOSBinFormatELF()) {
+// For SymbolFileDWARFDwo/SymbolFileDWARFDwoDwp
+// the offset of the base compilation unit should be used.
+uint64_t offset =
+  dwarf->GetBaseCompileUnit() ? dwarf->GetBaseCompileUnit()->GetOffset() :
+  cu_offset;
+return (offset << 32) | die_offset;
+  }
+
+  return dwarf->GetID() | die_offset;
 }


Index: source/Plugins/SymbolFile/DWARF/DIERef.cpp
===
--- source/Plugins/SymbolFile/DWARF/DIERef.cpp
+++ source/Plugins/SymbolFile/DWARF/DIERef.cpp
@@ -13,6 +13,7 @@
 #include "DWARFFormValue.h"
 #include "SymbolFileDWARF.h"
 #include "SymbolFileDWARFDebugMap.h"
+#include "lldb/Symbol/ObjectFile.h"
 
 DIERef::DIERef()
 : cu_offset(DW_INVALID_OFFSET), die_offset(DW_INVALID_OFFSET) {}
@@ -57,16 +58,21 @@
 }
 
 lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const {
-  //--
-  // Each SymbolFileDWARF will set its ID to what is expected.
-  //
-  // SymbolFileDWARF, when used for DWARF with .o files on MacOSX, has the
-  // ID set to the compile unit index.
-  //
-  // SymbolFileDWARFDwo sets the ID to the compile unit offset.
-  //--
-  if (dwarf && die_offset != DW_INVALID_OFFSET)
-return dwarf->GetID() | die_offset;
-  else
+  if (!dwarf || die_offset == DW_INVALID_OFFSET)
 return LLDB_INVALID_UID;
+
+  // For ELF targets the higher 32 bits of the returned id encode cu_offset
+  // which is used, for example, by DIERef.
+  lldb_private::ArchSpec arch;
+  if 

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

[Davide Italiano via Phabricator via lldb-commits]

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

Testcase?


Repository:
  rL LLVM

https://reviews.llvm.org/D42563



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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

[Alexander Shaposhnikov via Phabricator via lldb-commits]

alexshap added a comment.

@davide - the test case is in the description but i can try to add it to the 
test suite.


Repository:
  rL LLVM

https://reviews.llvm.org/D42563



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

[Lldb-commits] [PATCH] D42563: [lldb] attempt to fix DIERef::GetUID

[Davide Italiano via Phabricator via lldb-commits]

davide added a comment.

In https://reviews.llvm.org/D42563#988700, @alexshap wrote:

> @davide - the test case is in the description but i can try to add it to the 
> test suite.


yes, please.


Repository:
  rL LLVM

https://reviews.llvm.org/D42563



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