[Lldb-commits] [lldb] r317562 - test: Clean up finalize_build_dictionary
Author: labath
Date: Tue Nov 7 02:36:42 2017
New Revision: 317562
URL: http://llvm.org/viewvc/llvm-project?rev=317562&view=rev
Log:
test: Clean up finalize_build_dictionary
We only support API>=16 now, so we don't need to check the API level of
the android device.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.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=317562&r1=317561&r2=317562&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbplatformutil.py Tue Nov 7
02:36:42 2017
@@ -100,8 +100,7 @@ def finalize_build_dictionary(dictionary
if dictionary is None:
dictionary = {}
dictionary["OS"] = "Android"
-if android_device_api() >= 16:
-dictionary["PIE"] = 1
+dictionary["PIE"] = 1
return dictionary
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317561 - "Fix" concurrent events test for arm
Author: labath Date: Tue Nov 7 02:36:36 2017 New Revision: 317561 URL: http://llvm.org/viewvc/llvm-project?rev=317561&view=rev Log: "Fix" concurrent events test for arm Summary: The test incremented an atomic varible to trigger the watchpoint event. On arm64 this compiled to a ldaxr/stlxr loop, with the watchpoint being triggered in the middle of the loop. Hitting the watchpoint resets the exclusive monitor, and forces the process to loop one more time, hitting the watchpoint again, etc. While it would be nice if the debugger was able to resume from this situation, this is not trivial, and is not what this test is about. Therefore, I propose to change this to a simple store to a normal variable (which should still trip the watchpoint everywhere, but without atomic loops) and file a bug to investigate the possibilities of handling the watchpoints in atomic loops in a more reasonable way. Reviewers: clayborg Subscribers: aemerson, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D39680 Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/breakpoints_delayed_breakpoint_one_watchpoint/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint/TestConcurrentCrashWithWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint_breakpoint_signal/TestConcurrentCrashWithWatchpointBreakpointSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_signal_watch/TestConcurrentDelaySignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_watch_break/TestConcurrentDelayWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delayed_crash_with_breakpoint_watchpoint/TestConcurrentDelayedCrashWithBreakpointWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/main.cpp lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/n_watch_n_break/TestConcurrentNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_delay_watch/TestConcurrentSignalDelayWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch_break/TestConcurrentSignalWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoints_one_watchpoint/TestConcurrentTwoBreakpointsOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoint_threads/TestConcurrentTwoWatchpointThreads.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_breakpoint/TestConcurrentTwoWatchpointsOneBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_delay_breakpoint/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_signal/TestConcurrentTwoWatchpointsOneSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watch_break/TestConcurrentWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watch_break_delay/TestConcurrentWatchBreakDelay.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watchpoint_delay_watchpoint_one_breakpoint/TestConcurrentWatchpointDelayWatchpointOneBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watchpoint_with_delay_watchpoint_threads/TestConcurrentWatchpointWithDelayWatchpointThreads.py Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/decorators.py?rev=317561&r1=317560&r2=317561&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Tue Nov 7 02:36:36 2017 @@ -505,13 +505,6 @@ def skipIfRemote(func): return skipTestIfFn(is_remote)(func) -def skipIfRemoteDueToDeadlock(func): -"""Decorate the item to skip tests if testing remotely due to the test deadlocking.""" -def is_
[Lldb-commits] [PATCH] D39680: "Fix" concurrent events test for arm
This revision was automatically updated to reflect the committed changes. Closed by commit rL317561: "Fix" concurrent events test for arm (authored by labath). Repository: rL LLVM https://reviews.llvm.org/D39680 Files: lldb/trunk/packages/Python/lldbsuite/test/decorators.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/breakpoints_delayed_breakpoint_one_watchpoint/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint/TestConcurrentCrashWithWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint_breakpoint_signal/TestConcurrentCrashWithWatchpointBreakpointSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_signal_watch/TestConcurrentDelaySignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_watch_break/TestConcurrentDelayWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delayed_crash_with_breakpoint_watchpoint/TestConcurrentDelayedCrashWithBreakpointWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/main.cpp lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/n_watch_n_break/TestConcurrentNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_delay_watch/TestConcurrentSignalDelayWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch_break/TestConcurrentSignalWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoints_one_watchpoint/TestConcurrentTwoBreakpointsOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoint_threads/TestConcurrentTwoWatchpointThreads.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_breakpoint/TestConcurrentTwoWatchpointsOneBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_delay_breakpoint/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_signal/TestConcurrentTwoWatchpointsOneSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watch_break/TestConcurrentWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watch_break_delay/TestConcurrentWatchBreakDelay.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watchpoint_delay_watchpoint_one_breakpoint/TestConcurrentWatchpointDelayWatchpointOneBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/watchpoint_with_delay_watchpoint_threads/TestConcurrentWatchpointWithDelayWatchpointThreads.py Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py === --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py @@ -13,7 +13,6 @@ mydir = ConcurrentEventsBase.compute_mydir(__file__) @skipIfFreeBSD # timing out on buildbot -@skipIfRemoteDueToDeadlock # Atomic sequences are not supported yet for MIPS in LLDB. @skipIf(triple='^mips') @add_test_categories(["watchpoint"]) Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py === --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py @@ -13,7 +13,6 @@ mydir = ConcurrentEventsBase.compute_mydir(__file__) @skipIfFreeBSD # timing out on buildbot -@skipIfRemoteDueToDeadlock # Atomic sequences are not supported yet for MIPS in LLDB. @skipIf(triple='^mips') @add_test_categories(["wat
[Lldb-commits] [lldb] r317563 - Support scoped enums in the DWARF AST parser
Author: tberghammer
Date: Tue Nov 7 02:39:22 2017
New Revision: 317563
URL: http://llvm.org/viewvc/llvm-project?rev=317563&view=rev
Log:
Support scoped enums in the DWARF AST parser
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D39545
Modified:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=317563&r1=317562&r2=317563&view=diff
==
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Tue Nov 7 02:39:22 2017
@@ -397,7 +397,8 @@ public:
CompilerType CreateEnumerationType(const char *name,
clang::DeclContext *decl_ctx,
const Declaration &decl,
- const CompilerType &integer_qual_type);
+ const CompilerType &integer_qual_type,
+ bool is_scoped);
//--
// Integer type functions
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py?rev=317563&r1=317562&r2=317563&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
Tue Nov 7 02:39:22 2017
@@ -99,8 +99,8 @@ class CPP11EnumTypesTestCase(TestBase):
# Look up information about the 'DayType' enum type.
# Check for correct display.
self.expect("image lookup -t DayType", DATA_TYPES_DISPLAYED_CORRECTLY,
-substrs=['enum DayType {',
- 'Monday',
+patterns=['enum( struct| class) DayType {'],
+substrs=['Monday',
'Tuesday',
'Wednesday',
'Thursday',
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=317563&r1=317562&r2=317563&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Tue Nov
7 02:39:22 2017
@@ -927,6 +927,7 @@ TypeSP DWARFASTParserClang::ParseTypeFro
// Set a bit that lets us know that we are currently parsing this
dwarf->GetDIEToType()[die.GetDIE()] = DIE_IS_BEING_PARSED;
+bool is_scoped = false;
DWARFFormValue encoding_form;
const size_t num_attributes = die.GetAttributes(attributes);
@@ -963,6 +964,9 @@ TypeSP DWARFASTParserClang::ParseTypeFro
case DW_AT_declaration:
is_forward_declaration = form_value.Boolean();
break;
+ case DW_AT_enum_class:
+is_scoped = form_value.Boolean();
+break;
case DW_AT_allocated:
case DW_AT_associated:
case DW_AT_bit_stride:
@@ -1052,7 +1056,7 @@ TypeSP DWARFASTParserClang::ParseTypeFro
clang_type = m_ast.CreateEnumerationType(
type_name_cstr, GetClangDeclContextContainingDIE(die, nullptr),
-decl, enumerator_clang_type);
+decl, enumerator_clang_type, is_scoped);
} else {
enumerator_clang_type =
m_ast.GetEnumerationIntegerType(clang_type.GetOpaqueQualType());
Modified: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp?rev=317563&r1=317562&r2=317563&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp Tue Nov 7
02:39:22 2017
@@ -109,7 +109,7 @@ lldb::TypeSP PDBASTParser::CreateLLDBTyp
m_ast.GetBuiltinTypeForEncodingAndBitSize(encoding, bytes * 8);
CompilerType ast_enum = m_ast.CreateEnumerationType(
[Lldb-commits] [PATCH] D39545: Support scoped enums in the DWARF AST parser
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317563: Support scoped enums in the DWARF AST parser
(authored by tberghammer).
Repository:
rL LLVM
https://reviews.llvm.org/D39545
Files:
lldb/trunk/include/lldb/Symbol/ClangASTContext.h
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
@@ -109,7 +109,7 @@
m_ast.GetBuiltinTypeForEncodingAndBitSize(encoding, bytes * 8);
CompilerType ast_enum = m_ast.CreateEnumerationType(
-name.c_str(), tu_decl_ctx, decl, builtin_type);
+name.c_str(), tu_decl_ctx, decl, builtin_type, false);
auto enum_values = enum_type->findAllChildren();
while (auto enum_value = enum_values->getNext()) {
if (enum_value->getDataKind() != PDB_DataKind::Constant)
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -927,6 +927,7 @@
// Set a bit that lets us know that we are currently parsing this
dwarf->GetDIEToType()[die.GetDIE()] = DIE_IS_BEING_PARSED;
+bool is_scoped = false;
DWARFFormValue encoding_form;
const size_t num_attributes = die.GetAttributes(attributes);
@@ -963,6 +964,9 @@
case DW_AT_declaration:
is_forward_declaration = form_value.Boolean();
break;
+ case DW_AT_enum_class:
+is_scoped = form_value.Boolean();
+break;
case DW_AT_allocated:
case DW_AT_associated:
case DW_AT_bit_stride:
@@ -1052,7 +1056,7 @@
clang_type = m_ast.CreateEnumerationType(
type_name_cstr, GetClangDeclContextContainingDIE(die, nullptr),
-decl, enumerator_clang_type);
+decl, enumerator_clang_type, is_scoped);
} else {
enumerator_clang_type =
m_ast.GetEnumerationIntegerType(clang_type.GetOpaqueQualType());
Index: lldb/trunk/source/Symbol/ClangASTContext.cpp
===
--- lldb/trunk/source/Symbol/ClangASTContext.cpp
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp
@@ -2169,20 +2169,20 @@
CompilerType
ClangASTContext::CreateEnumerationType(const char *name, DeclContext *decl_ctx,
const Declaration &decl,
- const CompilerType &integer_clang_type) {
+ const CompilerType &integer_clang_type,
+ bool is_scoped) {
// TODO: Do something intelligent with the Declaration object passed in
// like maybe filling in the SourceLocation with it...
ASTContext *ast = getASTContext();
// TODO: ask about these...
- //const bool IsScoped = false;
//const bool IsFixed = false;
EnumDecl *enum_decl = EnumDecl::Create(
*ast, decl_ctx, SourceLocation(), SourceLocation(),
name && name[0] ? &ast->Idents.get(name) : nullptr, nullptr,
- false, // IsScoped
- false, // IsScopedUsingClassTag
+ is_scoped,
+ true, // IsScopedUsingClassTag
false); // IsFixed
if (enum_decl) {
Index: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
===
--- lldb/trunk/include/lldb/Symbol/ClangASTContext.h
+++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h
@@ -397,7 +397,8 @@
CompilerType CreateEnumerationType(const char *name,
clang::DeclContext *decl_ctx,
const Declaration &decl,
- const CompilerType &integer_qual_type);
+ const CompilerType &integer_qual_type,
+ bool is_scoped);
//--
// Integer type functions
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/enum_types/TestCPP11EnumTypes.py
@@ -99,8 +99,8 @@
# Look up inf
[Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
labath created this revision.
Herald added a subscriber: srhines.
This test was failing in various configurations on linux in a fairly
unpredictible way. The success depended on whether the c++ abi library
was linked in statically or not and how well was the linker able to
strip parts of it. This introduces additional code to the "dummmy" test
executable, which ensures that all parts of the library needed to
evaluate the expressions are always present.
https://reviews.llvm.org/D39727
Files:
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
Index: packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
===
--- packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
+++ packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
@@ -1,7 +1,15 @@
#include
-int main()
-{
-printf("This is a dummy\n"); // Set breakpoint here
-return 0;
+// These are needed to make sure that the linker does not strip the parts of
the
+// C++ abi library that are necessary to execute the expressions in the
+// debugger. It would be great if we did not need to do this, but the fact that
+// LLDB cannot conjure up the abi library on demand is not relevant for testing
+// top level expressions.
+struct DummyA {};
+struct DummyB : public virtual DummyA {};
+
+int main() {
+ DummyB b;
+ printf("This is a dummy\n"); // Set breakpoint here
+ return 0;
}
Index:
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
===
---
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
+++
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
@@ -57,23 +57,6 @@
self.runCmd("run", RUN_SUCCEEDED)
@add_test_categories(['pyapi'])
-@expectedFailureAndroid(api_levels=list(range(22+1)),
bugnumber="llvm.org/pr27787")
-@expectedFailureAll(
-oslist=["linux"],
-archs=[
-"arm",
-"aarch64"],
-bugnumber="llvm.org/pr27787")
-@expectedFailureAll(
-bugnumber="llvm.org/pr28353",
-oslist=["linux"],
-archs=[
-"i386",
-"x86_64"],
-compiler="gcc",
-compiler_version=[
-"<",
-"4.9"])
@skipIf(debug_info="gmodules") # not relevant
@skipIf(oslist=["windows"]) # Error in record layout on Windows
def test_top_level_expressions(self):
Index: packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
===
--- packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
+++ packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
@@ -1,7 +1,15 @@
#include
-int main()
-{
-printf("This is a dummy\n"); // Set breakpoint here
-return 0;
+// These are needed to make sure that the linker does not strip the parts of the
+// C++ abi library that are necessary to execute the expressions in the
+// debugger. It would be great if we did not need to do this, but the fact that
+// LLDB cannot conjure up the abi library on demand is not relevant for testing
+// top level expressions.
+struct DummyA {};
+struct DummyB : public virtual DummyA {};
+
+int main() {
+ DummyB b;
+ printf("This is a dummy\n"); // Set breakpoint here
+ return 0;
}
Index: packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
===
--- packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
+++ packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
@@ -57,23 +57,6 @@
self.runCmd("run", RUN_SUCCEEDED)
@add_test_categories(['pyapi'])
-@expectedFailureAndroid(api_levels=list(range(22+1)), bugnumber="llvm.org/pr27787")
-@expectedFailureAll(
-oslist=["linux"],
-archs=[
-"arm",
-"aarch64"],
-bugnumber="llvm.org/pr27787")
-@expectedFailureAll(
-bugnumber="llvm.org/pr28353",
-oslist=["linux"],
-archs=[
-"i386",
-"x86_64"],
-compiler="gcc",
-compiler_version=[
-"<",
-"4.9"])
@skipIf(debug_info="gmodules") # not relevant
@skipIf(oslist=["windows"]) # Error in record layout on Windows
def test_top_level_expressions(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
Can’t you just disable linker gc in the makefile?
On Tue, Nov 7, 2017 at 4:18 AM Pavel Labath via Phabricator via
lldb-commits wrote:
> labath created this revision.
> Herald added a subscriber: srhines.
>
> This test was failing in various configurations on linux in a fairly
> unpredictible way. The success depended on whether the c++ abi library
> was linked in statically or not and how well was the linker able to
> strip parts of it. This introduces additional code to the "dummmy" test
> executable, which ensures that all parts of the library needed to
> evaluate the expressions are always present.
>
>
> https://reviews.llvm.org/D39727
>
> Files:
>
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
>
>
> Index:
> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> ===
> --- packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> +++ packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> @@ -1,7 +1,15 @@
> #include
>
> -int main()
> -{
> -printf("This is a dummy\n"); // Set breakpoint here
> -return 0;
> +// These are needed to make sure that the linker does not strip the parts
> of the
> +// C++ abi library that are necessary to execute the expressions in the
> +// debugger. It would be great if we did not need to do this, but the
> fact that
> +// LLDB cannot conjure up the abi library on demand is not relevant for
> testing
> +// top level expressions.
> +struct DummyA {};
> +struct DummyB : public virtual DummyA {};
> +
> +int main() {
> + DummyB b;
> + printf("This is a dummy\n"); // Set breakpoint here
> + return 0;
> }
> Index:
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> ===
> ---
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> +++
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> @@ -57,23 +57,6 @@
> self.runCmd("run", RUN_SUCCEEDED)
>
> @add_test_categories(['pyapi'])
> -@expectedFailureAndroid(api_levels=list(range(22+1)), bugnumber="
> llvm.org/pr27787")
> -@expectedFailureAll(
> -oslist=["linux"],
> -archs=[
> -"arm",
> -"aarch64"],
> -bugnumber="llvm.org/pr27787")
> -@expectedFailureAll(
> -bugnumber="llvm.org/pr28353",
> -oslist=["linux"],
> -archs=[
> -"i386",
> -"x86_64"],
> -compiler="gcc",
> -compiler_version=[
> -"<",
> -"4.9"])
> @skipIf(debug_info="gmodules") # not relevant
> @skipIf(oslist=["windows"]) # Error in record layout on Windows
> def test_top_level_expressions(self):
>
>
> ___
> 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
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
I could, but I thought this would be more portable. For the Makefile
solution I'd need to do something like
LD_EXTRAS := -Wl,--no-as-needed,--whole-archive
Which is a bit of a hack, as I'm not even using these flags to affect
my own libraries, but the libraries that the compiler adds
automatically to the end of the linker line. And I'm not sure whether
the darwin linker (or lld when targetting windows) supports these
options.
On 7 November 2017 at 12:22, Zachary Turner wrote:
> Can’t you just disable linker gc in the makefile?
> On Tue, Nov 7, 2017 at 4:18 AM Pavel Labath via Phabricator via lldb-commits
> wrote:
>>
>> labath created this revision.
>> Herald added a subscriber: srhines.
>>
>> This test was failing in various configurations on linux in a fairly
>> unpredictible way. The success depended on whether the c++ abi library
>> was linked in statically or not and how well was the linker able to
>> strip parts of it. This introduces additional code to the "dummmy" test
>> executable, which ensures that all parts of the library needed to
>> evaluate the expressions are always present.
>>
>>
>> https://reviews.llvm.org/D39727
>>
>> Files:
>>
>> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
>> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
>>
>>
>> Index:
>> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
>> ===
>> --- packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
>> +++ packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
>> @@ -1,7 +1,15 @@
>> #include
>>
>> -int main()
>> -{
>> -printf("This is a dummy\n"); // Set breakpoint here
>> -return 0;
>> +// These are needed to make sure that the linker does not strip the parts
>> of the
>> +// C++ abi library that are necessary to execute the expressions in the
>> +// debugger. It would be great if we did not need to do this, but the
>> fact that
>> +// LLDB cannot conjure up the abi library on demand is not relevant for
>> testing
>> +// top level expressions.
>> +struct DummyA {};
>> +struct DummyB : public virtual DummyA {};
>> +
>> +int main() {
>> + DummyB b;
>> + printf("This is a dummy\n"); // Set breakpoint here
>> + return 0;
>> }
>> Index:
>> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
>> ===
>> ---
>> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
>> +++
>> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
>> @@ -57,23 +57,6 @@
>> self.runCmd("run", RUN_SUCCEEDED)
>>
>> @add_test_categories(['pyapi'])
>> -@expectedFailureAndroid(api_levels=list(range(22+1)),
>> bugnumber="llvm.org/pr27787")
>> -@expectedFailureAll(
>> -oslist=["linux"],
>> -archs=[
>> -"arm",
>> -"aarch64"],
>> -bugnumber="llvm.org/pr27787")
>> -@expectedFailureAll(
>> -bugnumber="llvm.org/pr28353",
>> -oslist=["linux"],
>> -archs=[
>> -"i386",
>> -"x86_64"],
>> -compiler="gcc",
>> -compiler_version=[
>> -"<",
>> -"4.9"])
>> @skipIf(debug_info="gmodules") # not relevant
>> @skipIf(oslist=["windows"]) # Error in record layout on Windows
>> def test_top_level_expressions(self):
>>
>>
>> ___
>> 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
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
I just wonder if we should be disabling linker gc across the board for all
tests unless you explicitly opt in.
Seems like something we would want only rarely, if ever
On Tue, Nov 7, 2017 at 4:36 AM Pavel Labath wrote:
> I could, but I thought this would be more portable. For the Makefile
> solution I'd need to do something like
>
> LD_EXTRAS := -Wl,--no-as-needed,--whole-archive
>
> Which is a bit of a hack, as I'm not even using these flags to affect
> my own libraries, but the libraries that the compiler adds
> automatically to the end of the linker line. And I'm not sure whether
> the darwin linker (or lld when targetting windows) supports these
> options.
>
> On 7 November 2017 at 12:22, Zachary Turner wrote:
> > Can’t you just disable linker gc in the makefile?
> > On Tue, Nov 7, 2017 at 4:18 AM Pavel Labath via Phabricator via
> lldb-commits
> > wrote:
> >>
> >> labath created this revision.
> >> Herald added a subscriber: srhines.
> >>
> >> This test was failing in various configurations on linux in a fairly
> >> unpredictible way. The success depended on whether the c++ abi library
> >> was linked in statically or not and how well was the linker able to
> >> strip parts of it. This introduces additional code to the "dummmy" test
> >> executable, which ensures that all parts of the library needed to
> >> evaluate the expressions are always present.
> >>
> >>
> >> https://reviews.llvm.org/D39727
> >>
> >> Files:
> >>
> >>
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> >> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> >>
> >>
> >> Index:
> >> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> >> ===
> >> ---
> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> >> +++
> packages/Python/lldbsuite/test/expression_command/top-level/dummy.cpp
> >> @@ -1,7 +1,15 @@
> >> #include
> >>
> >> -int main()
> >> -{
> >> -printf("This is a dummy\n"); // Set breakpoint here
> >> -return 0;
> >> +// These are needed to make sure that the linker does not strip the
> parts
> >> of the
> >> +// C++ abi library that are necessary to execute the expressions in the
> >> +// debugger. It would be great if we did not need to do this, but the
> >> fact that
> >> +// LLDB cannot conjure up the abi library on demand is not relevant for
> >> testing
> >> +// top level expressions.
> >> +struct DummyA {};
> >> +struct DummyB : public virtual DummyA {};
> >> +
> >> +int main() {
> >> + DummyB b;
> >> + printf("This is a dummy\n"); // Set breakpoint here
> >> + return 0;
> >> }
> >> Index:
> >>
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> >> ===
> >> ---
> >>
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> >> +++
> >>
> packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
> >> @@ -57,23 +57,6 @@
> >> self.runCmd("run", RUN_SUCCEEDED)
> >>
> >> @add_test_categories(['pyapi'])
> >> -@expectedFailureAndroid(api_levels=list(range(22+1)),
> >> bugnumber="llvm.org/pr27787")
> >> -@expectedFailureAll(
> >> -oslist=["linux"],
> >> -archs=[
> >> -"arm",
> >> -"aarch64"],
> >> -bugnumber="llvm.org/pr27787")
> >> -@expectedFailureAll(
> >> -bugnumber="llvm.org/pr28353",
> >> -oslist=["linux"],
> >> -archs=[
> >> -"i386",
> >> -"x86_64"],
> >> -compiler="gcc",
> >> -compiler_version=[
> >> -"<",
> >> -"4.9"])
> >> @skipIf(debug_info="gmodules") # not relevant
> >> @skipIf(oslist=["windows"]) # Error in record layout on Windows
> >> def test_top_level_expressions(self):
> >>
> >>
> >> ___
> >> 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
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
On 7 November 2017 at 12:46, Zachary Turner wrote: > I just wonder if we should be disabling linker gc across the board for all > tests unless you explicitly opt in. > > Seems like something we would want only rarely, if ever Yes, that might be an option. I don't really have a strong opinion on that, either way. FWIW, this is the only test that seems to be impacted by this. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
If it works, is easy, and doesn’t regress anything I’d honestly rather just disable linker gc. But I’m not familiar with the method you mentioned. I thought linker gc happens when you have -function-sections, -fdata-sections, and —gc-sections. Wouldn’t it work to just not have those? Or is something else going on? On Tue, Nov 7, 2017 at 5:17 AM Pavel Labath wrote: > On 7 November 2017 at 12:46, Zachary Turner wrote: > > I just wonder if we should be disabling linker gc across the board for > all > > tests unless you explicitly opt in. > > > > Seems like something we would want only rarely, if ever > > Yes, that might be an option. I don't really have a strong opinion on > that, either way. FWIW, this is the only test that seems to be > impacted by this. > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317574 - Fix an issue in r317563 causing a clang assert
Author: tberghammer
Date: Tue Nov 7 05:43:55 2017
New Revision: 317574
URL: http://llvm.org/viewvc/llvm-project?rev=317574&view=rev
Log:
Fix an issue in r317563 causing a clang assert
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=317574&r1=317573&r2=317574&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Tue Nov 7 05:43:55 2017
@@ -2181,9 +2181,9 @@ ClangASTContext::CreateEnumerationType(c
EnumDecl *enum_decl = EnumDecl::Create(
*ast, decl_ctx, SourceLocation(), SourceLocation(),
name && name[0] ? &ast->Idents.get(name) : nullptr, nullptr,
- is_scoped,
- true, // IsScopedUsingClassTag
- false); // IsFixed
+ is_scoped, // IsScoped
+ is_scoped, // IsScopedUsingClassTag
+ false);// IsFixed
if (enum_decl) {
// TODO: check if we should be setting the promotion type too?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
On 7 November 2017 at 13:29, Zachary Turner wrote: > If it works, is easy, and doesn’t regress anything I’d honestly rather just > disable linker gc. Ok, I'll try that. > > But I’m not familiar with the method you mentioned. I thought linker gc > happens when you have -function-sections, -fdata-sections, and —gc-sections. > > Wouldn’t it work to just not have those? Or is something else going on? There are different levels of gc. The flags you mentioned are what is traditionally understood as linker gc, and it works at function level. But there are other mechanisms to remove unused code. It is a form of GC, although most people probably don't think of it as such, since it has been around forever. (I just called it GC, because I didn't have a better name for it). We don't have this enabled for our tests. - normally when you are linking to a static library (.a file), linker will only include the object files that are needed to satisfy a dependency. This has been always the default, and you need to add --whole-library to disable it. However, I think we only link c++abi as a static library on android, so we can keep this flag in the android-specific blob. - if you link to a dynamic library, and that library is not needed to resolve any dependencies, then the linker can be told to omit it from the list of runtime dependencies (--as-needed). This didn't use to be the case, but more and more distributions are configured to have this on by default. This is what makes the behavior of the test unpredictable. > > On Tue, Nov 7, 2017 at 5:17 AM Pavel Labath wrote: >> >> On 7 November 2017 at 12:46, Zachary Turner wrote: >> > I just wonder if we should be disabling linker gc across the board for >> > all >> > tests unless you explicitly opt in. >> > >> > Seems like something we would want only rarely, if ever >> >> Yes, that might be an option. I don't really have a strong opinion on >> that, either way. FWIW, this is the only test that seems to be >> impacted by this. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
On 7 November 2017 at 13:51, Pavel Labath wrote: > On 7 November 2017 at 13:29, Zachary Turner wrote: >> If it works, is easy, and doesn’t regress anything I’d honestly rather just >> disable linker gc. > Ok, I'll try that. I'm starting not to to like this. Adding --whole-archive produces zillions of "multiple definitions of a symbol" errors on android. These can be squelched by telling the linker to ignore these errors (-z muldefs), but that's not really a supported configuration, and at that point this starts looking like a quite ugly hack. I think we should just stick to the original proposal of ensuring the code is pulled in by actually introducing a dependency. If it turns out we need to do this in a lot of places, we can revisit this approach. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D39727: Make TestTopLevelExprs more robust in face of linker GC
Fair enough, originally I thought this was the “traditional” kind of GC, which would have made this approach simpler On Tue, Nov 7, 2017 at 6:23 AM Pavel Labath wrote: > On 7 November 2017 at 13:51, Pavel Labath wrote: > > On 7 November 2017 at 13:29, Zachary Turner wrote: > >> If it works, is easy, and doesn’t regress anything I’d honestly rather > just > >> disable linker gc. > > Ok, I'll try that. > I'm starting not to to like this. Adding --whole-archive produces > zillions of "multiple definitions of a symbol" errors on android. > These can be squelched by telling the linker to ignore these errors > (-z muldefs), but that's not really a supported configuration, and at > that point this starts looking like a quite ugly hack. > > I think we should just stick to the original proposal of ensuring the > code is pulled in by actually introducing a dependency. If it turns > out we need to do this in a lot of places, we can revisit this > approach. > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
labath created this revision.
Herald added a subscriber: javed.absar.
These functions used to return bool to signify whether they were able to
retrieve the data. This is redundant because the ArchSpec and ByteOrder
already have their own "invalid" states, *and* because both of the
current implementations (linux, netbsd) can always provide a valid
result.
This allows us to simplify bits of the code handling these values.
https://reviews.llvm.org/D39733
Files:
include/lldb/Host/common/NativeProcessProtocol.h
source/Host/common/NativeProcessProtocol.cpp
source/Host/common/NativeRegisterContext.cpp
source/Plugins/Process/Linux/NativeProcessLinux.cpp
source/Plugins/Process/Linux/NativeProcessLinux.h
source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
source/Plugins/Process/Linux/NativeThreadLinux.cpp
source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -2041,17 +2041,6 @@
return SendIllFormedResponse(
packet, "P packet missing '=' char after register number");
- // Get process architecture.
- ArchSpec process_arch;
- if (!m_debugged_process_up ||
- !m_debugged_process_up->GetArchitecture(process_arch)) {
-if (log)
- log->Printf("GDBRemoteCommunicationServerLLGS::%s failed to retrieve "
- "inferior architecture",
- __FUNCTION__);
-return SendErrorResponse(0x49);
- }
-
// Parse out the value.
uint8_t reg_bytes[32]; // big enough to support up to 256 bit ymmN register
size_t reg_size = packet.GetHexBytesAvail(reg_bytes);
@@ -2109,7 +2098,9 @@
// Build the reginfos response.
StreamGDBRemote response;
- RegisterValue reg_value(reg_bytes, reg_size, process_arch.GetByteOrder());
+ RegisterValue reg_value(
+ reg_bytes, reg_size,
+ m_debugged_process_up->GetArchitecture().GetByteOrder());
Status error = reg_context_sp->WriteRegister(reg_info, reg_value);
if (error.Fail()) {
if (log)
Index: source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
===
--- source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
+++ source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp
@@ -144,9 +144,7 @@
if (m_reg_context_sp)
return m_reg_context_sp;
- ArchSpec target_arch;
- if (!m_process.GetArchitecture(target_arch))
-return NativeRegisterContextSP();
+ ArchSpec target_arch = m_process.GetArchitecture();
const uint32_t concrete_frame_idx = 0;
m_reg_context_sp.reset(
Index: source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
===
--- source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
+++ source/Plugins/Process/NetBSD/NativeProcessNetBSD.h
@@ -77,7 +77,7 @@
size_t UpdateThreads() override;
- bool GetArchitecture(ArchSpec &arch) const override;
+ const ArchSpec &GetArchitecture() const override { return m_arch; }
Status SetBreakpoint(lldb::addr_t addr, uint32_t size,
bool hardware) override;
Index: source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
===
--- source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
+++ source/Plugins/Process/NetBSD/NativeProcessNetBSD.cpp
@@ -678,11 +678,6 @@
size_t NativeProcessNetBSD::UpdateThreads() { return m_threads.size(); }
-bool NativeProcessNetBSD::GetArchitecture(ArchSpec &arch) const {
- arch = m_arch;
- return true;
-}
-
Status NativeProcessNetBSD::SetBreakpoint(lldb::addr_t addr, uint32_t size,
bool hardware) {
if (hardware)
Index: source/Plugins/Process/Linux/NativeThreadLinux.cpp
===
--- source/Plugins/Process/Linux/NativeThreadLinux.cpp
+++ source/Plugins/Process/Linux/NativeThreadLinux.cpp
@@ -144,14 +144,10 @@
if (m_reg_context_sp)
return m_reg_context_sp;
- ArchSpec target_arch;
- if (!m_process.GetArchitecture(target_arch))
-return NativeRegisterContextSP();
-
const uint32_t concrete_frame_idx = 0;
m_reg_context_sp.reset(
NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux(
- target_arch, *this, concrete_frame_idx));
+ m_process.GetArchitecture(), *this, concrete_frame_idx));
return m_reg_context_sp;
}
Index: source/Plug
[Lldb-commits] [PATCH] D39602: Update tuple/list/deque data formatters to work with newest libc++
jingham accepted this revision. jingham added a comment. This revision is now accepted and ready to land. This looks fine. Some day it would be nice to devise some markup in the STL that could be used to generate these formatters so we don't have to track them by hand, but that's a much longer term project. https://reviews.llvm.org/D39602 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
eugene added inline comments. Comment at: include/lldb/Host/common/NativeProcessProtocol.h:104 - virtual bool GetArchitecture(ArchSpec &arch) const = 0; + virtual const ArchSpec &GetArchitecture() const = 0; Why return reference instead of a value? https://reviews.llvm.org/D39733 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
labath added inline comments. Comment at: include/lldb/Host/common/NativeProcessProtocol.h:104 - virtual bool GetArchitecture(ArchSpec &arch) const = 0; + virtual const ArchSpec &GetArchitecture() const = 0; eugene wrote: > Why return reference instead of a value? I'd actually reverse that: Why value instead of a reference ? :D Returning by reference allows us to potentially avoid a copy. It does mean that the process object has to hold the archspec as a member, but that is currently not an issue, and we can always change that. https://reviews.llvm.org/D39733 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
krytarowski added a comment. The NetBSD part looks good. https://reviews.llvm.org/D39733 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r317624 - Update tuple/list/deque data formatters to work with newest libc++
Author: labath
Date: Tue Nov 7 14:17:29 2017
New Revision: 317624
URL: http://llvm.org/viewvc/llvm-project?rev=317624&view=rev
Log:
Update tuple/list/deque data formatters to work with newest libc++
Summary:
A couple of members of these data structures have been renamed in recent
months. This makes sure they still work with the latest libc++ version.
Reviewers: jingham, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39602
Modified:
lldb/trunk/examples/synthetic/libcxx.py
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
Modified: lldb/trunk/examples/synthetic/libcxx.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/examples/synthetic/libcxx.py?rev=317624&r1=317623&r2=317624&view=diff
==
--- lldb/trunk/examples/synthetic/libcxx.py (original)
+++ lldb/trunk/examples/synthetic/libcxx.py Tue Nov 7 14:17:29 2017
@@ -693,6 +693,13 @@ class stddeque_SynthProvider:
except:
return None
+def _get_value_of_compressed_pair(self, pair):
+value = pair.GetChildMemberWithName("__value_")
+if not value.IsValid():
+# pre-r300140 member name
+value = pair.GetChildMemberWithName("__first_")
+return value.GetValueAsUnsigned(0)
+
def update(self):
logger = lldb.formatters.Logger.Logger()
try:
@@ -709,8 +716,8 @@ class stddeque_SynthProvider:
# variable tells which element in this NxM array is the 0th
# one, and the 'size' element gives the number of elements
# in the deque.
-count = self.valobj.GetChildMemberWithName(
-
'__size_').GetChildMemberWithName('__first_').GetValueAsUnsigned(0)
+count = self._get_value_of_compressed_pair(
+self.valobj.GetChildMemberWithName('__size_'))
# give up now if we cant access memory reliably
if self.block_size < 0:
logger.write("block_size < 0")
@@ -724,8 +731,8 @@ class stddeque_SynthProvider:
'__begin_').GetValueAsUnsigned(0)
map_end = map_.GetChildMemberWithName(
'__end_').GetValueAsUnsigned(0)
-map_endcap = map_.GetChildMemberWithName(
-
'__end_cap_').GetChildMemberWithName('__first_').GetValueAsUnsigned(0)
+map_endcap = self._get_value_of_compressed_pair(
+map_.GetChildMemberWithName( '__end_cap_'))
# check consistency
if not map_first <= map_begin <= map_end <= map_endcap:
logger.write("map pointers are not monotonic")
Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp?rev=317624&r1=317623&r2=317624&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp Tue Nov 7
14:17:29 2017
@@ -298,6 +298,15 @@ ValueObjectSP ForwardListFrontEnd::GetCh
m_element_type);
}
+static ValueObjectSP GetValueOfCompressedPair(ValueObject &pair) {
+ ValueObjectSP value = pair.GetChildMemberWithName(ConstString("__value_"),
true);
+ if (! value) {
+// pre-r300140 member name
+value = pair.GetChildMemberWithName(ConstString("__first_"), true);
+ }
+ return value;
+}
+
bool ForwardListFrontEnd::Update() {
AbstractListFrontEnd::Update();
@@ -310,7 +319,7 @@ bool ForwardListFrontEnd::Update() {
m_backend.GetChildMemberWithName(ConstString("__before_begin_"), true));
if (!impl_sp)
return false;
- impl_sp = impl_sp->GetChildMemberWithName(ConstString("__first_"), true);
+ impl_sp = GetValueOfCompressedPair(*impl_sp);
if (!impl_sp)
return false;
m_head = impl_sp->GetChildMemberWithName(ConstString("__next_"), true).get();
@@ -331,10 +340,9 @@ size_t ListFrontEnd::CalculateNumChildre
ValueObjectSP size_alloc(
m_backend.GetChildMemberWithName(ConstString("__size_alloc_"), true));
if (size_alloc) {
-ValueObjectSP first(
-size_alloc->GetChildMemberWithName(ConstString("__first_"), true));
-if (first) {
- m_count = first->GetValueAsUnsigned(UINT32_MAX);
+ValueObjectSP value = GetValueOfCompressedPair(*size_alloc);
+if (value) {
+ m_count = value->GetValueAsUnsigned(UINT32_MAX);
}
}
if (m_count != UINT32_MAX) {
Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp?rev=317624&r1=317623&r2=317624&view=diff
==
--- l
[Lldb-commits] [PATCH] D39602: Update tuple/list/deque data formatters to work with newest libc++
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317624: Update tuple/list/deque data formatters to work with
newest libc++ (authored by labath).
Repository:
rL LLVM
https://reviews.llvm.org/D39602
Files:
lldb/trunk/examples/synthetic/libcxx.py
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
Index: lldb/trunk/examples/synthetic/libcxx.py
===
--- lldb/trunk/examples/synthetic/libcxx.py
+++ lldb/trunk/examples/synthetic/libcxx.py
@@ -693,6 +693,13 @@
except:
return None
+def _get_value_of_compressed_pair(self, pair):
+value = pair.GetChildMemberWithName("__value_")
+if not value.IsValid():
+# pre-r300140 member name
+value = pair.GetChildMemberWithName("__first_")
+return value.GetValueAsUnsigned(0)
+
def update(self):
logger = lldb.formatters.Logger.Logger()
try:
@@ -709,8 +716,8 @@
# variable tells which element in this NxM array is the 0th
# one, and the 'size' element gives the number of elements
# in the deque.
-count = self.valobj.GetChildMemberWithName(
-
'__size_').GetChildMemberWithName('__first_').GetValueAsUnsigned(0)
+count = self._get_value_of_compressed_pair(
+self.valobj.GetChildMemberWithName('__size_'))
# give up now if we cant access memory reliably
if self.block_size < 0:
logger.write("block_size < 0")
@@ -724,8 +731,8 @@
'__begin_').GetValueAsUnsigned(0)
map_end = map_.GetChildMemberWithName(
'__end_').GetValueAsUnsigned(0)
-map_endcap = map_.GetChildMemberWithName(
-
'__end_cap_').GetChildMemberWithName('__first_').GetValueAsUnsigned(0)
+map_endcap = self._get_value_of_compressed_pair(
+map_.GetChildMemberWithName( '__end_cap_'))
# check consistency
if not map_first <= map_begin <= map_end <= map_endcap:
logger.write("map pointers are not monotonic")
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxTuple.cpp
@@ -38,7 +38,11 @@
bool TupleFrontEnd::Update() {
m_elements.clear();
- m_base_sp = m_backend.GetChildMemberWithName(ConstString("base_"), true);
+ m_base_sp = m_backend.GetChildMemberWithName(ConstString("__base_"), true);
+ if (! m_base_sp) {
+// Pre r304382 name of the base element.
+m_base_sp = m_backend.GetChildMemberWithName(ConstString("base_"), true);
+ }
if (! m_base_sp)
return false;
m_elements.assign(m_base_sp->GetCompilerType().GetNumDirectBaseClasses(),
Index: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
===
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
@@ -298,6 +298,15 @@
m_element_type);
}
+static ValueObjectSP GetValueOfCompressedPair(ValueObject &pair) {
+ ValueObjectSP value = pair.GetChildMemberWithName(ConstString("__value_"),
true);
+ if (! value) {
+// pre-r300140 member name
+value = pair.GetChildMemberWithName(ConstString("__first_"), true);
+ }
+ return value;
+}
+
bool ForwardListFrontEnd::Update() {
AbstractListFrontEnd::Update();
@@ -310,7 +319,7 @@
m_backend.GetChildMemberWithName(ConstString("__before_begin_"), true));
if (!impl_sp)
return false;
- impl_sp = impl_sp->GetChildMemberWithName(ConstString("__first_"), true);
+ impl_sp = GetValueOfCompressedPair(*impl_sp);
if (!impl_sp)
return false;
m_head = impl_sp->GetChildMemberWithName(ConstString("__next_"), true).get();
@@ -331,10 +340,9 @@
ValueObjectSP size_alloc(
m_backend.GetChildMemberWithName(ConstString("__size_alloc_"), true));
if (size_alloc) {
-ValueObjectSP first(
-size_alloc->GetChildMemberWithName(ConstString("__first_"), true));
-if (first) {
- m_count = first->GetValueAsUnsigned(UINT32_MAX);
+ValueObjectSP value = GetValueOfCompressedPair(*size_alloc);
+if (value) {
+ m_count = value->GetValueAsUnsigned(UINT32_MAX);
}
}
if (m_count != UINT32_MAX) {
Index: lldb/trunk/examples/synthetic/libcxx.py
===
--- lldb/trunk/examples/synthetic/libcxx.py
+++ lldb/trunk/examples/synthetic/libcxx.py
@@ -693,6 +693,13 @@
except:
return None
+def _get_value_of_compressed_pair(self, pair):
+value =
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Looks fine. Seems like you should use your a const reference in a few places
and this will be good to go?
Comment at:
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1036
if (error.Success()) {
-lldb_private::ArchSpec arch;
-if (m_thread.GetProcess().GetArchitecture(arch)) {
- void *target_address = ((uint8_t *)®s) + offset +
- 4 * (arch.GetMachine() == llvm::Triple::mips);
- value.SetUInt(*(uint32_t *)target_address, size);
-} else
- error.SetErrorString("failed to get architecture");
+lldb_private::ArchSpec arch = m_thread.GetProcess().GetArchitecture();
+void *target_address = ((uint8_t *)®s) + offset +
Avoid a copy here by using a const reference?
Comment at: source/Plugins/Process/NetBSD/NativeThreadNetBSD.cpp:147
- ArchSpec target_arch;
- if (!m_process.GetArchitecture(target_arch))
-return NativeRegisterContextSP();
+ ArchSpec target_arch = m_process.GetArchitecture();
Void a copy here and use a const reference?
https://reviews.llvm.org/D39733
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
eugene added inline comments. Comment at: include/lldb/Host/common/NativeProcessProtocol.h:104 - virtual bool GetArchitecture(ArchSpec &arch) const = 0; + virtual const ArchSpec &GetArchitecture() const = 0; labath wrote: > eugene wrote: > > Why return reference instead of a value? > I'd actually reverse that: Why value instead of a reference ? :D > > Returning by reference allows us to potentially avoid a copy. It does mean > that the process object has to hold the archspec as a member, but that is > currently not an issue, and we can always change that. > Why value instead of a reference ? :D IMO returning by value is a default option, for 2 reasons: 1. References and pointers introduce implicit lifetime dependencies (prone to use-after-free) 2. Value can change over time, and client might not expect it to happen. Potentially avoid a copy in place where a copy was made previously and didn't seem to hurt anybody seems like a bad trade-off for one more place where we can get a dangling pointer. https://reviews.llvm.org/D39733 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39733: Simplify NativeProcessProtocol::GetArchitecture/GetByteOrder
clayborg added a comment. If it isn't expensive to copy, then we should probably just return by value. https://reviews.llvm.org/D39733 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
