Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Jim Ingham via lldb-commits
jingham added a subscriber: jingham.
jingham added a comment.

Done in r266407.  It built for me after this.

Jim


http://reviews.llvm.org/D18848



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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Jim Ingham via lldb-commits
Done in r266407.  It built for me after this.

Jim

> On Apr 14, 2016, at 6:34 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> zturner added a comment.
> 
> A new file was added, Greg or someone else at Apple may need to add it to
> the Xcode workspace
> 
> 
> http://reviews.llvm.org/D18848
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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


[Lldb-commits] [lldb] r266407 - Add the PDBParser.{cpp, h} files to the Xcode project.

2016-04-14 Thread Jim Ingham via lldb-commits
Author: jingham
Date: Thu Apr 14 20:42:30 2016
New Revision: 266407

URL: http://llvm.org/viewvc/llvm-project?rev=266407=rev
Log:
Add the PDBParser.{cpp,h} files to the Xcode project.

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

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=266407=266406=266407=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Apr 14 20:42:30 2016
@@ -697,6 +697,7 @@
4C0083401B9F9BA900D5CF24 /* UtilityFunction.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 4C00833F1B9F9BA900D5CF24 /* UtilityFunction.cpp 
*/; };
4C2479BD1BA39295009C9A7B /* FunctionCaller.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 4C0083321B9A5DE200D5CF24 /* FunctionCaller.cpp 
*/; };
4C3ADCD61810D88B00357218 /* BreakpointResolverFileRegex.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 4CAA56141422D986001FFA01 /* 
BreakpointResolverFileRegex.cpp */; };
+   4C562CC71CC07DF700C52EAC /* PDBASTParser.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 4C562CC21CC07DDD00C52EAC /* PDBASTParser.cpp */; 
};
4C56543119D1EFAA002E9C44 /* ThreadPlanPython.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 4C56543019D1EFAA002E9C44 /* 
ThreadPlanPython.cpp */; };
4C56543519D2297A002E9C44 /* SBThreadPlan.h in Headers */ = {isa 
= PBXBuildFile; fileRef = 4C56543419D2297A002E9C44 /* SBThreadPlan.h */; 
settings = {ATTRIBUTES = (Public, ); }; };
4C56543719D22B32002E9C44 /* SBThreadPlan.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 4C56543619D22B32002E9C44 /* SBThreadPlan.cpp */; 
};
@@ -2376,6 +2377,8 @@
4C43DF8611069BFD00E55CBF /* ThreadPlanStepOverRange.h */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name 
= ThreadPlanStepOverRange.h; path = 
include/lldb/Target/ThreadPlanStepOverRange.h; sourceTree = ""; };
4C43DF8911069C3200E55CBF /* ThreadPlanStepInRange.cpp */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = ThreadPlanStepInRange.cpp; path = 
source/Target/ThreadPlanStepInRange.cpp; sourceTree = ""; };
4C43DF8A11069C3200E55CBF /* ThreadPlanStepOverRange.cpp */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; name = ThreadPlanStepOverRange.cpp; path = 
source/Target/ThreadPlanStepOverRange.cpp; sourceTree = ""; };
+   4C562CC21CC07DDD00C52EAC /* PDBASTParser.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = PDBASTParser.cpp; path = PDB/PDBASTParser.cpp; sourceTree = ""; };
+   4C562CC31CC07DDD00C52EAC /* PDBASTParser.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
PDBASTParser.h; path = PDB/PDBASTParser.h; sourceTree = ""; };
4C56543019D1EFAA002E9C44 /* ThreadPlanPython.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = ThreadPlanPython.cpp; path = source/Target/ThreadPlanPython.cpp; 
sourceTree = ""; };
4C56543219D1EFB5002E9C44 /* ThreadPlanPython.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
ThreadPlanPython.h; path = include/lldb/Target/ThreadPlanPython.h; sourceTree = 
""; };
4C56543419D2297A002E9C44 /* SBThreadPlan.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
SBThreadPlan.h; path = include/lldb/API/SBThreadPlan.h; sourceTree = ""; 
};
@@ -5856,6 +5859,8 @@
AF6335DF1C87B20A00F7D554 /* PDB */ = {
isa = PBXGroup;
children = (
+   4C562CC21CC07DDD00C52EAC /* PDBASTParser.cpp */,
+   4C562CC31CC07DDD00C52EAC /* PDBASTParser.h */,
AF6335E01C87B21E00F7D554 /* SymbolFilePDB.cpp 
*/,
AF6335E11C87B21E00F7D554 /* SymbolFilePDB.h */,
);
@@ -6991,6 +6996,7 @@
26D1803E16CEBFD300EDFB5B /* KQueue.cpp in 
Sources */,
26A69C5F137A17A500262477 /* RegisterValue.cpp 
in Sources */,
2690B3711381D5C300ECFBAE /* Memory.cpp in 
Sources */,
+   4C562CC71CC07DF700C52EAC /* PDBASTParser.cpp in 
Sources */,
B28058A1139988B0002D96D0 /* 
InferiorCallPOSIX.cpp in Sources */,
AF20F76A1AF18F9000751A6E /* ABISysV_arm64.cpp 
in Sources */,
26F73062139D8FDB00FD51C7 /* History.cpp in 
Sources 

Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Zachary Turner via lldb-commits
zturner added a comment.

A new file was added, Greg or someone else at Apple may need to add it to
the Xcode workspace


http://reviews.llvm.org/D18848



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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Zachary Turner via lldb-commits
A new file was added, Greg or someone else at Apple may need to add it to
the Xcode workspace
On Thu, Apr 14, 2016 at 6:26 PM Vedant Kumar  wrote:

> vsk added a subscriber: vsk.
> vsk added a comment.
>
> Hi @zturner, this seems to have upset an lldb bot. Could you take a look (
> https://llvm.org/bugs/show_bug.cgi?id=27362)?
>
>
> http://reviews.llvm.org/D18848
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r266401 - Rename out->std_out in AppleObjCRuntimeV2.cpp.

2016-04-14 Thread Oleksiy Vyalov via lldb-commits
Author: ovyalov
Date: Thu Apr 14 19:56:11 2016
New Revision: 266401

URL: http://llvm.org/viewvc/llvm-project?rev=266401=rev
Log:
Rename out->std_out in AppleObjCRuntimeV2.cpp.


Modified:

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

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp?rev=266401=266400=266401=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
 Thu Apr 14 19:56:11 2016
@@ -596,7 +596,7 @@ protected:
 {
 auto iterators_pair = objc_runtime->GetDescriptorIteratorPair();
 auto iterator = iterators_pair.first;
-auto  = result.GetOutputStream();
+auto _out = result.GetOutputStream();
 for(; iterator != iterators_pair.second; iterator++)
 {
 if (iterator->second)
@@ -604,15 +604,15 @@ protected:
 const char* class_name = 
iterator->second->GetClassName().AsCString("");
 if (regex_up && class_name && 
!regex_up->Execute(class_name))
 continue;
-out.Printf("isa = 0x%" PRIx64, iterator->first);
-out.Printf(" name = %s", class_name);
-out.Printf(" instance size = %" PRIu64, 
iterator->second->GetInstanceSize());
-out.Printf(" num ivars = %" PRIuPTR, 
(uintptr_t)iterator->second->GetNumIVars());
+std_out.Printf("isa = 0x%" PRIx64, iterator->first);
+std_out.Printf(" name = %s", class_name);
+std_out.Printf(" instance size = %" PRIu64, 
iterator->second->GetInstanceSize());
+std_out.Printf(" num ivars = %" PRIuPTR, 
(uintptr_t)iterator->second->GetNumIVars());
 if (auto superclass = iterator->second->GetSuperclass())
 {
-out.Printf(" superclass = %s", 
superclass->GetClassName().AsCString(""));
+std_out.Printf(" superclass = %s", 
superclass->GetClassName().AsCString(""));
 }
-out.Printf("\n");
+std_out.Printf("\n");
 if (m_options.m_verbose)
 {
 for(size_t i = 0;
@@ -620,23 +620,23 @@ protected:
 i++)
 {
 auto ivar = iterator->second->GetIVarAtIndex(i);
-out.Printf("  ivar name = %s type = %s size = %" 
PRIu64 " offset = %" PRId32 "\n",
+std_out.Printf("  ivar name = %s type = %s size = 
%" PRIu64 " offset = %" PRId32 "\n",
 
ivar.m_name.AsCString(""),
 
ivar.m_type.GetDisplayTypeName().AsCString(""),
 ivar.m_size,
 ivar.m_offset);
 }
 iterator->second->Describe(nullptr,
-   [objc_runtime, ] (const 
char* name, const char* type) -> bool {
-   out.Printf("  instance 
method name = %s type = %s\n",
-  name,
-  type);
+   [objc_runtime, _out] 
(const char* name, const char* type) -> bool {
+   std_out.Printf("  
instance method name = %s type = %s\n",
+  name,
+  type);
return false;
},
-   [objc_runtime, ] (const 
char* name, const char* type) -> bool {
-   out.Printf("  class 
method name = %s type = %s\n",
-  name,
-  type);
+   [objc_runtime, _out] 
(const char* name, const char* type) -> bool {
+   std_out.Printf("  class 
method name = 

[Lldb-commits] [lldb] r266400 - Blocks are only reliably supported on Darwin. Disable the test otherwise.

2016-04-14 Thread Sean Callanan via lldb-commits
Author: spyffe
Date: Thu Apr 14 19:44:59 2016
New Revision: 266400

URL: http://llvm.org/viewvc/llvm-project?rev=266400=rev
Log:
Blocks are only reliably supported on Darwin.  Disable the test otherwise.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py?rev=266400=266399=266400=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py Thu 
Apr 14 19:44:59 2016
@@ -8,6 +8,7 @@ import unittest2
 import os, time
 import lldb
 from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
 
 class BlocksTestCase(TestBase):
@@ -36,6 +37,7 @@ class BlocksTestCase(TestBase):
 self.wait_for_breakpoint()
 
 @unittest2.expectedFailure("rdar://problem/10413887 - Call blocks in 
expressions")
+@skipUnlessDarwin
 def test_expr(self):
 self.launch_common()
 
@@ -51,6 +53,7 @@ class BlocksTestCase(TestBase):
 self.expect("expression (int)neg (-12)", VARIABLES_DISPLAYED_CORRECTLY,
 substrs = ["= 12"])
 
+@skipUnlessDarwin
 def test_define(self):
 self.launch_common()
 


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


[Lldb-commits] [lldb] r266397 - Added a testcase for defining and using lambdas in the expression parser.

2016-04-14 Thread Sean Callanan via lldb-commits
Author: spyffe
Date: Thu Apr 14 19:26:32 2016
New Revision: 266397

URL: http://llvm.org/viewvc/llvm-project?rev=266397=rev
Log:
Added a testcase for defining and using lambdas in the expression parser.



Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/TestLambdas.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp

Added: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/TestLambdas.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/TestLambdas.py?rev=266397=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/TestLambdas.py 
(added)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/TestLambdas.py 
Thu Apr 14 19:26:32 2016
@@ -0,0 +1,4 @@
+from lldbsuite.test import lldbinline
+from lldbsuite.test import decorators
+
+lldbinline.MakeInlineTest(__file__, globals(), [])

Added: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp?rev=266397=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp (added)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/lambdas/main.cpp Thu Apr 
14 19:26:32 2016
@@ -0,0 +1,17 @@
+//===-- main.cpp *- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+
+int main (int argc, char const *argv[])
+{
+printf("Stop here\n"); //% self.runCmd("expression auto $add = [](int 
a, int b) { return a + b };")
+   //% self.expect("expression $add(2,3)", substrs 
= ['= 5'])
+return 0; 
+}


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


[Lldb-commits] [lldb] r266392 - Initial support for reading type information from PDBs.

2016-04-14 Thread Zachary Turner via lldb-commits
Author: zturner
Date: Thu Apr 14 19:21:26 2016
New Revision: 266392

URL: http://llvm.org/viewvc/llvm-project?rev=266392=rev
Log:
Initial support for reading type information from PDBs.

This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name.  This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework.  With this patch, you should
be able to lookup basic types by name from a PDB.

Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.

Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton

Added:
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.h
lldb/trunk/unittests/SymbolFile/PDB/Inputs/test-pdb-types.cpp
lldb/trunk/unittests/SymbolFile/PDB/Inputs/test-pdb-types.pdb
Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/source/Plugins/SymbolFile/PDB/CMakeLists.txt
lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/SymbolFile/PDB/CMakeLists.txt
lldb/trunk/unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp

Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=266392=266391=266392=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Thu Apr 14 19:21:26 2016
@@ -37,6 +37,7 @@
 #include "lldb/lldb-enumerations.h"
 
 class DWARFASTParserClang;
+class PDBASTParser;
 
 namespace lldb_private {
 
@@ -524,6 +525,8 @@ public:
 //--
 DWARFASTParser *
 GetDWARFParser() override;
+PDBASTParser *
+GetPDBParser();
 
 //--
 // ClangASTContext callbacks for external source lookups.
@@ -696,7 +699,13 @@ public:
 
 bool
 IsPolymorphicClass (lldb::opaque_compiler_type_t type) override;
-
+
+static bool
+IsClassType(lldb::opaque_compiler_type_t type);
+
+static bool
+IsEnumType(lldb::opaque_compiler_type_t type);
+
 bool
 IsPossibleDynamicType(lldb::opaque_compiler_type_t type,
   CompilerType *target_type, // Can pass nullptr
@@ -1189,6 +1198,7 @@ protected:
 std::unique_ptr   m_selector_table_ap;
 std::unique_ptrm_builtins_ap;
 std::unique_ptrm_dwarf_ast_parser_ap;
+std::unique_ptr   m_pdb_ast_parser_ap;
 std::unique_ptr m_scratch_ast_source_ap;
 std::unique_ptr   m_mangle_ctx_ap;
 CompleteTagDeclCallback m_callback_tag_decl;

Modified: lldb/trunk/source/Plugins/SymbolFile/PDB/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/PDB/CMakeLists.txt?rev=266392=266391=266392=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/PDB/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/CMakeLists.txt Thu Apr 14 19:21:26 
2016
@@ -2,5 +2,6 @@ set(LLVM_PRIVATE_LINK_COMPONENTS
 DebugInfoPDB)
 
 add_lldb_library(lldbPluginSymbolFilePDB
+  PDBASTParser.cpp
   SymbolFilePDB.cpp
   )

Added: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp?rev=266392=auto
==
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp (added)
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp Thu Apr 14 
19:21:26 2016
@@ -0,0 +1,236 @@
+//===-- PDBASTParser.cpp *- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "PDBASTParser.h"
+
+#include "clang/AST/CharUnits.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+
+#include "lldb/Symbol/ClangASTContext.h"
+#include "lldb/Symbol/ClangUtil.h"
+#include "lldb/Symbol/Declaration.h"
+#include "lldb/Symbol/SymbolFile.h"
+#include "lldb/Symbol/TypeSystem.h"
+
+#include "llvm/DebugInfo/PDB/PDBSymbol.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolTypeArray.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolTypeBuiltin.h"
+#include 

[Lldb-commits] [lldb] r266389 - Added a testcase for defining and using a block in the expression parser.

2016-04-14 Thread Sean Callanan via lldb-commits
Author: spyffe
Date: Thu Apr 14 19:05:50 2016
New Revision: 266389

URL: http://llvm.org/viewvc/llvm-project?rev=266389=rev
Log:
Added a testcase for defining and using a block in the expression parser.



Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py?rev=266389=266388=266389=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/blocks/TestBlocks.py Thu 
Apr 14 19:05:50 2016
@@ -21,9 +21,8 @@ class BlocksTestCase(TestBase):
 # Find the line numbers to break at.
 self.lines.append(line_number('main.c', '// Set breakpoint 0 here.'))
 self.lines.append(line_number('main.c', '// Set breakpoint 1 here.'))
-
-@unittest2.expectedFailure("rdar://problem/10413887 - Call blocks in 
expressions")
-def test_expr(self):
+
+def launch_common(self):
 self.build()
 exe = os.path.join(os.getcwd(), "a.out")
 self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
@@ -35,6 +34,10 @@ class BlocksTestCase(TestBase):
 lldbutil.run_break_set_by_file_and_line (self, "main.c", line, 
num_expected_locations=1, loc_exact=True)
 
 self.wait_for_breakpoint()
+
+@unittest2.expectedFailure("rdar://problem/10413887 - Call blocks in 
expressions")
+def test_expr(self):
+self.launch_common()
 
 self.expect("expression a + b", VARIABLES_DISPLAYED_CORRECTLY,
 substrs = ["= 7"])
@@ -47,6 +50,13 @@ class BlocksTestCase(TestBase):
 # This should display correctly.
 self.expect("expression (int)neg (-12)", VARIABLES_DISPLAYED_CORRECTLY,
 substrs = ["= 12"])
+
+def test_define(self):
+self.launch_common()
+
+self.runCmd("expression int (^$add)(int, int) = ^int(int a, int b) { 
return a + b; };")
+
+self.expect("expression $add(2,3)", VARIABLES_DISPLAYED_CORRECTLY, 
substrs = [" = 5"])
 
 def wait_for_breakpoint(self):
 if self.is_started == False:


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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

Ooh, that might work. But when ControlProvateStateThread resets 
m_private_state_control_wait to false there's still a race between that and the 
thread exiting. It could then be set back to false even after the thread has 
exited (this is even likely for a detach).

I tried a different approach, changing `PrivateStateThreadIsValid` to the 
following. I'm not sure it's the right thing to do, but it certainly fixes the 
race (and thus timeout) on our platform:

  bool
  PrivateStateThreadIsValid () const
  {
  lldb::StateType state = m_private_state.GetValue();
  return state != lldb::eStateDetached &&
 state != lldb::eStateExited &&
 m_private_state_thread.IsJoinable();
  }


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


[Lldb-commits] [lldb] r266384 - Don't disable stdin buffering on Windows

2016-04-14 Thread Adrian McCarthy via lldb-commits
Author: amccarth
Date: Thu Apr 14 18:31:17 2016
New Revision: 266384

URL: http://llvm.org/viewvc/llvm-project?rev=266384=rev
Log:
Don't disable stdin buffering on Windows

Disabling buffering exposes a bug in the MS VS 2015 CRT implementation of 
fgets, where you sometimes have to hit Enter twice, depending on if the input 
had an odd or even number of characters.

This was hidden until a few days ago by the Python initialization which was 
re-enabling buffering on the streams. A few days ago, Enrico make the Python 
initialization on-demand, which exposed this problem.

Modified:
lldb/trunk/tools/driver/Driver.cpp

Modified: lldb/trunk/tools/driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Driver.cpp?rev=266384=266383=266384=diff
==
--- lldb/trunk/tools/driver/Driver.cpp (original)
+++ lldb/trunk/tools/driver/Driver.cpp Thu Apr 14 18:31:17 2016
@@ -1037,7 +1037,12 @@ Driver::MainLoop ()
 atexit (reset_stdin_termios);
 }
 
+#ifndef _MSC_VER
+// Disabling stdin buffering with MSVC's 2015 CRT exposes a bug in fgets
+// which causes it to miss newlines depending on whether there have been an
+// odd or even number of characters.  Bug has been reported to MS via 
Connect.
 ::setbuf (stdin, NULL);
+#endif
 ::setbuf (stdout, NULL);
 
 m_debugger.SetErrorFileHandle (stderr, false);
@@ -1309,12 +1314,6 @@ wmain(int argc, wchar_t const *wargv[])
 main(int argc, char const *argv[])
 #endif
 {
-#ifdef _MSC_VER
-   // disable buffering on windows
-   setvbuf(stdout, NULL, _IONBF, 0);
-   setvbuf(stdin , NULL, _IONBF, 0);
-#endif
-
 #ifdef _WIN32
 // Convert wide arguments to UTF-8
 std::vector argvStrings(argc);


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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

> I think the real bug is in StopPrivateStateThread, which only sends the stop 
> state if the thread is still joinable; since I removed the Reset, it is of 
> course still joinable after it exits. But even with the Reset (which we agree 
> shouldn't be there), there is still a race between the time the detach signal 
> is sent and when the thread sees it and exits. It seems once a detach or stop 
> is sent, no further detaches/stops can be sent, regardless of what the thread 
> is doing (since it will exit as soon as it sees the first one). So there 
> should be a flag to that effect somewhere checked in 
> ControlPrivateStateThread. Probably all the calls to `IsJoinable()` should be 
> replaced with calls to `PrivateStateThreadIsValid`, which should be updated 
> to check that flag.

> 

> I don't see a nice way to add this flag for each private state thread, 
> though, instead of for the process object as a whole. But maybe that's all 
> that's necessary?


You can just check the value of m_private_state_control_wait:

  void
  Process::ControlPrivateStateThread (uint32_t signal)
  {
  // Signal the private state thread. First we should copy this is case the
  // thread starts exiting since the private state thread will NULL this out
  // when it exits
  HostThread private_state_thread(m_private_state_thread);
  if (private_state_thread.IsJoinable() && 
m_private_state_control_wait.GetValue() == false)
  {

m_private_state_control_wait is always false if the private state thread is 
running. It is set to true immediately after sending a control and syncing with 
the sender and then it is set back to false. It is set to true again when the 
thread exits.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19136: Don't disable stdin and stdout buffering on Windows

2016-04-14 Thread Adrian McCarthy via lldb-commits
amccarth added a comment.

In http://reviews.llvm.org/D19136#401888, @zturner wrote:

> I think you can probably leave buffering turned off for stdout and only do 
> this change for stdin unless we find some other bug.  AFAIK the problem is 
> confined to stdin.  I'd probably leave a comment in `Driver::MainLoop()` 
> about why you're not disabling buffering on Windows though.


Done.  Re-running tests on Windows and will submit when they're done.


http://reviews.llvm.org/D19136



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


Re: [Lldb-commits] [PATCH] D19136: Don't disable stdin and stdout buffering on Windows

2016-04-14 Thread Zachary Turner via lldb-commits
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.

I think you can probably leave buffering turned off for stdout and only do this 
change for stdin unless we find some other bug.  AFAIK the problem is confined 
to stdin.  I'd probably leave a comment in `Driver::MainLoop()` about why 
you're not disabling buffering on Windows though.


http://reviews.llvm.org/D19136



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

OK, I'll pare down the patch to just that line then.

I found the reason for the time out. At the end of our debug session, we 
destroy the Target, which destroys the process. Process::Destroy in turn calls 
Process::Detach, which calls DoDetach just before calling 
StopPrivateStateThread (which times out). Our platform's process object 
(modeled after the GDB remote one) sets the thread state to eStateDetached in 
its DoDetach implementation; and the private state thread exits as soon as it 
sees that state, meaning it's no longer around handle the 
eBroadcastInternalStateControlStop state event from the StopPrivateStateThread 
just after.

I think the real bug is in StopPrivateStateThread, which only sends the stop 
state if the thread is still joinable; since I removed the Reset, it is of 
course still joinable after it exits. But even with the Reset (which we agree 
shouldn't be there), there is still a race between the time the detach signal 
is sent and when the thread sees it and exits. It seems once a detach or stop 
is sent, no further detaches/stops can be sent, regardless of what the thread 
is doing (since it will exit as soon as it sees the first one). So there should 
be a flag to that effect somewhere checked in ControlPrivateStateThread. 
Probably all the calls to `IsJoinable()` should be replaced with calls to 
`PrivateStateThreadIsValid`, which should be updated to check that flag.

I don't see a nice way to add this flag for each private state thread, though, 
instead of for the process object as a whole. But maybe that's all that's 
necessary?


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


[Lldb-commits] [PATCH] D19136: Don't disable stdin and stdout buffering on Windows

2016-04-14 Thread Adrian McCarthy via lldb-commits
amccarth created this revision.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.

Disabling buffering exposes a bug in the MS VS 2015 CRT implementation of 
fgets, where you sometimes have to hit Enter twice, depending on if the input 
had an odd or even number of characters.

This was hidden until a few days ago by the Python initialization which was 
re-enabling buffering on the streams.  A few days ago, Enrico make the Python 
initialization on-demand, which exposed this problem.

http://reviews.llvm.org/D19136

Files:
  tools/driver/Driver.cpp

Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -1037,8 +1037,10 @@
 atexit (reset_stdin_termios);
 }
 
+#ifndef _MSC_VER
 ::setbuf (stdin, NULL);
 ::setbuf (stdout, NULL);
+#endif
 
 m_debugger.SetErrorFileHandle (stderr, false);
 m_debugger.SetOutputFileHandle (stdout, false);
@@ -1309,12 +1311,6 @@
 main(int argc, char const *argv[])
 #endif
 {
-#ifdef _MSC_VER
-   // disable buffering on windows
-   setvbuf(stdout, NULL, _IONBF, 0);
-   setvbuf(stdin , NULL, _IONBF, 0);
-#endif
-
 #ifdef _WIN32
 // Convert wide arguments to UTF-8
 std::vector argvStrings(argc);


Index: tools/driver/Driver.cpp
===
--- tools/driver/Driver.cpp
+++ tools/driver/Driver.cpp
@@ -1037,8 +1037,10 @@
 atexit (reset_stdin_termios);
 }
 
+#ifndef _MSC_VER
 ::setbuf (stdin, NULL);
 ::setbuf (stdout, NULL);
+#endif
 
 m_debugger.SetErrorFileHandle (stderr, false);
 m_debugger.SetOutputFileHandle (stdout, false);
@@ -1309,12 +1311,6 @@
 main(int argc, char const *argv[])
 #endif
 {
-#ifdef _MSC_VER
-	// disable buffering on windows
-	setvbuf(stdout, NULL, _IONBF, 0);
-	setvbuf(stdin , NULL, _IONBF, 0);
-#endif
-
 #ifdef _WIN32
 // Convert wide arguments to UTF-8
 std::vector argvStrings(argc);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Jim Ingham via lldb-commits
jingham added a subscriber: jingham.
jingham added a comment.

At the Command & SB API level, we restrict access to the process from multiple 
threads with the run lock.  But internally it is currently more of a 
gentleman's agreement not to do this.

I don't think it would ever be useful to try to make calling functions in the 
target (which is the job of RunThreadPlan) work concurrently.  Rather we should 
have some higher level permission baton that you have to have to do anything 
that would run the target, and then let only one thread at a time do this work. 
 That would make it impossible for RunThreadPlan to get run on multiple threads 
for the same process.  So while it wouldn't hurt to protect the 
m_private_state_thread variable with locks, that's not really the right level 
to do this, and if you ever let two threads try to run function calls in the 
target simultaneously, racy-ness in the m_private_state_thread would be the 
least of your problems...

Jim


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Jim Ingham via lldb-commits
At the Command & SB API level, we restrict access to the process from multiple 
threads with the run lock.  But internally it is currently more of a 
gentleman's agreement not to do this.  

I don't think it would ever be useful to try to make calling functions in the 
target (which is the job of RunThreadPlan) work concurrently.  Rather we should 
have some higher level permission baton that you have to have to do anything 
that would run the target, and then let only one thread at a time do this work. 
 That would make it impossible for RunThreadPlan to get run on multiple threads 
for the same process.  So while it wouldn't hurt to protect the 
m_private_state_thread variable with locks, that's not really the right level 
to do this, and if you ever let two threads try to run function calls in the 
target simultaneously, racy-ness in the m_private_state_thread would be the 
least of your problems...

Jim


> On Apr 14, 2016, at 3:44 PM, Cameron  wrote:
> 
> cameron314 added a comment.
> 
> I read the same docs :D This is the important part:
> 
>> If multiple threads of execution access the same shared_ptr without 
>> synchronization and any of those accesses uses a non-const member function 
>> of shared_ptr then a data race will occur; the shared_ptr overloads of 
>> atomic functions can be used to prevent the data race.
> 
> 
> Copying the shared pointer and accessing its pointee through it is thread 
> safe (copying a wrapper object technically isn't, but it will boil down to 
> the same thing, so let's leave that aside). But copying it while the pointer 
> is being reassigned (`operator=`) on a different thread is //not// thread 
> safe.
> 
> To answer your question, yes, absolutely, we can just remove that one call to 
> Reset. But if the copy is still necessary, that means a lot of existing code 
> (including that copy) is also racy and should be reviewed (though this would 
> make sense to do in a separate patch).
> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D19122
> 
> 
> 

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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

agreed


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

I read the same docs :D This is the important part:

> If multiple threads of execution access the same shared_ptr without 
> synchronization and any of those accesses uses a non-const member function of 
> shared_ptr then a data race will occur; the shared_ptr overloads of atomic 
> functions can be used to prevent the data race.


Copying the shared pointer and accessing its pointee through it is thread safe 
(copying a wrapper object technically isn't, but it will boil down to the same 
thing, so let's leave that aside). But copying it while the pointer is being 
reassigned (`operator=`) on a different thread is //not// thread safe.

To answer your question, yes, absolutely, we can just remove that one call to 
Reset. But if the copy is still necessary, that means a lot of existing code 
(including that copy) is also racy and should be reviewed (though this would 
make sense to do in a separate patch).


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

We should figure out what is going wrong on your system though and figure out 
why we need to call Cancel() as well.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

from the C++ docs:

> All member functions (including copy constructor and copy assignment) can be 
> called by multiple threads on different instances of shared_ptr without 
> additional synchronization even if these instances are copies and share 
> ownership of the same object. If multiple threads of execution access the 
> same shared_ptr without synchronization and any of those accesses uses a 
> non-const member function of shared_ptr then a data race will occur; the 
> shared_ptr overloads of atomic functions can be used to prevent the data race.


So we might not need to do anything.

So back to my original comment: can we just remove all changes except the 
"m_private_state_thread.Reset();" in Process::RunPrivateStateThread()?


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

Hmm, interesting. Yes, it should not be timing out in the first place. That's 
likely a bug on our side, still to be determined. I'm looking into it. 
Regardless, it led us to find and fix this race :-)

I think it still makes sense for LLDB to do a `Cancel()` as a last-ditch effort 
on timing out. But `Cancel()` is fundamentally very dangerous, so then again, 
maybe not.

Can the code that spins up the extra thread (RunThreadPlan) run on a different 
thread than ControlPrivateStateThread runs on? I was under the (perhaps 
entirely false!) impression that the Process object was used by only one thread 
at a time (with the exception of the private state thread(s), of course, but 
that thread shouldn't touch its own control variables).

If that's not the case, then looking at the RunThreadPlan code, there's lots 
more races on m_private_state_thread alone (e.g. calling EqualsThread on it 
while it could be assigned from another thread). And even just creating a copy 
is not thread safe, for example, since it could be reassigned from another 
thread at the same time... you'd need `m_private_state_thread` to be wrap its 
shared pointer with `std::atomic`.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19114: [test] Relax stderr expectations on targets with chatty output

2016-04-14 Thread Stephen Hines via lldb-commits
srhines added inline comments.


Comment at: packages/Python/lldbsuite/test/lldbplatformutil.py:142
@@ +141,3 @@
+def hasChattyStderr(test_case):
+"""Some targets produce garbage on the standard error output. This utility 
function
+determines whether the tests can be strict about the expected stderr 
contents."""

I know it isn't ideal, but the stderr output isn't actually "garbage". It is 
just not a warning that lldb cares about, but it is perfectly valid to notify 
developers of an incorrect linking behavior.


http://reviews.llvm.org/D19114



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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

Sounds good. Lets start with this and add on as needed.


http://reviews.llvm.org/D18848



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

HostThread::Reset() is a bad function and should not be directly used by anyone 
other that Join() or Detach(). Just clearing the thread ID and setting the 
result to zero is bad and means we will leak a thread if no one else joins it. 
If someone else already called Detach() on the thread, then Reset() is ok. Also 
calling m_private_state_thread.Cancel() is equally bad.

The real question is why is the cancel timing out?

I agree that the call to "m_private_state_thread.Reset();" should be removed 
from Process::RunPrivateStateThread(). But we should look at why we need to 
call Cancel in the first place. We should never need to cancel our own thread 
unless something really bad has gone on. So it seems like the real bug here is 
bad thread synchronization leading to issues.

I don't like the fact that we are not copying the thread anymore. We have code 
that sometimes needs to spin up an extra private state thread and I wouldn't 
want the code that changes the m_private_state_thread after backing up an older 
one, cause this function to call IsJoinable(), Cancel() and Join() on different 
objects. So it seems like the only needed fix here is to not call 
"m_private_state_thread.Reset();" in Process::RunPrivateStateThread(), all 
other changes can be removed?


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Zachary Turner via lldb-commits
zturner added a comment.

That should be fine, but as long as I don't have to create a `TypeSP` for it 
when someone calls `FindTypes`, which is the only thing I'm implementing here, 
I think I should be ok.  When I go to create `CXXRecordDecls` to complete class 
types, or when I add support for symbols, I can add those back because then I 
will need it.  Right now I'm only trying to get type lookup working.


http://reviews.llvm.org/D18848



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


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Ulrich Weigand via lldb-commits
Ulrich Weigand/Germany/IBM wrote on 14.04.2016 18:20:20:

> So there seem to be at least two different issues, looking at the build
bot
> logs.   After the main SystemZ patch went it, there was just a single
> failure, a timeout on the new s390x.core test.  I guess we can just
disable
> that test until we know what's going on here.
>
> After the rest of the patches went in, we're additionally seeing all
those
> 32-bit failures.  Not sure which of the patches is responsible (most
likely
> the Scalar / APInt patch, just from the amount of changes).
>
> I'm currently rebuilding the Intel LLDB to see if I can reproduce
locally.

The current status is:

- I've disabled the s390x.core test on all architectures except s390x;
  there seems to be some problem with reading cross-architecture cores.

- There was a regression introduced due to a thinko in my gnu_libstdcpp.py
  patch; I've checked in a fix for that.

- Support for the new files was missing in the XCode project file;
  Greg checked in a fix for that.  Thanks!

- I was unable to reproduce the 32-bit failures on my system, so I just
  reverted the Scalar / APInt patch, and that got the build bot going
again.
  Looking at the results, I think I now understand why I wasn't able to
  reproduce: I was using gcc to compile the test cases, but apparently
  the failure occurred only when using clang.  I'll try again to reproduce.

Right now, the build bots seem to be going green again one by one,
hopefully
we'll be back to normal soon.  Sorry for the breakage!

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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg added a comment.

So you will need to make up base types if you have any types that use them. 
Like if a struct contains an "int", you will need to make an integer up and 
feed it to your CXXRecordDecl. So you will probably need to add those functions 
back. You will need them for:

- class/struct/union members
- class/struct method arguments and return values
- arrays
- plain variables whose types are basic types


http://reviews.llvm.org/D18848



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

Note also that using a copy of the instance variable is no different from using 
the instance variable directly, here, since as you say they both have a shared 
pointer to the same underlying object which is manipulated through either of 
the two to the same effect.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 added inline comments.


Comment at: source/Target/Process.cpp:4116
@@ -4120,1 +4115,3 @@
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {

clayborg wrote:
> If you are going to do IsJoinable(), Cancel(), and Join() then this is still 
> racy in that someone else could do the same thing on another thread. So this 
> code should probably take a mutex to protect:
> 
> ```
> Mutex::Locker locker(m_private_state_thread.GetMutex());
> if (m_private_state_thread.IsJoinable())
> ```
> 
> This would need to live in HostNativeThreadBase because HostThread contains a 
> shared pointer to a HostNativeThreadBase and HostThread can be copied.
> 
I removed the call to `Reset` from the other thread (line 4452 below). It 
didn't make sense for a thread to reset its own `HostThread` since it's not its 
own owner, the Process is.

So now only the `Process` is allowed to control the `HostThread` it owns, and 
there's no races and thus no need for a mutex.


Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB

2016-04-14 Thread Zachary Turner via lldb-commits
zturner updated this revision to Diff 53780.
zturner added a comment.

Generated the wrong patch last time.  This one should be good


http://reviews.llvm.org/D18848

Files:
  include/lldb/Symbol/ClangASTContext.h
  source/Plugins/SymbolFile/PDB/CMakeLists.txt
  source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
  source/Plugins/SymbolFile/PDB/PDBASTParser.h
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
  source/Symbol/ClangASTContext.cpp
  unittests/SymbolFile/PDB/CMakeLists.txt
  unittests/SymbolFile/PDB/Inputs/test-pdb-types.cpp
  unittests/SymbolFile/PDB/Inputs/test-pdb-types.pdb
  unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp

Index: unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
===
--- unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
+++ unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
@@ -11,6 +11,8 @@
 
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Config/config.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
+#include "llvm/DebugInfo/PDB/PDBSymbolExe.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 
@@ -20,6 +22,7 @@
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Host/FileSpec.h"
 #include "lldb/Host/HostInfo.h"
+#include "lldb/Symbol/ClangASTContext.h"
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/LineTable.h"
 #include "lldb/Symbol/SymbolVendor.h"
@@ -29,9 +32,12 @@
 #include "Plugins/SymbolFile/PDB/SymbolFilePDB.h"
 
 #if defined(_MSC_VER)
+#include "lldb/Host/windows/windows.h"
 #include 
 #endif
 
+#include 
+
 extern const char *TestMainArgv0;
 
 using namespace lldb_private;
@@ -42,13 +48,17 @@
 void
 SetUp() override
 {
+// Initialize and TearDown the plugin every time, so we get a brand new
+// AST every time so that modifications to the AST from each test don't
+// leak into the next test.
 #if defined(_MSC_VER)
 ::CoInitializeEx(nullptr, COINIT_MULTITHREADED);
 #endif
 
-HostInfoBase::Initialize();
+HostInfo::Initialize();
 ObjectFilePECOFF::Initialize();
 SymbolFileDWARF::Initialize();
+ClangASTContext::Initialize();
 SymbolFilePDB::Initialize();
 
 llvm::StringRef exe_folder = llvm::sys::path::parent_path(TestMainArgv0);
@@ -57,24 +67,30 @@
 
 m_pdb_test_exe = inputs_folder;
 m_dwarf_test_exe = inputs_folder;
+m_types_test_exe = inputs_folder;
 llvm::sys::path::append(m_pdb_test_exe, "test-pdb.exe");
 llvm::sys::path::append(m_dwarf_test_exe, "test-dwarf.exe");
+llvm::sys::path::append(m_types_test_exe, "test-pdb-types.exe");
 }
 
 void
 TearDown() override
 {
-#if defined(_MSC_VER)
-::CoUninitialize();
-#endif
 SymbolFilePDB::Terminate();
+ClangASTContext::Initialize();
 SymbolFileDWARF::Terminate();
 ObjectFilePECOFF::Terminate();
+HostInfo::Terminate();
+
+#if defined(_MSC_VER)
+::CoUninitialize();
+#endif
 }
 
 protected:
 llvm::SmallString<128> m_pdb_test_exe;
 llvm::SmallString<128> m_dwarf_test_exe;
+llvm::SmallString<128> m_types_test_exe;
 
 bool
 FileSpecMatchesAsBaseOrFull(const FileSpec , const FileSpec ) const
@@ -116,6 +132,35 @@
 }
 return false;
 }
+
+int
+GetGlobalConstantInteger(const llvm::IPDBSession , llvm::StringRef var) const
+{
+auto global = session.getGlobalScope();
+auto results = global->findChildren(llvm::PDB_SymType::Data, var, llvm::PDB_NameSearchFlags::NS_Default);
+uint32_t count = results->getChildCount();
+if (count == 0)
+return -1;
+
+auto item = results->getChildAtIndex(0);
+auto symbol = llvm::dyn_cast(item.get());
+if (!symbol)
+return -1;
+llvm::Variant value = symbol->getValue();
+switch (value.Type)
+{
+case llvm::PDB_VariantType::Int16:
+return value.Value.Int16;
+case llvm::PDB_VariantType::Int32:
+return value.Value.Int32;
+case llvm::PDB_VariantType::UInt16:
+return value.Value.UInt16;
+case llvm::PDB_VariantType::UInt32:
+return value.Value.UInt32;
+default:
+return 0;
+}
+}
 };
 
 #if defined(HAVE_DIA_SDK)
@@ -342,3 +387,196 @@
 VerifyLineEntry(module, sc, source_file, *lt, 9, 0x401045);
 VerifyLineEntry(module, sc, header1, *lt, 9, 0x401090);
 }
+
+TEST_F(SymbolFilePDBTests, REQUIRES_DIA_SDK(TestSimpleClassTypes))
+{
+FileSpec fspec(m_types_test_exe.c_str(), false);
+ArchSpec aspec("i686-pc-windows");
+lldb::ModuleSP module = std::make_shared(fspec, aspec);
+
+SymbolVendor *plugin = module->GetSymbolVendor();
+SymbolFilePDB *symfile = static_cast(plugin->GetSymbolFile());
+const llvm::IPDBSession  = symfile->GetPDBSession();
+SymbolContext 

Re: [Lldb-commits] [PATCH] D19086: [clang-analyzer] fix warnings emitted on lldb code base

2016-04-14 Thread Apelete Seketeli via lldb-commits
apelete marked 2 inline comments as done.
apelete added a comment.

http://reviews.llvm.org/D19086



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


[Lldb-commits] [lldb] r266361 - Fix Xcode project after recent s390x changes.

2016-04-14 Thread Greg Clayton via lldb-commits
Author: gclayton
Date: Thu Apr 14 15:05:21 2016
New Revision: 266361

URL: http://llvm.org/viewvc/llvm-project?rev=266361=rev
Log:
Fix Xcode project after recent s390x changes.


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

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=266361=266360=266361=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Apr 14 15:05:21 2016
@@ -305,6 +305,15 @@
267C012B136880DF006E963E /* OptionGroupValueObjectDisplay.cpp 
in Sources */ = {isa = PBXBuildFile; fileRef = 267C012A136880DF006E963E /* 
OptionGroupValueObjectDisplay.cpp */; };
267C01371368C49C006E963E /* OptionGroupOutputFile.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 26BCFC531368B3E4006DC050 /* 
OptionGroupOutputFile.cpp */; };
267DFB461B06752A0FB7 /* MICmdArgValPrintValues.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 267DFB441B06752A0FB7 /* 
MICmdArgValPrintValues.cpp */; };
+   267F684A1CC02DED0086832B /* ABISysV_s390x.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 267F68471CC02DED0086832B /* ABISysV_s390x.cpp 
*/; };
+   267F684B1CC02DED0086832B /* ABISysV_s390x.h in Headers */ = 
{isa = PBXBuildFile; fileRef = 267F68481CC02DED0086832B /* ABISysV_s390x.h */; 
};
+   267F684F1CC02E270086832B /* RegisterContextPOSIXCore_s390x.cpp 
in Sources */ = {isa = PBXBuildFile; fileRef = 267F684D1CC02E270086832B /* 
RegisterContextPOSIXCore_s390x.cpp */; };
+   267F68501CC02E270086832B /* RegisterContextPOSIXCore_s390x.h in 
Headers */ = {isa = PBXBuildFile; fileRef = 267F684E1CC02E270086832B /* 
RegisterContextPOSIXCore_s390x.h */; };
+   267F68531CC02E920086832B /* RegisterContextLinux_s390x.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 267F68511CC02E920086832B /* 
RegisterContextLinux_s390x.cpp */; };
+   267F68541CC02E920086832B /* RegisterContextLinux_s390x.h in 
Headers */ = {isa = PBXBuildFile; fileRef = 267F68521CC02E920086832B /* 
RegisterContextLinux_s390x.h */; };
+   267F68571CC02EAE0086832B /* RegisterContextPOSIX_s390x.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 267F68551CC02EAE0086832B /* 
RegisterContextPOSIX_s390x.cpp */; };
+   267F68581CC02EAE0086832B /* RegisterContextPOSIX_s390x.h in 
Headers */ = {isa = PBXBuildFile; fileRef = 267F68561CC02EAE0086832B /* 
RegisterContextPOSIX_s390x.h */; };
+   267F685A1CC02EBE0086832B /* RegisterInfos_s390x.h in Headers */ 
= {isa = PBXBuildFile; fileRef = 267F68591CC02EBE0086832B /* 
RegisterInfos_s390x.h */; };
268648C416531BF800F04704 /* com.apple.debugserver.posix.plist 
in CopyFiles */ = {isa = PBXBuildFile; fileRef = 268648C116531BF800F04704 /* 
com.apple.debugserver.posix.plist */; };
268648C516531BF800F04704 /* 
com.apple.debugserver.applist.internal.plist in CopyFiles */ = {isa = 
PBXBuildFile; fileRef = 268648C216531BF800F04704 /* 
com.apple.debugserver.applist.internal.plist */; };
268648C616531BF800F04704 /* 
com.apple.debugserver.internal.plist in CopyFiles */ = {isa = PBXBuildFile; 
fileRef = 268648C316531BF800F04704 /* com.apple.debugserver.internal.plist */; 
};
@@ -1706,6 +1715,15 @@
267C012A136880DF006E963E /* OptionGroupValueObjectDisplay.cpp 
*/ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; name = OptionGroupValueObjectDisplay.cpp; path = 
source/Interpreter/OptionGroupValueObjectDisplay.cpp; sourceTree = ""; };
267DFB441B06752A0FB7 /* MICmdArgValPrintValues.cpp */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; name = MICmdArgValPrintValues.cpp; path = 
"tools/lldb-mi/MICmdArgValPrintValues.cpp"; sourceTree = SOURCE_ROOT; };
267DFB451B06752A0FB7 /* MICmdArgValPrintValues.h */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name 
= MICmdArgValPrintValues.h; path = "tools/lldb-mi/MICmdArgValPrintValues.h"; 
sourceTree = SOURCE_ROOT; };
+   267F68471CC02DED0086832B /* ABISysV_s390x.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = ABISysV_s390x.cpp; sourceTree = ""; };
+   267F68481CC02DED0086832B /* ABISysV_s390x.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
ABISysV_s390x.h; sourceTree = ""; };
+   267F684D1CC02E270086832B /* RegisterContextPOSIXCore_s390x.cpp 
*/ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; path = RegisterContextPOSIXCore_s390x.cpp; sourceTree = 
""; };
+   267F684E1CC02E270086832B /* 

[Lldb-commits] [lldb] r266352 - Fix regression in gnu_libstdcpp.py introduced by r266313

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 13:31:12 2016
New Revision: 266352

URL: http://llvm.org/viewvc/llvm-project?rev=266352=rev
Log:
Fix regression in gnu_libstdcpp.py introduced by r266313

CreateChildAtOffset needs a byte offset, not an element number.


Modified:
lldb/trunk/examples/synthetic/gnu_libstdcpp.py

Modified: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/synthetic/gnu_libstdcpp.py?rev=266352=266351=266352=diff
==
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py (original)
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py Thu Apr 14 13:31:12 2016
@@ -239,7 +239,7 @@ class StdVectorSynthProvider:
return None
element_type = self.start_p.GetType().GetPointeeType()
element_bits = 8 * element_type.GetByteSize()
-   element_offset = index / element_bits
+   element_offset = (index / element_bits) * 
element_type.GetByteSize()
bit_offset = index % element_bits
element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)


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


Re: [Lldb-commits] [PATCH] D19092: Fix Android build after r266267

2016-04-14 Thread Pavel Labath via lldb-commits
labath added a subscriber: labath.
labath added a comment.

Judging by the cryptic error message, and the fact that a global variable 
should not cause an issue, i suspect stdout was a macro in this case...


http://reviews.llvm.org/D19092



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


Re: [Lldb-commits] [PATCH] D19092: Fix Android build after r266267

2016-04-14 Thread Enrico Granata via lldb-commits

> On Apr 14, 2016, at 10:56 AM, Oleksiy Vyalov via lldb-commits 
>  wrote:
> 
> ovyalov added a comment.
> 
> In http://reviews.llvm.org/D19092#401450, @jingham wrote:
> 
>> Why is this necessary?  stdout is a local variable defined in this scope.  
>> Why would the android g++ have problems with this?
>> 
>> Anyway, if you have to avoid using stdout as a name, maybe name it std_out 
>> as that better reflects its meaning.
> 
> 
> My understanding that NDK toolchain exposes stdout global variable that is 
> caused name collision here.
> 

That seems wrong - if stdout truly is just a global variable, the scoping rules 
should totally allow me to define a local by the same name

Our (uneducated) guess is that stdout is defined to be a macro which expands to 
something that is not actually an identifier (which - at a glance - looks like 
it is not POSIX compliant)

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


Thanks,
- Enrico
 egranata@.com ☎️ 27683

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


Re: [Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Greg Clayton via lldb-commits
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

If you use the instance variable directly, we will need a mutex inside the 
HostNativeThreadBase class to protect against multi-threaded access. I believe 
the reason it was being copied before was in case the Reset was called on 
another thread. So we might want a mutex in HostNativeThreadBase that gets 
exposed via HostThread. See inlined comments.



Comment at: source/Target/Process.cpp:4116
@@ -4120,1 +4115,3 @@
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {

If you are going to do IsJoinable(), Cancel(), and Join() then this is still 
racy in that someone else could do the same thing on another thread. So this 
code should probably take a mutex to protect:

```
Mutex::Locker locker(m_private_state_thread.GetMutex());
if (m_private_state_thread.IsJoinable())
```

This would need to live in HostNativeThreadBase because HostThread contains a 
shared pointer to a HostNativeThreadBase and HostThread can be copied.



Repository:
  rL LLVM

http://reviews.llvm.org/D19122



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


Re: [Lldb-commits] [PATCH] D19092: Fix Android build after r266267

2016-04-14 Thread Oleksiy Vyalov via lldb-commits
ovyalov added a comment.

In http://reviews.llvm.org/D19092#401450, @jingham wrote:

> Why is this necessary?  stdout is a local variable defined in this scope.  
> Why would the android g++ have problems with this?
>
> Anyway, if you have to avoid using stdout as a name, maybe name it std_out as 
> that better reflects its meaning.


My understanding that NDK toolchain exposes stdout global variable that is 
caused name collision here.


http://reviews.llvm.org/D19092



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


[Lldb-commits] [lldb] r266343 - Disable LinuxCoreTestCase.test_s390x

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 12:36:41 2016
New Revision: 266343

URL: http://llvm.org/viewvc/llvm-project?rev=266343=rev
Log:
Disable LinuxCoreTestCase.test_s390x

This seems to hang on non-s390x hosts.  Disable for now to get the build
bots going again.


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py?rev=266343=266342=266343=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
 Thu Apr 14 12:36:41 2016
@@ -30,6 +30,8 @@ class LinuxCoreTestCase(TestBase):
 """Test that lldb can read the process information from an x86_64 
linux core file."""
 self.do_test("x86_64", self._x86_64_pid)
 
+# This seems to hang on non-s390x platforms for some reason.  Disabling 
for now.
+@skipIf(archs=no_match(['s390x'])) 
 def test_s390x(self):
 """Test that lldb can read the process information from an s390x linux 
core file."""
 self.do_test("s390x", self._s390x_pid)


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


Re: [Lldb-commits] [PATCH] D19092: Fix Android build after r266267

2016-04-14 Thread Jim Ingham via lldb-commits
jingham added a subscriber: jingham.
jingham added a comment.

Why is this necessary?  stdout is a local variable defined in this scope.  Why 
would the android g++ have problems with this?

Anyway, if you have to avoid using stdout as a name, maybe name it std_out as 
that better reflects its meaning.


http://reviews.llvm.org/D19092



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


[Lldb-commits] [lldb] r266341 - Revert r266311 - Fix usage of APInt.getRawData for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 12:22:18 2016
New Revision: 266341

URL: http://llvm.org/viewvc/llvm-project?rev=266341=rev
Log:
Revert r266311 - Fix usage of APInt.getRawData for big-endian systems

Try to get 32-bit build bots running again.


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266341=266340=266341=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Thu Apr 14 12:22:18 2016
@@ -162,9 +162,6 @@ public:
 bool
 MakeSigned ();
 
-bool
-MakeUnsigned ();
-
 static const char *
 GetValueTypeAsCString (Scalar::Type value_type);
 
@@ -242,10 +239,22 @@ public:
 int
 SInt(int fail_value = 0) const;
 
+// Return the raw unsigned integer without any casting or conversion
+unsigned int
+RawUInt () const;
+
+// Return the raw unsigned long without any casting or conversion
+unsigned long
+RawULong () const;
+
+// Return the raw unsigned long long without any casting or conversion
+unsigned long long
+RawULongLong () const;
+
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
-signed char
+char
 SChar(char fail_value = 0) const;
 
 unsigned short
@@ -290,6 +299,9 @@ public:
 long double
 LongDouble(long double fail_value = 0.0) const;
 
+uint64_t
+GetRawBits64 (uint64_t fail_value) const;
+
 Error
 SetValueFromCString (const char *s, lldb::Encoding encoding, size_t 
byte_size);
 

Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266341=266340=266341=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Thu Apr 14 12:22:18 2016
@@ -958,13 +958,13 @@ public:
 uint64_t
 GetValueAsUnsigned () const
 {
-return m_value.getZExtValue();
+return *m_value.getRawData();
 }
 
 int64_t
 GetValueAsSigned () const
 {
-return m_value.getSExtValue();
+return (int64_t) *m_value.getRawData();
 }
 
 protected:

Modified: lldb/trunk/source/Core/Scalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266341=266340=266341=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Thu Apr 14 12:22:18 2016
@@ -16,8 +16,6 @@
 #include 
 
 // Other libraries and framework includes
-#include "llvm/ADT/SmallString.h"
-
 // Project includes
 #include "lldb/Interpreter/Args.h"
 #include "lldb/Core/Error.h"
@@ -136,10 +134,10 @@ bool
 Scalar::GetData (DataExtractor , size_t limit_byte_size) const
 {
 size_t byte_size = GetByteSize();
+static float f_val;
+static double d_val;
 if (byte_size > 0)
 {
-const uint8_t *bytes = reinterpret_cast(GetBytes());
-
 if (limit_byte_size < byte_size)
 {
 if (endian::InlHostByteOrder() == eByteOrderLittle)
@@ -147,19 +145,105 @@ Scalar::GetData (DataExtractor , si
 // On little endian systems if we want fewer bytes from the
 // current type we just specify fewer bytes since the LSByte
 // is first...
-byte_size = limit_byte_size;
+switch(m_type)
+{
+case e_void:
+break;
+case e_sint:
+case e_uint:
+case e_slong:
+case e_ulong:
+case e_slonglong:
+case e_ulonglong:
+case e_sint128:
+case e_uint128:
+case e_sint256:
+case e_uint256:
+data.SetData((const uint8_t *)m_integer.getRawData(), 
limit_byte_size, endian::InlHostByteOrder());
+return true;
+case e_float:
+f_val = m_float.convertToFloat();
+data.SetData((uint8_t *)_val, limit_byte_size, 
endian::InlHostByteOrder());
+return true;
+case e_double:
+d_val = m_float.convertToDouble();
+data.SetData((uint8_t *)_val, limit_byte_size, 
endian::InlHostByteOrder());
+return true;
+case e_long_double:
+

Re: [Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

Whoops, my fault. I was accidentally using the VS2013 command prompt with the 
2015 cmake files. Compiling happily as we speak, test coming up soon after.


Repository:
  rL LLVM

http://reviews.llvm.org/D19124



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


Re: [Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Zachary Turner via lldb-commits
http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015

My build bot which uses MSVC 2015 is workign fine.  What kind of error are
you seeing?

On Thu, Apr 14, 2016 at 10:14 AM Cameron  wrote:

> cameron314 added a comment.
>
> Ah, that's a bit tricky at the moment. The LLVM tip no longer compiles
> with VS2015 (specifically lib\Support\SourceMgr.cpp), and my Python setup
> for VS2013 is all wonky.
> This will have to wait a bit.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D19124
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Cameron via lldb-commits
cameron314 added a comment.

Ah, that's a bit tricky at the moment. The LLVM tip no longer compiles with 
VS2015 (specifically lib\Support\SourceMgr.cpp), and my Python setup for VS2013 
is all wonky.
This will have to wait a bit.


Repository:
  rL LLVM

http://reviews.llvm.org/D19124



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


Re: [Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Zachary Turner via lldb-commits
zturner added a subscriber: zturner.
zturner added a comment.

I'll let Sean comment on the content of the patch, but please add a test
that runs such an expression and demonstrates the correct output.


Repository:
  rL LLVM

http://reviews.llvm.org/D19124



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


Re: [Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Zachary Turner via lldb-commits
I'll let Sean comment on the content of the patch, but please add a test
that runs such an expression and demonstrates the correct output.

On Thu, Apr 14, 2016 at 10:01 AM Cameron via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> cameron314 created this revision.
> cameron314 added a reviewer: spyffe.
> cameron314 added subscribers: mamai, lldb-commits.
> cameron314 set the repository for this revision to rL LLVM.
>
> This allows expressions such as 'i == 1 || i == 2` to be executed using
> the IR interpreter.
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D19124
>
> Files:
>   source/Expression/IRInterpreter.cpp
>
> Index: source/Expression/IRInterpreter.cpp
> ===
> --- source/Expression/IRInterpreter.cpp
> +++ source/Expression/IRInterpreter.cpp
> @@ -106,6 +106,7 @@
>  DataLayout _target_data;
>  lldb_private::IRExecutionUnit  _execution_unit;
>  const BasicBlock   *m_bb;
> +const BasicBlock   *m_prev_bb;
>  BasicBlock::const_iterator  m_ii;
>  BasicBlock::const_iterator  m_ie;
>
> @@ -121,7 +122,9 @@
> lldb::addr_t stack_frame_bottom,
> lldb::addr_t stack_frame_top) :
>  m_target_data (target_data),
> -m_execution_unit (execution_unit)
> +m_execution_unit (execution_unit),
> +m_bb (nullptr),
> +m_prev_bb (nullptr)
>  {
>  m_byte_order = (target_data.isLittleEndian() ?
> lldb::eByteOrderLittle : lldb::eByteOrderBig);
>  m_addr_byte_size = (target_data.getPointerSize(0));
> @@ -137,6 +140,7 @@
>
>  void Jump (const BasicBlock *bb)
>  {
> +m_prev_bb = m_bb;
>  m_bb = bb;
>  m_ii = m_bb->begin();
>  m_ie = m_bb->end();
> @@ -563,6 +567,7 @@
>  case Instruction::Alloca:
>  case Instruction::BitCast:
>  case Instruction::Br:
> +case Instruction::PHI:
>  break;
>  case Instruction::Call:
>  {
> @@ -1052,6 +1057,46 @@
>  }
>  }
>  continue;
> +case Instruction::PHI:
> +{
> +const PHINode *phi_inst = dyn_cast(inst);
> +
> +if (!phi_inst)
> +{
> +if (log)
> +log->Printf("getOpcode() returns PHI, but
> instruction is not a PHINode");
> +error.SetErrorToGenericError();
> +error.SetErrorString(interpreter_internal_error);
> +return false;
> +}
> +if (!frame.m_prev_bb)
> +{
> +if (log)
> +log->Printf("Encountered PHI node without having
> jumped from another basic block");
> +error.SetErrorToGenericError();
> +error.SetErrorString(interpreter_internal_error);
> +return false;
> +}
> +
> +Value* value =
> phi_inst->getIncomingValueForBlock(frame.m_prev_bb);
> +lldb_private::Scalar result;
> +if (!frame.EvaluateValue(result, value, module))
> +{
> +if (log)
> +log->Printf("Couldn't evaluate %s",
> PrintValue(value).c_str());
> +error.SetErrorToGenericError();
> +error.SetErrorString(bad_value_error);
> +return false;
> +}
> +frame.AssignValue(inst, result, module);
> +
> +if (log)
> +{
> +log->Printf("Interpreted a %s",
> inst->getOpcodeName());
> +log->Printf("  Incoming value : %s",
> frame.SummarizeValue(value).c_str());
> +}
> +}
> +break;
>  case Instruction::GetElementPtr:
>  {
>  const GetElementPtrInst *gep_inst =
> dyn_cast(inst);
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D19124: [LLDB] Added support for PHI nodes to IR interpreter

2016-04-14 Thread Cameron via lldb-commits
cameron314 created this revision.
cameron314 added a reviewer: spyffe.
cameron314 added subscribers: mamai, lldb-commits.
cameron314 set the repository for this revision to rL LLVM.

This allows expressions such as 'i == 1 || i == 2` to be executed using the IR 
interpreter.

Repository:
  rL LLVM

http://reviews.llvm.org/D19124

Files:
  source/Expression/IRInterpreter.cpp

Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -106,6 +106,7 @@
 DataLayout _target_data;
 lldb_private::IRExecutionUnit  _execution_unit;
 const BasicBlock   *m_bb;
+const BasicBlock   *m_prev_bb;
 BasicBlock::const_iterator  m_ii;
 BasicBlock::const_iterator  m_ie;
 
@@ -121,7 +122,9 @@
lldb::addr_t stack_frame_bottom,
lldb::addr_t stack_frame_top) :
 m_target_data (target_data),
-m_execution_unit (execution_unit)
+m_execution_unit (execution_unit),
+m_bb (nullptr),
+m_prev_bb (nullptr)
 {
 m_byte_order = (target_data.isLittleEndian() ? lldb::eByteOrderLittle 
: lldb::eByteOrderBig);
 m_addr_byte_size = (target_data.getPointerSize(0));
@@ -137,6 +140,7 @@
 
 void Jump (const BasicBlock *bb)
 {
+m_prev_bb = m_bb;
 m_bb = bb;
 m_ii = m_bb->begin();
 m_ie = m_bb->end();
@@ -563,6 +567,7 @@
 case Instruction::Alloca:
 case Instruction::BitCast:
 case Instruction::Br:
+case Instruction::PHI:
 break;
 case Instruction::Call:
 {
@@ -1052,6 +1057,46 @@
 }
 }
 continue;
+case Instruction::PHI:
+{
+const PHINode *phi_inst = dyn_cast(inst);
+
+if (!phi_inst)
+{
+if (log)
+log->Printf("getOpcode() returns PHI, but instruction 
is not a PHINode");
+error.SetErrorToGenericError();
+error.SetErrorString(interpreter_internal_error);
+return false;
+}
+if (!frame.m_prev_bb)
+{
+if (log)
+log->Printf("Encountered PHI node without having 
jumped from another basic block");
+error.SetErrorToGenericError();
+error.SetErrorString(interpreter_internal_error);
+return false;
+}
+
+Value* value = 
phi_inst->getIncomingValueForBlock(frame.m_prev_bb);
+lldb_private::Scalar result;
+if (!frame.EvaluateValue(result, value, module))
+{
+if (log)
+log->Printf("Couldn't evaluate %s", 
PrintValue(value).c_str());
+error.SetErrorToGenericError();
+error.SetErrorString(bad_value_error);
+return false;
+}
+frame.AssignValue(inst, result, module);
+
+if (log)
+{
+log->Printf("Interpreted a %s", inst->getOpcodeName());
+log->Printf("  Incoming value : %s", 
frame.SummarizeValue(value).c_str());
+}
+}
+break;
 case Instruction::GetElementPtr:
 {
 const GetElementPtrInst *gep_inst = 
dyn_cast(inst);


Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -106,6 +106,7 @@
 DataLayout _target_data;
 lldb_private::IRExecutionUnit  _execution_unit;
 const BasicBlock   *m_bb;
+const BasicBlock   *m_prev_bb;
 BasicBlock::const_iterator  m_ii;
 BasicBlock::const_iterator  m_ie;
 
@@ -121,7 +122,9 @@
lldb::addr_t stack_frame_bottom,
lldb::addr_t stack_frame_top) :
 m_target_data (target_data),
-m_execution_unit (execution_unit)
+m_execution_unit (execution_unit),
+m_bb (nullptr),
+m_prev_bb (nullptr)
 {
 m_byte_order = (target_data.isLittleEndian() ? lldb::eByteOrderLittle : lldb::eByteOrderBig);
 m_addr_byte_size = (target_data.getPointerSize(0));
@@ -137,6 +140,7 @@
 
 void Jump (const BasicBlock *bb)
 {
+m_prev_bb = m_bb;
 m_bb = bb;
 m_ii = m_bb->begin();
 m_ie = m_bb->end();
@@ -563,6 +567,7 @@
 case 

Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR

2016-04-14 Thread Francis Ricci via lldb-commits
fjricci added a comment.

When I use LLVM_LIBDIR_SUFFIX=64, it looks like the python _lldb.so symlink 
still points to build/lib/liblldb.so, instead of using the lib64 directory. So 
if I do this, none of the tests will run on the check-lldb target, since 
importing lldb in python fails.

Perhaps this symlink is the bug that should be fixed? However, it appears that 
finish-swig-Python-LLDB.sh already has the correct logic for this, so it's not 
immediately clear to me why the symlink is incorrect (if this seems like a bug 
we want fixed, I'll investigate):

  ln -s "../../../liblldb${SOEXT}" _lldb.so


http://reviews.llvm.org/D19067



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


[Lldb-commits] [PATCH] D19122: LLDB: Fixed race condition on timeout when stopping private state thread

2016-04-14 Thread Cameron via lldb-commits
cameron314 created this revision.
cameron314 added reviewers: clayborg, zturner, jingham.
cameron314 added subscribers: mamai, lldb-commits.
cameron314 set the repository for this revision to rL LLVM.

When stopping the private state thread, there was a race condition between the 
time the thread exits (resetting the HostThread object) and the time a Join was 
attempted, especially in the case of a timeout.

The previous workaround of copying the HostThread object is not enough, since 
on a Reset the internal thread stuff gets nulled out regardless of which 
HostThread object actually has Reset called on it, resulting in an attempt to 
dereference a null pointer on the subsequent call to Join from the copy as well.

In our environment (custom target), we were hitting this every time we stopped 
debugging.

Repository:
  rL LLVM

http://reviews.llvm.org/D19122

Files:
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -4112,11 +4112,8 @@
 if (log)
 log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
 
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {
 TimeValue timeout_time;
 bool timed_out;
@@ -4134,7 +4131,7 @@
 {
 if (timed_out)
 {
-Error error = private_state_thread.Cancel();
+Error error = m_private_state_thread.Cancel();
 if (log)
 log->Printf ("Timed out responding to the control event, 
cancel got error: \"%s\".", error.AsCString());
 }
@@ -4145,7 +4142,7 @@
 }
 
 thread_result_t result = NULL;
-private_state_thread.Join();
+m_private_state_thread.Join();
 m_private_state_thread.Reset();
 }
 }
@@ -4449,7 +4446,6 @@
 if (!is_secondary_thread)
 m_public_run_lock.SetStopped();
 m_private_state_control_wait.SetValue (true, eBroadcastAlways);
-m_private_state_thread.Reset();
 return NULL;
 }
 


Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -4112,11 +4112,8 @@
 if (log)
 log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
 
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {
 TimeValue timeout_time;
 bool timed_out;
@@ -4134,7 +4131,7 @@
 {
 if (timed_out)
 {
-Error error = private_state_thread.Cancel();
+Error error = m_private_state_thread.Cancel();
 if (log)
 log->Printf ("Timed out responding to the control event, cancel got error: \"%s\".", error.AsCString());
 }
@@ -4145,7 +4142,7 @@
 }
 
 thread_result_t result = NULL;
-private_state_thread.Join();
+m_private_state_thread.Join();
 m_private_state_thread.Reset();
 }
 }
@@ -4449,7 +4446,6 @@
 if (!is_secondary_thread)
 m_public_run_lock.SetStopped();
 m_private_state_control_wait.SetValue (true, eBroadcastAlways);
-m_private_state_thread.Reset();
 return NULL;
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Ulrich Weigand via lldb-commits
Pavel Labath  wrote on 14.04.2016 17:36:40:

> this has broken basically everything on 32-bit targets
>
 >.
> Will you be able to track down the problem quickly? I don't expect the
> fix to be complicated, but if we can't track it down quickly (1-2
> hours?) we should start pulling out the offending changes...

So there seem to be at least two different issues, looking at the build bot
logs.   After the main SystemZ patch went it, there was just a single
failure, a timeout on the new s390x.core test.  I guess we can just disable
that test until we know what's going on here.

After the rest of the patches went in, we're additionally seeing all those
32-bit failures.  Not sure which of the patches is responsible (most likely
the Scalar / APInt patch, just from the amount of changes).

I'm currently rebuilding the Intel LLDB to see if I can reproduce locally.

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


Re: [Lldb-commits] [PATCH] D19114: [test] Relax stderr expectations on targets with chatty output

2016-04-14 Thread Pavel Labath via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266326: [test] Relax stderr expectations on targets with 
chatty output (authored by labath).

Changed prior to commit:
  http://reviews.llvm.org/D19114?vs=53718=53737#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D19114

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
  lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -139,3 +139,10 @@
 return _PlatformContext('LD_LIBRARY_PATH', 'lib', 'so')
 else:
 return None
+
+def hasChattyStderr(test_case):
+"""Some targets produce garbage on the standard error output. This utility function
+determines whether the tests can be strict about the expected stderr contents."""
+if match_android_device(test_case.getArchitecture(), ['aarch64'], [22]):
+return True # The dynamic linker on the device will complain about unknown DT entries
+return False
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -1374,3 +1374,6 @@
 self.assertTrue(state_reached)
 self.assertEqual(step_count, expected_step_count)
 
+def maybe_strict_output_regex(self, regex):
+return '.*'+regex+'.*' if lldbplatformutil.hasChattyStderr(self) else '^'+regex+'$'
+
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -787,7 +787,7 @@
 regex = line.get("regex", None)
 # Compile the regex.
 if regex and (type(regex) == str):
-regex = re.compile(regex)
+regex = re.compile(regex, re.DOTALL)
 
 regex_mode = line.get("regex_mode", "match")
 capture = line.get("capture", None)
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
@@ -232,7 +232,7 @@
 self.add_verified_launch_packets(launch_args)
 self.test_sequence.add_log_lines(
 ["read packet: $vCont;c#a8",
- {"type":"output_match", "regex":r"^hello, world\r\n$" },
+ {"type":"output_match", "regex": self.maybe_strict_output_regex(r"hello, world\r\n")},
  "send packet: $W00#00"],
 True)
 
@@ -868,7 +868,8 @@
  "read packet: $c#63",
  # Match output line that prints the memory address of the message buffer within the inferior. 
  # Note we require launch-only testing so we can get inferior otuput.
- { "type":"output_match", "regex":r"^data address: 0x([0-9a-fA-F]+)\r\n$", "capture":{ 1:"message_address"} },
+ { "type":"output_match", "regex":self.maybe_strict_output_regex(r"data address: 0x([0-9a-fA-F]+)\r\n"),
+   "capture":{ 1:"message_address"} },
  # Now stop the inferior.
  "read packet: {}".format(chr(3)),
  # And wait for the stop notification.
@@ -950,7 +951,8 @@
  "read packet: $c#63",
  # Match output line that prints the memory address of the message buffer within the inferior. 
  # Note we require launch-only testing so we can get inferior otuput.
- { "type":"output_match", "regex":r"^code address: 0x([0-9a-fA-F]+)\r\n$", "capture":{ 1:"code_address"} },
+ { "type":"output_match", "regex":self.maybe_strict_output_regex(r"code address: 0x([0-9a-fA-F]+)\r\n"),
+   "capture":{ 1:"code_address"} },
  # Now stop the inferior.
  

[Lldb-commits] [lldb] r266326 - [test] Relax stderr expectations on targets with chatty output

2016-04-14 Thread Pavel Labath via lldb-commits
Author: labath
Date: Thu Apr 14 10:52:53 2016
New Revision: 266326

URL: http://llvm.org/viewvc/llvm-project?rev=266326=rev
Log:
[test] Relax stderr expectations on targets with chatty output

Summary:
On some android targets, a binary can produce additional garbage (e.g. warning 
messages from the
dynamic linker) on the standard error, which confuses some tests. This relaxes 
the stderr
expectations for targets known for their chattyness.

Reviewers: tfiala, ovyalov

Subscribers: tberghammer, danalbert, srhines, lldb-commits

Differential Revision: http://reviews.llvm.org/D19114

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py?rev=266326=266325=266326=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py Thu Apr 14 
10:52:53 2016
@@ -139,3 +139,10 @@ def createPlatformContext():
 return _PlatformContext('LD_LIBRARY_PATH', 'lib', 'so')
 else:
 return None
+
+def hasChattyStderr(test_case):
+"""Some targets produce garbage on the standard error output. This utility 
function
+determines whether the tests can be strict about the expected stderr 
contents."""
+if match_android_device(test_case.getArchitecture(), ['aarch64'], [22]):
+return True # The dynamic linker on the device will complain about 
unknown DT entries
+return False

Modified: lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py?rev=266326=266325=266326=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/settings/TestSettings.py Thu Apr 
14 10:52:53 2016
@@ -312,8 +312,11 @@ class SettingsCommandTestCase(TestBase):
 with open('stderr.txt', 'r') as f:
 output = f.read()
 
-self.expect(output, exe=False,
-startstr = "This message should go to standard error.")
+message = "This message should go to standard error."
+if lldbplatformutil.hasChattyStderr(self):
+self.expect(output, exe=False, substrs = [message])
+else:
+self.expect(output, exe=False, startstr = message)
 
 # The 'stdout.txt' file should now exist.
 self.assertTrue(os.path.isfile("stdout.txt"),

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py?rev=266326=266325=266326=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
 Thu Apr 14 10:52:53 2016
@@ -25,7 +25,7 @@ class TestGdbRemoteAuxvSupport(gdbremote
 # Start the inferior...
 "read packet: $c#63",
 # ... match output
-{ "type":"output_match", "regex":r"^message:main entered\r\n$" },
+{ "type":"output_match", 
"regex":self.maybe_strict_output_regex(r"message:main entered\r\n") },
 ], True)
 # ... then interrupt.
 self.add_interrupt_packets()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py?rev=266326=266325=266326=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py
 Thu Apr 14 10:52:53 2016
@@ -26,7 +26,7 @@ class TestGdbRemoteRegisterState(gdbremo
 # Start the inferior...
 "read packet: $c#63",
  

[Lldb-commits] [lldb] r266327 - [test] make expect_state_changes actually expect *only* them

2016-04-14 Thread Pavel Labath via lldb-commits
Author: labath
Date: Thu Apr 14 10:52:58 2016
New Revision: 266327

URL: http://llvm.org/viewvc/llvm-project?rev=266327=rev
Log:
[test] make expect_state_changes actually expect *only* them

The android dirty stderr problem has uncovered an issue where 
lldbutil.expect_state_changes was
reading events other than state change events, which resulted in general 
confusion. Make it more
strict to accept *only* state changes.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
lldb/trunk/packages/Python/lldbsuite/test/lldbutil.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py?rev=266327=266326=266327=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/attach_resume/TestAttachResume.py
 Thu Apr 14 10:52:58 2016
@@ -38,19 +38,20 @@ class AttachResumeTestCase(TestBase):
 
 self.setAsync(True)
 listener = self.dbg.GetListener()
+process = self.dbg.GetSelectedTarget().GetProcess()
 
 self.runCmd("c")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 self.runCmd("process interrupt")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateStopped])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateStopped])
 
 # be sure to continue/interrupt/continue (r204504)
 self.runCmd("c")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 self.runCmd("process interrupt")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateStopped])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateStopped])
 
 # Second interrupt should have no effect.
 self.expect("process interrupt", patterns=["Process is not running"], 
error=True)
@@ -59,7 +60,7 @@ class AttachResumeTestCase(TestBase):
 self.runCmd("br set -f main.cpp -l %u" % (line_number('main.cpp', '// 
Set breakpoint here')))
 
 self.runCmd("c")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning, 
lldb.eStateStopped])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning, lldb.eStateStopped])
 self.expect('br list', 'Breakpoint not hit',
 substrs = ['hit count = 1'])
 
@@ -67,8 +68,8 @@ class AttachResumeTestCase(TestBase):
 self.expect("expr debugger_flag = false", substrs=[" = false"]);
 
 self.runCmd("c")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 # make sure to detach while in running state (r204759)
 self.runCmd("detach")
-lldbutil.expect_state_changes(self, listener, [lldb.eStateDetached])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateDetached])

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py?rev=266327=266326=266327=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
 Thu Apr 14 10:52:58 2016
@@ -89,11 +89,11 @@ class ThreadStateTestCase(TestBase):
 # Kill the process
 self.runCmd("process kill")
 
-def wait_for_running_event(self):
+def wait_for_running_event(self, process):
 listener = self.dbg.GetListener()
 if lldb.remote_platform:
-lldbutil.expect_state_changes(self, listener, 
[lldb.eStateConnected])
-lldbutil.expect_state_changes(self, listener, [lldb.eStateRunning])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateConnected])
+lldbutil.expect_state_changes(self, listener, process, 
[lldb.eStateRunning])
 
 def thread_state_after_continue_test(self):
 """Test thread state after continue."""
@@ -117,7 +117,7 @@ class ThreadStateTestCase(TestBase):
 # Continue, the inferior will go into an infinite loop waiting for 
'g_test' to change.
 

Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Ulrich Weigand via lldb-commits
Pavel Labath  wrote on 14.04.2016 17:36:40:

> this has broken basically everything on 32-bit targets
>
 >.
> Will you be able to track down the problem quickly? I don't expect the
> fix to be complicated, but if we can't track it down quickly (1-2
> hours?) we should start pulling out the offending changes...

Huh, sorry for that.  I did test x86_64, but not 32-bit.

I'll have a look and see what I can find.

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


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Pavel Labath via lldb-commits
labath added a subscriber: labath.
labath added a comment.

Hi,

this has broken basically everything on 32-bit targets
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/13413.
Will you be able to track down the problem quickly? I don't expect the
fix to be complicated, but if we can't track it down quickly (1-2
hours?) we should start pulling out the offending changes...

pl


Repository:
  rL LLVM

http://reviews.llvm.org/D18978



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


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Pavel Labath via lldb-commits
Hi,

this has broken basically everything on 32-bit targets
.
Will you be able to track down the problem quickly? I don't expect the
fix to be complicated, but if we can't track it down quickly (1-2
hours?) we should start pulling out the offending changes...

pl

On 14 April 2016 at 16:07, Ulrich Weigand  wrote:
> uweigand added a comment.
>
> In http://reviews.llvm.org/D18978#400787, @labath wrote:
>
>> That's perfect, thanks a lot. :)
>>
>> Do you have commit access? If not, let me know when you're ready to start 
>> landing these things...
>
>
> I do have commit access, and have committed the 10 out of 12 patches that are 
> approved as of today.  This means current mainline should support Linux on 
> SystemZ as target pretty well.  Due to the two patches still missing, I'm 
> still seeing three test suite failures: TestNoreturnUnwind.py and 
> TestInferiorAssert.py fail due to missing http://reviews.llvm.org/D18975, and 
> TestCppScope.py fails due to missing http://reviews.llvm.org/D18976.
>
> Otherwise, everything is looking good.   Thanks to everybody for your support 
> in getting this in!
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D18978
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Ulrich Weigand via lldb-commits
uweigand added a comment.

In http://reviews.llvm.org/D18978#400787, @labath wrote:

> That's perfect, thanks a lot. :)
>
> Do you have commit access? If not, let me know when you're ready to start 
> landing these things...


I do have commit access, and have committed the 10 out of 12 patches that are 
approved as of today.  This means current mainline should support Linux on 
SystemZ as target pretty well.  Due to the two patches still missing, I'm still 
seeing three test suite failures: TestNoreturnUnwind.py and 
TestInferiorAssert.py fail due to missing http://reviews.llvm.org/D18975, and 
TestCppScope.py fails due to missing http://reviews.llvm.org/D18976.

Otherwise, everything is looking good.   Thanks to everybody for your support 
in getting this in!


Repository:
  rL LLVM

http://reviews.llvm.org/D18978



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


Re: [Lldb-commits] [PATCH] D19114: [test] Relax stderr expectations on targets with chatty output

2016-04-14 Thread Tamas Berghammer via lldb-commits
tberghammer accepted this revision.
tberghammer added a reviewer: tberghammer.
tberghammer added a comment.
This revision is now accepted and ready to land.

Looks good


http://reviews.llvm.org/D19114



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


[Lldb-commits] [PATCH] D19114: [test] Relax stderr expectations on targets with chatty output

2016-04-14 Thread Pavel Labath via lldb-commits
labath created this revision.
labath added reviewers: tfiala, ovyalov.
labath added a subscriber: lldb-commits.
Herald added subscribers: srhines, danalbert, tberghammer.

On some android targets, a binary can produce additional garbage (e.g. warning 
messages from the
dynamic linker) on the standard error, which confuses some tests. This relaxes 
the stderr
expectations for targets known for their chattyness.

http://reviews.llvm.org/D19114

Files:
  packages/Python/lldbsuite/test/lldbplatformutil.py
  packages/Python/lldbsuite/test/settings/TestSettings.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -784,7 +784,7 @@
 regex = line.get("regex", None)
 # Compile the regex.
 if regex and (type(regex) == str):
-regex = re.compile(regex)
+regex = re.compile(regex, re.DOTALL)
 
 regex_mode = line.get("regex_mode", "match")
 capture = line.get("capture", None)
Index: packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -1371,3 +1371,6 @@
 self.assertTrue(state_reached)
 self.assertEqual(step_count, expected_step_count)
 
+def maybe_strict_output_regex(self, regex):
+return '.*'+regex+'.*' if lldbplatformutil.hasChattyStderr(self) else '^'+regex+'$'
+
Index: packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
@@ -232,7 +232,7 @@
 self.add_verified_launch_packets(launch_args)
 self.test_sequence.add_log_lines(
 ["read packet: $vCont;c#a8",
- {"type":"output_match", "regex":r"^hello, world\r\n$" },
+ {"type":"output_match", "regex": self.maybe_strict_output_regex(r"hello, world\r\n")},
  "send packet: $W00#00"],
 True)
 
@@ -868,7 +868,8 @@
  "read packet: $c#63",
  # Match output line that prints the memory address of the message buffer within the inferior. 
  # Note we require launch-only testing so we can get inferior otuput.
- { "type":"output_match", "regex":r"^data address: 0x([0-9a-fA-F]+)\r\n$", "capture":{ 1:"message_address"} },
+ { "type":"output_match", "regex":self.maybe_strict_output_regex(r"data address: 0x([0-9a-fA-F]+)\r\n"),
+   "capture":{ 1:"message_address"} },
  # Now stop the inferior.
  "read packet: {}".format(chr(3)),
  # And wait for the stop notification.
@@ -950,7 +951,8 @@
  "read packet: $c#63",
  # Match output line that prints the memory address of the message buffer within the inferior. 
  # Note we require launch-only testing so we can get inferior otuput.
- { "type":"output_match", "regex":r"^code address: 0x([0-9a-fA-F]+)\r\n$", "capture":{ 1:"code_address"} },
+ { "type":"output_match", "regex":self.maybe_strict_output_regex(r"code address: 0x([0-9a-fA-F]+)\r\n"),
+   "capture":{ 1:"code_address"} },
  # Now stop the inferior.
  "read packet: {}".format(chr(3)),
  # And wait for the stop notification.
@@ -1011,7 +1013,8 @@
  "read packet: $c#63",
  # Match output line that prints the memory address of the message buffer within the inferior. 
  # Note we require launch-only testing so we can get inferior otuput.
- { "type":"output_match", "regex":r"^stack address: 0x([0-9a-fA-F]+)\r\n$", "capture":{ 1:"stack_address"} },
+ { "type":"output_match", "regex":self.maybe_strict_output_regex(r"stack address: 0x([0-9a-fA-F]+)\r\n"),
+   "capture":{ 1:"stack_address"} },
  # Now stop the inferior.
  "read packet: {}".format(chr(3)),
  # And wait for the stop notification.
@@ -1072,7 +1075,8 @@
  "read packet: $c#63",
   

[Lldb-commits] [lldb] r266311 - Fix usage of APInt.getRawData for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:32:01 2016
New Revision: 266311

URL: http://llvm.org/viewvc/llvm-project?rev=266311=rev
Log:
Fix usage of APInt.getRawData for big-endian systems

The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method.  Unfortunately, pretty much all of these places
do not handle big-endian systems correctly.  While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer.  This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.

This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.

This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret.  For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.

The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed.  I've also removed
the Scalar::GetRawBits64 function and its few users.

The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems.  GetData now simply calls GetBytes instead of reimplementing
its contents.

Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer.  I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.

The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines.  Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.

Differential Revision: http://reviews.llvm.org/D18981


Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp

Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266311=266310=266311=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Thu Apr 14 09:32:01 2016
@@ -162,6 +162,9 @@ public:
 bool
 MakeSigned ();
 
+bool
+MakeUnsigned ();
+
 static const char *
 GetValueTypeAsCString (Scalar::Type value_type);
 
@@ -239,22 +242,10 @@ public:
 int
 SInt(int fail_value = 0) const;
 
-// Return the raw unsigned integer without any casting or conversion
-unsigned int
-RawUInt () const;
-
-// Return the raw unsigned long without any casting or conversion
-unsigned long
-RawULong () const;
-
-// Return the raw unsigned long long without any casting or conversion
-unsigned long long
-RawULongLong () const;
-
 unsigned char
 UChar(unsigned char fail_value = 0) const;
 
-char
+signed char
 SChar(char fail_value = 0) const;
 
 unsigned short
@@ -299,9 +290,6 @@ public:
 long double
 LongDouble(long double fail_value = 0.0) const;
 
-uint64_t
-GetRawBits64 (uint64_t fail_value) const;
-
 Error
 SetValueFromCString (const char *s, lldb::Encoding encoding, size_t 
byte_size);
 

Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266311=266310=266311=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Thu Apr 14 09:32:01 2016
@@ -958,13 +958,13 @@ public:
 uint64_t
 GetValueAsUnsigned () const
 {
-return 

Re: [Lldb-commits] [PATCH] D18981: Fix usage of APInt.getRawData for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266311: Fix usage of APInt.getRawData for big-endian systems 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18981?vs=53622=53710#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18981

Files:
  lldb/trunk/include/lldb/Core/Scalar.h
  lldb/trunk/include/lldb/Symbol/Type.h
  lldb/trunk/source/Core/Scalar.cpp
  lldb/trunk/source/Expression/IRInterpreter.cpp
  lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp
  lldb/trunk/unittests/Core/ScalarTest.cpp

Index: lldb/trunk/unittests/Core/ScalarTest.cpp
===
--- lldb/trunk/unittests/Core/ScalarTest.cpp
+++ lldb/trunk/unittests/Core/ScalarTest.cpp
@@ -15,7 +15,10 @@
 
 #include "gtest/gtest.h"
 
+#include "lldb/Core/Error.h"
 #include "lldb/Core/Scalar.h"
+#include "lldb/Core/DataExtractor.h"
+#include "lldb/Host/Endian.h"
 
 using namespace lldb_private;
 
@@ -30,3 +33,49 @@
 ASSERT_EQ(a >> c, a_scalar >> c_scalar);
 ASSERT_EQ(b >> c, b_scalar >> c_scalar);
 }
+
+TEST(ScalarTest, GetBytes)
+{
+int a = 0x01020304;
+long long b = 0x0102030405060708LL;
+float c = 1234567.89e42;
+double d = 1234567.89e42;
+char e[16] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
+char f[32] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
+   17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 };
+Scalar a_scalar(a);
+Scalar b_scalar(b);
+Scalar c_scalar(c);
+Scalar d_scalar(d);
+Scalar e_scalar;
+Scalar f_scalar;
+DataExtractor e_data(e, sizeof(e), endian::InlHostByteOrder(), sizeof(void *));
+Error e_error = e_scalar.SetValueFromData(e_data, lldb::eEncodingUint, sizeof(e));
+DataExtractor f_data(f, sizeof(f), endian::InlHostByteOrder(), sizeof(void *));
+Error f_error = f_scalar.SetValueFromData(f_data, lldb::eEncodingUint, sizeof(f));
+ASSERT_EQ(0, memcmp(, a_scalar.GetBytes(), sizeof(a)));
+ASSERT_EQ(0, memcmp(, b_scalar.GetBytes(), sizeof(b)));
+ASSERT_EQ(0, memcmp(, c_scalar.GetBytes(), sizeof(c)));
+ASSERT_EQ(0, memcmp(, d_scalar.GetBytes(), sizeof(d)));
+ASSERT_EQ(0, e_error.Fail());
+ASSERT_EQ(0, memcmp(e, e_scalar.GetBytes(), sizeof(e)));
+ASSERT_EQ(0, f_error.Fail());
+ASSERT_EQ(0, memcmp(f, f_scalar.GetBytes(), sizeof(f)));
+}
+
+TEST(ScalarTest, CastOperations)
+{
+long long a = 0xf1f2f3f4f5f6f7f8LL;
+Scalar a_scalar(a);
+ASSERT_EQ((signed char)a, a_scalar.SChar());
+ASSERT_EQ((unsigned char)a, a_scalar.UChar());
+ASSERT_EQ((signed short)a, a_scalar.SShort());
+ASSERT_EQ((unsigned short)a, a_scalar.UShort());
+ASSERT_EQ((signed int)a, a_scalar.SInt());
+ASSERT_EQ((unsigned int)a, a_scalar.UInt());
+ASSERT_EQ((signed long)a, a_scalar.SLong());
+ASSERT_EQ((unsigned long)a, a_scalar.ULong());
+ASSERT_EQ((signed long long)a, a_scalar.SLongLong());
+ASSERT_EQ((unsigned long long)a, a_scalar.ULongLong());
+}
+
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -72,6 +72,7 @@
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/RegularExpression.h"
+#include "lldb/Core/Scalar.h"
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/ThreadSafeDenseMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
@@ -8645,18 +8646,10 @@
 const uint64_t byte_size = bit_size / 8;
 if (dst_size >= byte_size)
 {
-if (bit_size == sizeof(float)*8)
-{
-float float32 = ap_float.convertToFloat();
-::memcpy (dst, , byte_size);
+Scalar scalar = ap_float.bitcastToAPInt().zextOrTrunc(llvm::NextPowerOf2(byte_size) * 8);
+lldb_private::Error get_data_error;
+if (scalar.GetAsMemoryData(dst, byte_size, lldb_private::endian::InlHostByteOrder(), get_data_error))
 return byte_size;
-}
-else if (bit_size >= 64)
-{
-llvm::APInt ap_int(ap_float.bitcastToAPInt());
-::memcpy (dst, ap_int.getRawData(), byte_size);
-return byte_size;
-}
 }
 }
 }
Index: lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
===
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
@@ -1105,7 +1105,13 @@
 
 if (ConstantInt *int_initializer = dyn_cast(initializer))
 {
-memcpy (data, 

Re: [Lldb-commits] [PATCH] D18973: Find .plt section in object files generated by recent ld

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266316: Find .plt section in object files generated by 
recent ld (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18973?vs=53288=53715#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18973

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

Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table 
then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;


Index: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2611,17 +2611,17 @@
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r266316 - Find .plt section in object files generated by recent ld

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:36:29 2016
New Revision: 266316

URL: http://llvm.org/viewvc/llvm-project?rev=266316=rev
Log:
Find .plt section in object files generated by recent ld

Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However, with recent GNU ld this is no longer true.  As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).

This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.

This patch changes LLDB to simply always look for the .plt section by
name.  This should be safe across all linkers and targets.

Differential Revision: http://reviews.llvm.org/D18973


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=266316=266315=266316=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Thu Apr 14 
09:36:29 2016
@@ -2611,17 +2611,17 @@ ObjectFileELF::ParseTrampolineSymbols(Sy
 {
 assert(rel_hdr->sh_type == SHT_RELA || rel_hdr->sh_type == SHT_REL);
 
-// The link field points to the associated symbol table. The info field
-// points to the section holding the plt.
+// The link field points to the associated symbol table.
 user_id_t symtab_id = rel_hdr->sh_link;
-user_id_t plt_id = rel_hdr->sh_info;
 
 // If the link field doesn't point to the appropriate symbol name table 
then
 // try to find it by name as some compiler don't fill in the link fields.
 if (!symtab_id)
 symtab_id = GetSectionIndexByName(".dynsym");
-if (!plt_id)
-plt_id = GetSectionIndexByName(".plt");
+
+// Get PLT section.  We cannot use rel_hdr->sh_info, since current linkers
+// point that to the .got.plt or .got section instead of .plt.
+user_id_t plt_id = GetSectionIndexByName(".plt");
 
 if (!symtab_id || !plt_id)
 return 0;


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


Re: [Lldb-commits] [PATCH] D18985: Fix test cases for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266315: Fix test cases for big-endian systems (authored by 
uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18985?vs=53501=53714#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18985

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/main.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
  lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
@@ -186,7 +186,10 @@
 
 self.assertTrue(new_object.GetValue() == "1", 'new_object == 1')
 
-data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
+if data.GetByteOrder() == lldb.eByteOrderBig:
+data.SetData(error, '\0\0\0A', data.GetByteOrder(), data.GetAddressByteSize())
+else:
+data.SetData(error, 'A\0\0\0', data.GetByteOrder(), data.GetAddressByteSize())
 self.assertTrue(error.Success())
 
 data2 = lldb.SBData()
@@ -311,8 +314,8 @@
 self.assert_data(data2.GetSignedInt32, 4, -2)
 
 data2.SetDataFromSInt64Array([2, -2])
-self.assert_data(data2.GetSignedInt32, 0, 2)
-self.assert_data(data2.GetSignedInt32, 8, -2)
+self.assert_data(data2.GetSignedInt64, 0, 2)
+self.assert_data(data2.GetSignedInt64, 8, -2)
 
 data2.SetDataFromUInt32Array([1,2,3,4,5])
 self.assert_data(data2.GetUnsignedInt32, 0, 1)
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
@@ -232,6 +232,7 @@
 
 # The bytearray_to_int utility function expects a little endian bytearray.
 if byteOrder == lldb.eByteOrderBig:
+content = bytearray(content, 'ascii')
 content.reverse()
 
 new_value = bytearray_to_int(content, byteSize)
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
@@ -19,7 +19,13 @@
 
 self.runCmd("process launch", RUN_SUCCEEDED)
 
-self.expect('frame variable -f x i', substrs=['ff41'])
+process = self.dbg.GetSelectedTarget().GetProcess()
+
+if process.GetByteOrder() == lldb.eByteOrderLittle:
+self.expect('frame variable -f x i', substrs=['ff41'])
+else:
+self.expect('frame variable -f x i', substrs=['4100'])
+
 self.expect('frame variable c', substrs=["'A"])
 
 self.expect('frame variable x', matching=False, substrs=['3'])
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -387,7 +387,10 @@
 return retval
 
 elif endian == 'big':
-retval = value.encode("hex")
+retval = ""
+while value != 0:
+retval = "{:02x}".format(value & 0xff) + retval
+value = value >> 8
 if byte_size:
 # Add zero-fill to the left/front (MSB side) of the value.
 retval = ("00" * (byte_size - len(retval)/2)) + retval
Index: 

[Lldb-commits] [lldb] r266315 - Fix test cases for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:35:02 2016
New Revision: 266315

URL: http://llvm.org/viewvc/llvm-project?rev=266315=rev
Log:
Fix test cases for big-endian systems

A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.

These two test cases:
  tools/lldb-server/lldbgdbserverutils.py
  python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.

These test cases:
  
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
  
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
  functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
  lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
  python_api/sbdata/TestSBData.py  (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly.  For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.

These test case:
  python_api/sbdata/TestSBData.py  (second change)
  functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.

Differential Revision: http://reviews.llvm.org/D18985


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/TestSyntheticCapping.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/synthcapping/main.cpp

lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/cache/TestMemoryCache.py

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py

lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
lldb/trunk/packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py?rev=266315=266314=266315=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
 Thu Apr 14 09:35:02 2016
@@ -44,6 +44,8 @@ class PythonSynthDataFormatterTestCase(T
 
 self.runCmd("run", RUN_SUCCEEDED)
 
+process = self.dbg.GetSelectedTarget().GetProcess()
+
 # The stop reason of the thread should be breakpoint.
 self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
 substrs = ['stopped',
@@ -62,40 +64,46 @@ class PythonSynthDataFormatterTestCase(T
 
 # print the f00_1 variable without a synth
 self.expect("frame variable f00_1",
-substrs = ['a = 0',
-   'b = 1',
-   'r = 33']);
+substrs = ['a = 1',
+   'b = 2',
+   'r = 34']);
 
 # now set up the synth
 self.runCmd("script from fooSynthProvider import *")
 self.runCmd("type synth add -l fooSynthProvider foo")
 self.expect("type synthetic list foo", substrs=['fooSynthProvider'])
 
+# note that the value of fake_a depends on target byte order
+if process.GetByteOrder() == lldb.eByteOrderLittle:
+fake_a_val = 0x0200
+else:
+fake_a_val = 0x0100
+
 # check that we get the two real vars and the fake_a variables
 self.expect("frame variable f00_1",
-substrs = ['r = 33',
-   'fake_a = 16777216',
-   'a = 0']);
+substrs = ['r = 34',
+   'fake_a = %d' % fake_a_val,
+   'a = 1']);
 
 # check that we do not get the extra vars
 self.expect("frame variable f00_1", matching=False,
-substrs = ['b = 1']);
+

Re: [Lldb-commits] [PATCH] D18984: Fix ARM instruction emulation tests on big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266314: Fix ARM instruction emulation tests on big-endian 
systems (authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18984?vs=53500=53713#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18984

Files:
  lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
  lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
  lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h

Index: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
===
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h
@@ -30,10 +30,10 @@
 ReadPseudoRegisterValue (uint32_t reg_num, bool );
 
 bool
-StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size);
+StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value);
 
 uint32_t
-ReadFromPseudoAddress (lldb::addr_t p_address, uint32_t size, bool );
+ReadFromPseudoAddress (lldb::addr_t p_address, bool );
 
 void
 ClearPseudoRegisters ();
@@ -82,11 +82,7 @@
 uint32_t m_gpr[17];
 struct _sd_regs
 {
-union 
-{
-uint32_t s_reg[2];
-uint64_t d_reg;
-} sd_regs[16];  // sregs 0 - 31 & dregs 0 - 15
+uint32_t s_regs[32]; // sregs 0 - 31 & dregs 0 - 15
 
 uint64_t d_regs[16]; // dregs 16-31
  
Index: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
===
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
@@ -61,11 +61,15 @@
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-value = m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2];
+value = m_vfp_regs.d_regs[idx];
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
-value = m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg;
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
+value = (uint64_t)m_vfp_regs.s_regs[idx * 2] | ((uint64_t)m_vfp_regs.s_regs[idx * 2 + 1] >> 32);
 else
-value = m_vfp_regs.d_regs[reg_num - dwarf_d16];
+value = m_vfp_regs.d_regs[idx - 16];
 }
 else
 success = false;
@@ -131,8 +138,8 @@
 for (int i = 0; i < 17; ++i)
 m_gpr[i] = 0;
 
-for (int i = 0; i < 16; ++i)
-m_vfp_regs.sd_regs[i].d_reg = 0;
+for (int i = 0; i < 32; ++i)
+m_vfp_regs.s_regs[i] = 0;
 
 for (int i = 0; i < 16; ++i)
 m_vfp_regs.d_regs[i] = 0;
@@ -145,23 +152,14 @@
 }
 
 bool
-EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint64_t value, uint32_t size)
+EmulationStateARM::StoreToPseudoAddress (lldb::addr_t p_address, uint32_t value)
 {
-if (size > 8)
-return false;
-
-if (size <= 4)
-m_memory[p_address] = value;
-else if (size == 8)
-{
-m_memory[p_address] = (value << 32) >> 32;
-m_memory[p_address + 4] = value << 32;
-}
+m_memory[p_address] = value;
 return true;
 }
 
 uint32_t
-EmulationStateARM::ReadFromPseudoAddress (lldb::addr_t 

[Lldb-commits] [lldb] r266314 - Fix ARM instruction emulation tests on big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:34:19 2016
New Revision: 266314

URL: http://llvm.org/viewvc/llvm-project?rev=266314=rev
Log:
Fix ARM instruction emulation tests on big-endian systems

Running the ARM instruction emulation test on a big-endian system
would fail, since the code doesn't respect endianness properly.

In EmulateInstructionARM::TestEmulation, code assumes that an
instruction opcode read in from the test file is in target byte
order, but it was in fact read in in host byte order.

More difficult to fix, the EmulationStateARM structure models
the overlapping sregs and dregs by a union in _sd_regs.  This
only works correctly if the host is a little-endian system.
I've removed the union in favor of a simple array containing
the 32 sregs, and changed any code accessing dregs to explicitly
use the correct two sregs overlaying that dreg in the proper
target order.

Also, the EmulationStateARM::ReadPseudoMemory and WritePseudoMemory
track memory as a map of uint32_t values in host byte order, and
implement 64-bit memory accessing by splitting them up into two
uint32_t ones.  However, callers expect memory contents to be
provided in the form of a byte array (in target byte order).
This means the uint32_t contents need to be byte-swapped on
BE systems, and when splitting up a 64-bit access into two 32-bit
ones, byte order has to be respected.

Differential Revision: http://reviews.llvm.org/D18984


Modified:
lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.h

Modified: lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp?rev=266314=266313=266314=diff
==
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp 
(original)
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulateInstructionARM.cpp Thu Apr 
14 09:34:19 2016
@@ -13683,14 +13683,14 @@ EmulateInstructionARM::TestEmulation (St
 {
 m_opcode_mode = eModeThumb;
 if (test_opcode < 0x1)
-m_opcode.SetOpcode16 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode16 (test_opcode, endian::InlHostByteOrder());
 else
-m_opcode.SetOpcode32 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode32 (test_opcode, endian::InlHostByteOrder());
 }
 else if (arch.GetTriple().getArch() == llvm::Triple::arm)
 {
 m_opcode_mode = eModeARM;
-m_opcode.SetOpcode32 (test_opcode, GetByteOrder());
+m_opcode.SetOpcode32 (test_opcode, endian::InlHostByteOrder());
 }
 else
 {

Modified: lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp?rev=266314=266313=266314=diff
==
--- lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp (original)
+++ lldb/trunk/source/Plugins/Instruction/ARM/EmulationStateARM.cpp Thu Apr 14 
09:34:19 2016
@@ -61,11 +61,15 @@ EmulationStateARM::LoadPseudoRegistersFr
 
 if (reg_ctx->ReadRegister (reg_info, reg_value))
 {
+uint64_t value = reg_value.GetAsUInt64();
 uint32_t idx = i - dwarf_d0;
 if (i < 16)
-m_vfp_regs.sd_regs[idx].d_reg = reg_value.GetAsUInt64();
+{
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
+}
 else
-m_vfp_regs.d_regs[idx - 16] = reg_value.GetAsUInt64();
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 success = false;
@@ -82,16 +86,18 @@ EmulationStateARM::StorePseudoRegisterVa
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
 uint32_t idx = reg_num - dwarf_s0;
-m_vfp_regs.sd_regs[idx / 2].s_reg[idx % 2] = (uint32_t) value;
+m_vfp_regs.s_regs[idx] = (uint32_t)value;
 }
 else if ((dwarf_d0 <= reg_num) && (reg_num <= dwarf_d31))
 {
-if ((reg_num - dwarf_d0) < 16)
+uint32_t idx = reg_num - dwarf_d0;
+if (idx < 16)
 {
-m_vfp_regs.sd_regs[reg_num - dwarf_d0].d_reg = value;
+m_vfp_regs.s_regs[idx * 2] = (uint32_t)value;
+m_vfp_regs.s_regs[idx * 2 + 1] = (uint32_t)(value >> 32);
 }
 else
-m_vfp_regs.d_regs[reg_num - dwarf_d16] = value;
+m_vfp_regs.d_regs[idx - 16] = value;
 }
 else
 return false;
@@ -110,14 +116,15 @@ EmulationStateARM::ReadPseudoRegisterVal
 else if ((dwarf_s0 <= reg_num) && (reg_num <= dwarf_s31))
 {
  

Re: [Lldb-commits] [PATCH] D18983: Miscellaneous fixes for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266313: Miscellaneous fixes for big-endian systems (authored 
by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18983?vs=53299=53712#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18983

Files:
  lldb/trunk/examples/synthetic/gnu_libstdcpp.py
  lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
  lldb/trunk/source/Symbol/ClangASTContext.cpp
  lldb/trunk/source/Target/Process.cpp

Index: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
===
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py
@@ -237,11 +237,12 @@
def get_child_at_index(self, index):
if index >= self.num_children():
return None
-   byte_offset = index / 8
-   bit_offset = index % 8
-   element_size = 
self.start_p.GetType().GetPointeeType().GetByteSize()
-   data = self.start_p.GetPointeeData(byte_offset / 
element_size)
-   bit = data.GetUnsignedInt8(lldb.SBError(), byte_offset 
% element_size) & (1 << bit_offset)
+   element_type = self.start_p.GetType().GetPointeeType()
+   element_bits = 8 * element_type.GetByteSize()
+   element_offset = index / element_bits
+   bit_offset = index % element_bits
+   element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
+   bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)
if bit != 0:
value_expr = "(bool)true"
else:
Index: lldb/trunk/source/Target/Process.cpp
===
--- lldb/trunk/source/Target/Process.cpp
+++ lldb/trunk/source/Target/Process.cpp
@@ -2437,7 +2437,7 @@
 // Search for a null terminator of correct size and alignment in 
bytes_read
 size_t aligned_start = total_bytes_read - total_bytes_read % 
type_width;
 for (size_t i = aligned_start; i + type_width <= total_bytes_read 
+ bytes_read; i += type_width)
-if (::strncmp([i], terminator, type_width) == 0)
+if (::memcmp([i], terminator, type_width) == 0)
 {
 error.Clear();
 return i;
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -6075,8 +6075,9 @@
 {
 clang::CharUnits 
base_offset_offset = 
itanium_vtable_ctx->getVirtualBaseOffsetOffset(cxx_record_decl, 
base_class_decl);
 const lldb::addr_t 
base_offset_addr = vtable_ptr + base_offset_offset.getQuantity();
-const uint32_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 4, 
UINT32_MAX, err);
-if (base_offset != 
UINT32_MAX)
+const uint32_t 
base_offset_size = process->GetAddressByteSize();
+const uint64_t 
base_offset = process->ReadUnsignedIntegerFromMemory(base_offset_addr, 
base_offset_size, UINT32_MAX, err);
+if (base_offset < 
UINT32_MAX)
 {
 handled = true;
 bit_offset = 
base_offset * 8;
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
@@ -192,13 +192,33 @@
 if (error.Fail())
 return false;
 
+// Get a wchar_t basic type from the current type system
+CompilerType wchar_compiler_type = 
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
+
+if (!wchar_compiler_type)
+return false;
+
+const uint32_t wchar_size = wchar_compiler_type.GetBitSize(nullptr); // 
Safe to pass NULL for exe_scope here
+
 StringPrinter::ReadBufferAndDumpToStreamOptions options(valobj);
 options.SetData(data);
 options.SetStream();
 

[Lldb-commits] [lldb] r266313 - Miscellaneous fixes for big-endian systems

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:33:47 2016
New Revision: 266313

URL: http://llvm.org/viewvc/llvm-project?rev=266313=rev
Log:
Miscellaneous fixes for big-endian systems

This patch fixes a bunch of issues that show up on big-endian systems:

- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
  bit vectors: it should identify the enclosing *word* and then access
  the appropriate bit within that word.  Instead, the script simply
  operates on bytes.  This gives the same result on little-endian
  systems, but not on big-endian.

- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
  is UTF16, even though it could also be UTF8 or UTF32.  This is mostly
  not an issue on little-endian systems, but immediately fails on BE.
  Fixed by checking the size of wchar_t like WCharStringSummaryProvider
  already does.

- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
  the virtual base offset stored in the vtable, even though the size
  of this field matches the target pointer size according to the C++
  ABI.  Again, this is mostly not visible on LE, but fails on BE.

- Process::ReadStringFromMemory uses strncmp to search for a terminator
  consisting of multiple zero bytes.  This doesn't work since strncmp
  will stop already at the first zero byte.  Use memcmp instead.

Differential Revision: http://reviews.llvm.org/D18983


Modified:
lldb/trunk/examples/synthetic/gnu_libstdcpp.py
lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/examples/synthetic/gnu_libstdcpp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/synthetic/gnu_libstdcpp.py?rev=266313=266312=266313=diff
==
--- lldb/trunk/examples/synthetic/gnu_libstdcpp.py (original)
+++ lldb/trunk/examples/synthetic/gnu_libstdcpp.py Thu Apr 14 09:33:47 2016
@@ -237,11 +237,12 @@ class StdVectorSynthProvider:
def get_child_at_index(self, index):
if index >= self.num_children():
return None
-   byte_offset = index / 8
-   bit_offset = index % 8
-   element_size = 
self.start_p.GetType().GetPointeeType().GetByteSize()
-   data = self.start_p.GetPointeeData(byte_offset / 
element_size)
-   bit = data.GetUnsignedInt8(lldb.SBError(), byte_offset 
% element_size) & (1 << bit_offset)
+   element_type = self.start_p.GetType().GetPointeeType()
+   element_bits = 8 * element_type.GetByteSize()
+   element_offset = index / element_bits
+   bit_offset = index % element_bits
+   element = 
self.start_p.CreateChildAtOffset('['+str(index)+']',element_offset,element_type)
+   bit = element.GetValueAsUnsigned(0) & (1 << bit_offset)
if bit != 0:
value_expr = "(bool)true"
else:

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp?rev=266313=266312=266313=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CxxStringTypes.cpp Thu Apr 14 
09:33:47 2016
@@ -192,6 +192,14 @@ lldb_private::formatters::WCharSummaryPr
 if (error.Fail())
 return false;
 
+// Get a wchar_t basic type from the current type system
+CompilerType wchar_compiler_type = 
valobj.GetCompilerType().GetBasicTypeFromAST(lldb::eBasicTypeWChar);
+
+if (!wchar_compiler_type)
+return false;
+
+const uint32_t wchar_size = wchar_compiler_type.GetBitSize(nullptr); // 
Safe to pass NULL for exe_scope here
+
 StringPrinter::ReadBufferAndDumpToStreamOptions options(valobj);
 options.SetData(data);
 options.SetStream();
@@ -200,5 +208,17 @@ lldb_private::formatters::WCharSummaryPr
 options.SetSourceSize(1);
 options.SetBinaryZeroIsTerminator(false);
 
-return 
StringPrinter::ReadBufferAndDumpToStream(options);
+switch (wchar_size)
+{
+case 8:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 16:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+case 32:
+return 
StringPrinter::ReadBufferAndDumpToStream(options);
+default:
+stream.Printf("size for wchar_t is not valid");
+return true;
+}
+return true;
 }

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

Re: [Lldb-commits] [PATCH] D18982: Handle bit fields on big-endian systems correctly

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266312: Handle bit fields on big-endian systems correctly 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18982?vs=53605=53711#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18982

Files:
  lldb/trunk/include/lldb/Core/DataExtractor.h
  lldb/trunk/source/Core/DataExtractor.cpp
  lldb/trunk/source/Core/ValueObject.cpp
  lldb/trunk/unittests/Core/CMakeLists.txt
  lldb/trunk/unittests/Core/DataExtractorTest.cpp

Index: lldb/trunk/include/lldb/Core/DataExtractor.h
===
--- lldb/trunk/include/lldb/Core/DataExtractor.h
+++ lldb/trunk/include/lldb/Core/DataExtractor.h
@@ -763,8 +763,10 @@
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The unsigned bitfield integer value that was extracted, or
@@ -805,8 +807,10 @@
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The signed bitfield integer value that was extracted, or
Index: lldb/trunk/unittests/Core/DataExtractorTest.cpp
===
--- lldb/trunk/unittests/Core/DataExtractorTest.cpp
+++ lldb/trunk/unittests/Core/DataExtractorTest.cpp
@@ -0,0 +1,39 @@
+//===-- DataExtractorTest.cpp ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#if defined(_MSC_VER) && (_HAS_EXCEPTIONS == 0)
+// Workaround for MSVC standard library bug, which fails to include  when
+// exceptions are disabled.
+#include 
+#endif
+
+#include "gtest/gtest.h"
+
+#include "lldb/Core/DataExtractor.h"
+
+using namespace lldb_private;
+
+TEST(DataExtractorTest, GetBitfield)
+{
+char buffer[] = { 0x01, 0x23, 0x45, 0x67 };
+DataExtractor LE(buffer, sizeof(buffer), lldb::eByteOrderLittle, sizeof(void *));
+DataExtractor BE(buffer, sizeof(buffer), lldb::eByteOrderBig, sizeof(void *));
+
+lldb::offset_t offset;
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxU64Bitfield(, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxU64Bitfield(, sizeof(buffer), 8, 8));
+
+offset = 0;
+ASSERT_EQ(buffer[1], LE.GetMaxS64Bitfield(, sizeof(buffer), 8, 8));
+offset = 0;
+ASSERT_EQ(buffer[1], BE.GetMaxS64Bitfield(, sizeof(buffer), 8, 8));
+}
Index: lldb/trunk/unittests/Core/CMakeLists.txt
===
--- lldb/trunk/unittests/Core/CMakeLists.txt
+++ lldb/trunk/unittests/Core/CMakeLists.txt
@@ -1,3 +1,4 @@
 add_lldb_unittest(LLDBCoreTests
+  DataExtractorTest.cpp
   ScalarTest.cpp
   )
Index: lldb/trunk/source/Core/ValueObject.cpp
===
--- lldb/trunk/source/Core/ValueObject.cpp
+++ lldb/trunk/source/Core/ValueObject.cpp
@@ -2146,15 +2146,19 @@
 synthetic_child_sp = GetSyntheticChild (index_const_str);
 if (!synthetic_child_sp)
 {
+uint32_t bit_field_size = to - from + 1;
+uint32_t bit_field_offset = from;
+if (GetDataExtractor().GetByteOrder() == eByteOrderBig)
+bit_field_offset = GetByteSize() * 8 - bit_field_size - bit_field_offset;
 // We haven't made a synthetic array member for INDEX yet, so
 // lets make one and cache it for any future reference.
 ValueObjectChild *synthetic_child = new ValueObjectChild (*this,
   GetCompilerType(),
   index_const_str,
   GetByteSize(),
   0,
-  to-from+1,
-  

[Lldb-commits] [lldb] r266312 - Handle bit fields on big-endian systems correctly

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:32:57 2016
New Revision: 266312

URL: http://llvm.org/viewvc/llvm-project?rev=266312=rev
Log:
Handle bit fields on big-endian systems correctly

Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.

On many big-endian systems, however, the big-endian bit numbering
is used for bit fields.  Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.

Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use.  However, there are two problems with
the current approach:

- When parsing DWARF, LLDB decodes bit offsets in little-endian
  bit numbering on LE systems, but in big-endian bit numbering
  on BE systems.  Passing those offsets later on into the
  DataExtractor routines gives incorrect results on BE.

- In the interim, LLDB's type layer combines byte and bit offsets
  into a single number.  I.e. instead of recording bitfields by
  specifying the byte offset and byte size of the surrounding
  integer *plus* the bit offset of the bit field within that field,
  it simply records a single bit offset number.

  Now, note that converting from byte offset + bit offset to a
  single offset value and back is well-defined if we either use
  little-endian byte order *and* little-endian bit numbering,
  or use big-endian byte order *and* big-endian bit numbering.
  Any other combination will yield incorrect results.

Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order.  This makes
storing a single bit offset valid, and makes the existing DWARF
code correct.  The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.

However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields.  While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering.  Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.

Differential Revision: http://reviews.llvm.org/D18982


Added:
lldb/trunk/unittests/Core/DataExtractorTest.cpp
Modified:
lldb/trunk/include/lldb/Core/DataExtractor.h
lldb/trunk/source/Core/DataExtractor.cpp
lldb/trunk/source/Core/ValueObject.cpp
lldb/trunk/unittests/Core/CMakeLists.txt

Modified: lldb/trunk/include/lldb/Core/DataExtractor.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/DataExtractor.h?rev=266312=266311=266312=diff
==
--- lldb/trunk/include/lldb/Core/DataExtractor.h (original)
+++ lldb/trunk/include/lldb/Core/DataExtractor.h Thu Apr 14 09:32:57 2016
@@ -763,8 +763,10 @@ public:
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The unsigned bitfield integer value that was extracted, or
@@ -805,8 +807,10 @@ public:
 ///
 /// @param[in] bitfield_bit_offset
 /// The bit offset of the bitfield value in the extracted
-/// integer (the number of bits to shift the integer to the
-/// right).
+/// integer.  For little-endian data, this is the offset of
+/// the LSB of the bitfield from the LSB of the integer.
+/// For big-endian data, this is the offset of the MSB of the
+/// bitfield from the MSB of the integer.
 ///
 /// @return
 /// The signed bitfield integer value that was extracted, or

Modified: lldb/trunk/source/Core/DataExtractor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DataExtractor.cpp?rev=266312=266311=266312=diff
==
--- lldb/trunk/source/Core/DataExtractor.cpp (original)
+++ lldb/trunk/source/Core/DataExtractor.cpp Thu Apr 14 09:32:57 2016
@@ -733,8 +733,11 @@ DataExtractor::GetMaxU64Bitfield (offset
 uint64_t uval64 = GetMaxU64 (offset_ptr, size);
 if (bitfield_bit_size > 0)
 {
-if (bitfield_bit_offset > 0)
-uval64 >>= bitfield_bit_offset;
+int32_t lsbcount = 

Re: [Lldb-commits] [PATCH] D18979: Fixes for platforms that default to unsigned char

2016-04-14 Thread Ulrich Weigand via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266309: Fixes for platforms that default to unsigned char 
(authored by uweigand).

Changed prior to commit:
  http://reviews.llvm.org/D18979?vs=53294=53708#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D18979

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
  lldb/trunk/source/Symbol/ClangASTContext.cpp

Index: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57,7 @@
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], 
bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})
Index: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))


Index: lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
+++ lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
@@ -57,7 +57,7 @@
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 //===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -783,8 +783,8 @@
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org

[Lldb-commits] [lldb] r266309 - Fixes for platforms that default to unsigned char

2016-04-14 Thread Ulrich Weigand via lldb-commits
Author: uweigand
Date: Thu Apr 14 09:30:12 2016
New Revision: 266309

URL: http://llvm.org/viewvc/llvm-project?rev=266309=rev
Log:
Fixes for platforms that default to unsigned char

This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.

- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
  an explicit *signed* char type for encoding eEncodingSint and bit size 8,
  instead of the default platform char type (which may be unsigned).
  This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
  and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
  unit test case.

- The test/expression_command/char/TestExprsChar.py test case is known to
  fail on platforms defaulting to unsigned char (pr23069), and just needs
  to be xfailed on s390x like on arm.

- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
  case defines a vector of "char" and implicitly assumes to be signed.
  Use an explicit "signed char" instead.

Differential Revision: http://reviews.llvm.org/D18979


Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py?rev=266309=266308=266309=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/char/TestExprsChar.py
 Thu Apr 14 09:30:12 2016
@@ -57,7 +57,7 @@ class ExprCharTestCase(TestBase):
 def test_default_char(self):
 self.do_test()
 
-@expectedFailureAll(archs=["arm", "aarch64"], bugnumber="llvm.org/pr23069")
+@expectedFailureAll(archs=["arm", "aarch64", "s390x"], 
bugnumber="llvm.org/pr23069")
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr21765")
 def test_signed_char(self):
 self.do_test(dictionary={'CFLAGS_EXTRAS': '-fsigned-char'})

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c?rev=266309=266308=266309=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_on_vectors/main.c
 Thu Apr 14 09:30:12 2016
@@ -6,7 +6,7 @@
 // License. See LICENSE.TXT for details.
 //
 
//===--===//
-typedef char v4i8 __attribute__ ((vector_size(4)));
+typedef signed char v4i8 __attribute__ ((vector_size(4)));
 v4i8 global_vector = {1, 2, 3, 4};
 
 int

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=266309=266308=266309=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Thu Apr 14 09:30:12 2016
@@ -783,8 +783,8 @@ ClangASTContext::GetBuiltinTypeForEncodi
 break;
 
 case eEncodingSint:
-if (QualTypeMatchesBitSize (bit_size, ast, ast->CharTy))
-return CompilerType (ast, ast->CharTy);
+if (QualTypeMatchesBitSize (bit_size, ast, ast->SignedCharTy))
+return CompilerType (ast, ast->SignedCharTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->ShortTy))
 return CompilerType (ast, ast->ShortTy);
 if (QualTypeMatchesBitSize (bit_size, ast, ast->IntTy))


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


Re: [Lldb-commits] [PATCH] D19052: Make destructor breakpoint location test more resilient

2016-04-14 Thread Pavel Labath via lldb-commits
labath updated this revision to Diff 53694.
labath added a comment.

One more tweak to make the test work on linux clang: I've needed to move the 
constructors out-of-line to make sure the compiler generates the expected 
symbols.


http://reviews.llvm.org/D19052

Files:
  
packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
  packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp

Index: packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
@@ -12,8 +12,8 @@
 namespace a {
 class c {
 public:
-c () {}
-~c() {}
+c();
+~c();
 void func1() 
 {
 puts (__PRETTY_FUNCTION__);
@@ -27,13 +27,16 @@
 puts (__PRETTY_FUNCTION__);
 }
 };
+
+c::c() {}
+c::~c() {}
 }
 
 namespace b {
 class c {
 public:
-c () {}
-~c() {}
+c();
+~c();
 void func1() 
 {
 puts (__PRETTY_FUNCTION__);
@@ -43,6 +46,9 @@
 puts (__PRETTY_FUNCTION__);
 }
 };
+
+c::c() {}
+c::~c() {}
 }
 
 namespace c {
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
@@ -26,7 +26,7 @@
 name = bp_dict['name']
 names = bp_dict['loc_names']
 bp = target.BreakpointCreateByName (name)
-self.assertTrue (bp.GetNumLocations() <= len(names), "Make sure we find the right number of breakpoint locations")
+self.assertEquals(bp.GetNumLocations(), len(names), "Make sure we find the right number of breakpoint locations")
 
 bp_loc_names = list()
 for bp_loc in bp:
@@ -48,19 +48,48 @@
 { 'name' : 'func1', 'loc_names' : [ 'a::c::func1()', 'b::c::func1()'] },
 { 'name' : 'func2', 'loc_names' : [ 'a::c::func2()', 'c::d::func2()'] },
 { 'name' : 'func3', 'loc_names' : [ 'a::c::func3()', 'b::c::func3()', 'c::d::func3()'] },
-{ 'name' : '~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
 { 'name' : 'c::func1', 'loc_names' : [ 'a::c::func1()', 'b::c::func1()'] },
 { 'name' : 'c::func2', 'loc_names' : [ 'a::c::func2()'] },
 { 'name' : 'c::func3', 'loc_names' : [ 'a::c::func3()', 'b::c::func3()'] },
-{ 'name' : 'c::~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
 { 'name' : 'a::c::func1', 'loc_names' : [ 'a::c::func1()'] },
 { 'name' : 'b::c::func1', 'loc_names' : [ 'b::c::func1()'] },
 { 'name' : 'c::d::func2', 'loc_names' : [ 'c::d::func2()'] },
 { 'name' : 'a::c::func1()', 'loc_names' : [ 'a::c::func1()'] },
 { 'name' : 'b::c::func1()', 'loc_names' : [ 'b::c::func1()'] },
 { 'name' : 'c::d::func2()', 'loc_names' : [ 'c::d::func2()'] },
-{ 'name' : 'c::~c()', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
 ]
 
 for bp_dict in bp_dicts:
 self.verify_breakpoint_locations(target, bp_dict)
+
+@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24764")
+def test_destructors(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+target = self.dbg.CreateTarget(exe)
+
+# Don't skip prologue, so we can check the breakpoint address more easily
+self.runCmd("settings set target.skip-prologue false")
+try:
+names = ['~c', 'c::~c', 'c::~c()']
+loc_names = {'a::c::~c()', 'b::c::~c()'}
+# TODO: For windows targets we should put windows mangled names here
+symbols = ['_ZN1a1cD1Ev', '_ZN1a1cD2Ev', '_ZN1b1cD1Ev', '_ZN1b1cD2Ev']
+
+for name in names:
+bp = target.BreakpointCreateByName(name)
+
+bp_loc_names = { bp_loc.GetAddress().GetFunction().GetName() for bp_loc in bp }
+self.assertEquals(bp_loc_names, loc_names, "Breakpoint set on the correct symbol")
+
+bp_addresses = { bp_loc.GetLoadAddress() for bp_loc in bp }
+symbol_addresses = set()
+for symbol in symbols:
+sc_list = target.FindSymbols(symbol, lldb.eSymbolTypeCode)
+self.assertEquals(sc_list.GetSize(), 1, "Found symbol " + symbol)
+symbol = sc_list.GetContextAtIndex(0).GetSymbol()
+

[Lldb-commits] [lldb] r266286 - FileSpec: make matching separator-agnostic again

2016-04-14 Thread Pavel Labath via lldb-commits
Author: labath
Date: Thu Apr 14 04:38:06 2016
New Revision: 266286

URL: http://llvm.org/viewvc/llvm-project?rev=266286=rev
Log:
FileSpec: make matching separator-agnostic again

Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it 
no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes 
a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This 
turned out to be a
problem because we would consider paths with different separators as different 
(which led to
unresolved breakpoints for instance).

Here, I am putting back in the call to Normalize() and adding a unittest for 
FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is 
the expected
behaviour here.

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D19060

Modified:
lldb/trunk/source/Host/common/FileSpec.cpp
lldb/trunk/unittests/Host/FileSpecTest.cpp

Modified: lldb/trunk/source/Host/common/FileSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/FileSpec.cpp?rev=266286=266285=266286=diff
==
--- lldb/trunk/source/Host/common/FileSpec.cpp (original)
+++ lldb/trunk/source/Host/common/FileSpec.cpp Thu Apr 14 04:38:06 2016
@@ -394,6 +394,8 @@ FileSpec::SetFile (const char *pathname,
 m_is_resolved = true;
 }
 
+Normalize(resolved, syntax);
+
 llvm::StringRef resolve_path_ref(resolved.c_str());
 size_t dir_end = ParentPathEnd(resolve_path_ref, syntax);
 if (dir_end == 0)

Modified: lldb/trunk/unittests/Host/FileSpecTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/FileSpecTest.cpp?rev=266286=266285=266286=diff
==
--- lldb/trunk/unittests/Host/FileSpecTest.cpp (original)
+++ lldb/trunk/unittests/Host/FileSpecTest.cpp Thu Apr 14 04:38:06 2016
@@ -22,7 +22,7 @@ TEST(FileSpecTest, FileAndDirectoryCompo
 
 FileSpec fs_windows("F:\\bar", false, FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar", fs_windows.GetCString());
-EXPECT_STREQ("F:\\", fs_windows.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\", fs_windows.GetDirectory().GetCString()); // It 
returns "F:/"
 EXPECT_STREQ("bar", fs_windows.GetFilename().GetCString());
 
 FileSpec fs_posix_root("/", false, FileSpec::ePathSyntaxPosix);
@@ -38,7 +38,7 @@ TEST(FileSpecTest, FileAndDirectoryCompo
 FileSpec fs_windows_root("F:\\", false, FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\", fs_windows_root.GetCString());
 EXPECT_STREQ("F:", fs_windows_root.GetDirectory().GetCString());
-EXPECT_STREQ("\\", fs_windows_root.GetFilename().GetCString());
+// EXPECT_STREQ("\\", fs_windows_root.GetFilename().GetCString()); // It 
returns "/"
 
 FileSpec fs_posix_long("/foo/bar/baz", false, FileSpec::ePathSyntaxPosix);
 EXPECT_STREQ("/foo/bar/baz", fs_posix_long.GetCString());
@@ -47,7 +47,7 @@ TEST(FileSpecTest, FileAndDirectoryCompo
 
 FileSpec fs_windows_long("F:\\bar\\baz", false, 
FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar\\baz", fs_windows_long.GetCString());
-EXPECT_STREQ("F:\\bar", fs_windows_long.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", fs_windows_long.GetDirectory().GetCString()); 
// It returns "F:/bar"
 EXPECT_STREQ("baz", fs_windows_long.GetFilename().GetCString());
 
 FileSpec fs_posix_trailing_slash("/foo/bar/", false, 
FileSpec::ePathSyntaxPosix);
@@ -57,7 +57,7 @@ TEST(FileSpecTest, FileAndDirectoryCompo
 
 FileSpec fs_windows_trailing_slash("F:\\bar\\", false, 
FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar\\.", fs_windows_trailing_slash.GetCString());
-EXPECT_STREQ("F:\\bar", 
fs_windows_trailing_slash.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", 
fs_windows_trailing_slash.GetDirectory().GetCString()); // It returns "F:/bar"
 EXPECT_STREQ(".", fs_windows_trailing_slash.GetFilename().GetCString());
 }
 
@@ -72,7 +72,7 @@ TEST(FileSpecTest, AppendPathComponent)
 FileSpec fs_windows("F:\\bar", false, FileSpec::ePathSyntaxWindows);
 fs_windows.AppendPathComponent("baz");
 EXPECT_STREQ("F:\\bar\\baz", fs_windows.GetCString());
-EXPECT_STREQ("F:\\bar", fs_windows.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", fs_windows.GetDirectory().GetCString()); // It 
returns "F:/bar"
 EXPECT_STREQ("baz", fs_windows.GetFilename().GetCString());
 
 FileSpec fs_posix_root("/", false, FileSpec::ePathSyntaxPosix);
@@ -84,7 +84,7 @@ TEST(FileSpecTest, AppendPathComponent)
 FileSpec fs_windows_root("F:\\", false, FileSpec::ePathSyntaxWindows);
 fs_windows_root.AppendPathComponent("bar");
 EXPECT_STREQ("F:\\bar", fs_windows_root.GetCString());
-EXPECT_STREQ("F:\\", 

Re: [Lldb-commits] [PATCH] D19060: FileSpec: make matching separator-agnostic again

2016-04-14 Thread Pavel Labath via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266286: FileSpec: make matching separator-agnostic again 
(authored by labath).

Changed prior to commit:
  http://reviews.llvm.org/D19060?vs=53567=53680#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D19060

Files:
  lldb/trunk/source/Host/common/FileSpec.cpp
  lldb/trunk/unittests/Host/FileSpecTest.cpp

Index: lldb/trunk/unittests/Host/FileSpecTest.cpp
===
--- lldb/trunk/unittests/Host/FileSpecTest.cpp
+++ lldb/trunk/unittests/Host/FileSpecTest.cpp
@@ -22,7 +22,7 @@
 
 FileSpec fs_windows("F:\\bar", false, FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar", fs_windows.GetCString());
-EXPECT_STREQ("F:\\", fs_windows.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\", fs_windows.GetDirectory().GetCString()); // It 
returns "F:/"
 EXPECT_STREQ("bar", fs_windows.GetFilename().GetCString());
 
 FileSpec fs_posix_root("/", false, FileSpec::ePathSyntaxPosix);
@@ -38,16 +38,16 @@
 FileSpec fs_windows_root("F:\\", false, FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\", fs_windows_root.GetCString());
 EXPECT_STREQ("F:", fs_windows_root.GetDirectory().GetCString());
-EXPECT_STREQ("\\", fs_windows_root.GetFilename().GetCString());
+// EXPECT_STREQ("\\", fs_windows_root.GetFilename().GetCString()); // It 
returns "/"
 
 FileSpec fs_posix_long("/foo/bar/baz", false, FileSpec::ePathSyntaxPosix);
 EXPECT_STREQ("/foo/bar/baz", fs_posix_long.GetCString());
 EXPECT_STREQ("/foo/bar", fs_posix_long.GetDirectory().GetCString());
 EXPECT_STREQ("baz", fs_posix_long.GetFilename().GetCString());
 
 FileSpec fs_windows_long("F:\\bar\\baz", false, 
FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar\\baz", fs_windows_long.GetCString());
-EXPECT_STREQ("F:\\bar", fs_windows_long.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", fs_windows_long.GetDirectory().GetCString()); 
// It returns "F:/bar"
 EXPECT_STREQ("baz", fs_windows_long.GetFilename().GetCString());
 
 FileSpec fs_posix_trailing_slash("/foo/bar/", false, 
FileSpec::ePathSyntaxPosix);
@@ -57,7 +57,7 @@
 
 FileSpec fs_windows_trailing_slash("F:\\bar\\", false, 
FileSpec::ePathSyntaxWindows);
 EXPECT_STREQ("F:\\bar\\.", fs_windows_trailing_slash.GetCString());
-EXPECT_STREQ("F:\\bar", 
fs_windows_trailing_slash.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", 
fs_windows_trailing_slash.GetDirectory().GetCString()); // It returns "F:/bar"
 EXPECT_STREQ(".", fs_windows_trailing_slash.GetFilename().GetCString());
 }
 
@@ -72,7 +72,7 @@
 FileSpec fs_windows("F:\\bar", false, FileSpec::ePathSyntaxWindows);
 fs_windows.AppendPathComponent("baz");
 EXPECT_STREQ("F:\\bar\\baz", fs_windows.GetCString());
-EXPECT_STREQ("F:\\bar", fs_windows.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\bar", fs_windows.GetDirectory().GetCString()); // It 
returns "F:/bar"
 EXPECT_STREQ("baz", fs_windows.GetFilename().GetCString());
 
 FileSpec fs_posix_root("/", false, FileSpec::ePathSyntaxPosix);
@@ -84,7 +84,7 @@
 FileSpec fs_windows_root("F:\\", false, FileSpec::ePathSyntaxWindows);
 fs_windows_root.AppendPathComponent("bar");
 EXPECT_STREQ("F:\\bar", fs_windows_root.GetCString());
-EXPECT_STREQ("F:\\", fs_windows_root.GetDirectory().GetCString());
+// EXPECT_STREQ("F:\\", fs_windows_root.GetDirectory().GetCString()); // 
It returns "F:/"
 EXPECT_STREQ("bar", fs_windows_root.GetFilename().GetCString());
 }
 
@@ -95,3 +95,17 @@
 EXPECT_STREQ("/foo", fs.GetDirectory().GetCString());
 EXPECT_STREQ("bar", fs.GetFilename().GetCString());
 }
+
+TEST(FileSpecTest, Equal)
+{
+FileSpec backward("C:\\foo\\bar", false, FileSpec::ePathSyntaxWindows);
+FileSpec forward("C:/foo/bar", false, FileSpec::ePathSyntaxWindows);
+EXPECT_EQ(forward, backward);
+
+const bool full_match = true;
+const bool remove_backup_dots = true;
+EXPECT_TRUE(FileSpec::Equal(forward, backward, full_match, 
remove_backup_dots));
+EXPECT_TRUE(FileSpec::Equal(forward, backward, full_match, 
!remove_backup_dots));
+EXPECT_TRUE(FileSpec::Equal(forward, backward, !full_match, 
remove_backup_dots));
+EXPECT_TRUE(FileSpec::Equal(forward, backward, !full_match, 
!remove_backup_dots));
+}
Index: lldb/trunk/source/Host/common/FileSpec.cpp
===
--- lldb/trunk/source/Host/common/FileSpec.cpp
+++ lldb/trunk/source/Host/common/FileSpec.cpp
@@ -394,6 +394,8 @@
 m_is_resolved = true;
 }
 
+Normalize(resolved, syntax);
+
 llvm::StringRef resolve_path_ref(resolved.c_str());
 size_t dir_end = ParentPathEnd(resolve_path_ref, syntax);
 if (dir_end == 0)


Index: lldb/trunk/unittests/Host/FileSpecTest.cpp
===
--- 

Re: [Lldb-commits] [PATCH] D18981: Fix usage of APInt.getRawData for big-endian systems

2016-04-14 Thread Pavel Labath via lldb-commits
labath accepted this revision.
labath added a comment.

I am glad that the unit tests are finding real problems and not just being a 
nuisance. Thanks a lot.



Comment at: source/Core/Scalar.cpp:2655
@@ -2654,3 +2656,3 @@
 int128.x[1] = (uint64_t)data.GetU64 ();
-int128.x[0] = (uint64_t)data.GetU64 ( + 1);
 }

:D


http://reviews.llvm.org/D18981



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


Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR

2016-04-14 Thread Pavel Labath via lldb-commits
labath added a subscriber: labath.
labath added a comment.

Actually, the destination for liblldb.so depends on the LLVM_LIBDIR_SUFFIX 
cmake variable. If you're on a system which likes to shove things into lib64, 
maybe you could follow suit and define the variable when you build llvm/lldb. 
(otherwise, this patch will break the logic for anyone who does use the 
variable.) Would that work for your use case?


http://reviews.llvm.org/D19067



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


Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform

2016-04-14 Thread Pavel Labath via lldb-commits
labath accepted this revision.
labath added a comment.

That's perfect, thanks a lot. :)

Do you have commit access? If not, let me know when you're ready to start 
landing these things...


http://reviews.llvm.org/D18978



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