[Lldb-commits] [lldb] r264846 - Fix flakyness in TestWatchpointMultipleThreads
Author: labath
Date: Wed Mar 30 03:43:54 2016
New Revision: 264846
URL: http://llvm.org/viewvc/llvm-project?rev=264846&view=rev
Log:
Fix flakyness in TestWatchpointMultipleThreads
Summary:
the inferior in the test deliberately does not lock a mutex when accessing the
watched variable.
The reason for that is unclear as, based on the logs, the original intention of
the test was to
check whether watchpoints get propagated to newly created threads, which should
work fine even
with a mutex. Furthermore, in the unlikely event (which I have still observed
happening from time
to time) that two threads do manage the execute the "critical section"
simultaneously, the test
will fail, as it is expecting the watchpoint "hit count" to be 1, but in this
case it will be 2.
Given this, I have simply chose to lock the mutex always, so that we have more
predictible
behavior. Watchpoints being hit simultaneously is still (and correctly!) tested
by
TestConcurrentEvents.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18558
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py?rev=264846&r1=264845&r2=264846&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
Wed Mar 30 03:43:54 2016
@@ -58,9 +58,6 @@ class WatchpointForMultipleThreadsTestCa
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
self.expect("watchpoint set variable -w write g_val",
WATCHPOINT_CREATED,
substrs = ['Watchpoint created', 'size = 4', 'type = w'])
@@ -102,9 +99,6 @@ class WatchpointForMultipleThreadsTestCa
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
self.expect("watchpoint set variable -w write g_val",
WATCHPOINT_CREATED,
substrs = ['Watchpoint created', 'size = 4', 'type = w'])
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp?rev=264846&r1=264845&r2=264846&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
Wed Mar 30 03:43:54 2016
@@ -23,8 +23,7 @@ uint32_t
access_pool (bool flag = false)
{
static std::mutex g_access_mutex;
-if (!flag)
-g_access_mutex.lock();
+g_access_mutex.lock();
uint32_t old_val = g_val;
if (flag)
@@ -33,17 +32,14 @@ access_pool (bool flag = false)
g_val = old_val + 1;
}
-if (!flag)
-g_access_mutex.unlock();
+g_access_mutex.unlock();
return g_val;
}
void
thread_func (uint32_t thread_index)
{
-// Break here in order to allow the thread
-// to inherit the global watchpoint state.
-printf ("%s (thread index = %u) startng...\n", __FUNCTION__, thread_index);
+printf ("%s (thread index = %u) starting...\n", __FUNCTION__,
thread_index);
uint32_t count = 0;
uint32_t val;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18558: Fix flakyness in TestWatchpointMultipleThreads
This revision was automatically updated to reflect the committed changes.
Closed by commit rL264846: Fix flakyness in TestWatchpointMultipleThreads
(authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D18558?vs=51929&id=52028#toc
Repository:
rL LLVM
http://reviews.llvm.org/D18558
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
@@ -23,27 +23,23 @@
access_pool (bool flag = false)
{
static std::mutex g_access_mutex;
-if (!flag)
-g_access_mutex.lock();
+g_access_mutex.lock();
uint32_t old_val = g_val;
if (flag)
{
printf("changing g_val to %d...\n", old_val + 1);
g_val = old_val + 1;
}
-if (!flag)
-g_access_mutex.unlock();
+g_access_mutex.unlock();
return g_val;
}
void
thread_func (uint32_t thread_index)
{
-// Break here in order to allow the thread
-// to inherit the global watchpoint state.
-printf ("%s (thread index = %u) startng...\n", __FUNCTION__, thread_index);
+printf ("%s (thread index = %u) starting...\n", __FUNCTION__,
thread_index);
uint32_t count = 0;
uint32_t val;
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
@@ -58,9 +58,6 @@
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
self.expect("watchpoint set variable -w write g_val",
WATCHPOINT_CREATED,
substrs = ['Watchpoint created', 'size = 4', 'type = w'])
@@ -102,9 +99,6 @@
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the global pool and by not
-# writing to the variable.
self.expect("watchpoint set variable -w write g_val",
WATCHPOINT_CREATED,
substrs = ['Watchpoint created', 'size = 4', 'type = w'])
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/main.cpp
@@ -23,27 +23,23 @@
access_pool (bool flag = false)
{
static std::mutex g_access_mutex;
-if (!flag)
-g_access_mutex.lock();
+g_access_mutex.lock();
uint32_t old_val = g_val;
if (flag)
{
printf("changing g_val to %d...\n", old_val + 1);
g_val = old_val + 1;
}
-if (!flag)
-g_access_mutex.unlock();
+g_access_mutex.unlock();
return g_val;
}
void
thread_func (uint32_t thread_index)
{
-// Break here in order to allow the thread
-// to inherit the global watchpoint state.
-printf ("%s (thread index = %u) startng...\n", __FUNCTION__, thread_index);
+printf ("%s (thread index = %u) starting...\n", __FUNCTION__, thread_index);
uint32_t count = 0;
uint32_t val;
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/multiple_threads/TestWatchpointMultipleThreads.py
@@ -58,9 +58,6 @@
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint for variable 'g_val'.
-# The main.cpp, by design, misbehaves by not following the agreed upon
-# protocol of using a mutex while accessing the glob
[Lldb-commits] [lldb] r264847 - Fix warning in ClangExpressionParser
Author: labath
Date: Wed Mar 30 03:45:37 2016
New Revision: 264847
URL: http://llvm.org/viewvc/llvm-project?rev=264847&view=rev
Log:
Fix warning in ClangExpressionParser
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?rev=264847&r1=264846&r2=264847&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Wed Mar 30 03:45:37 2016
@@ -212,7 +212,7 @@ public:
if (severity == eDiagnosticSeverityError)
{
size_t num_fixit_hints = Info.getNumFixItHints();
-for (int i = 0; i < num_fixit_hints; i++)
+for (size_t i = 0; i < num_fixit_hints; i++)
{
const clang::FixItHint &fixit = Info.getFixItHint(i);
if (!fixit.isNull())
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory
tberghammer added a reviewer: ted. tberghammer added a comment. Looks good (I added Ted as a reviewer for hexagon). http://reviews.llvm.org/D18531 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18481: Add argument to expectedFailureAll decorator to xfail for environment variables, and xfail tests for hard float abi and -mthumb on android arm
tberghammer added a comment. I would prefer a more general solution then the one Pavel proposed because currently we are adding 2 more options (abi and isa) but in the future we might need a lot of other stuff as well and adding a new argument for each one will be problematic (e.g. omit frame pointer, tune for processor core, specify fpu instruction set, etc...). I think if we have the option to specify a list of additional command line flags then tests can change behavior based on that list what will result in a similar behavior then Pavel's suggestion http://reviews.llvm.org/D18481 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264849 - Fix warning in ThreadSanitizerRuntime
Author: labath
Date: Wed Mar 30 04:42:59 2016
New Revision: 264849
URL: http://llvm.org/viewvc/llvm-project?rev=264849&view=rev
Log:
Fix warning in ThreadSanitizerRuntime
Modified:
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
Modified:
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp?rev=264849&r1=264848&r2=264849&view=diff
==
---
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
Wed Mar 30 04:42:59 2016
@@ -287,7 +287,7 @@ ConvertToStructuredArray(ValueObjectSP r
StructuredData::Array *array = new StructuredData::Array();
unsigned int count =
return_value_sp->GetValueForExpressionPath(count_name.c_str())->GetValueAsUnsigned(0);
ValueObjectSP objects =
return_value_sp->GetValueForExpressionPath(items_name.c_str());
-for (int i = 0; i < count; i++) {
+for (unsigned int i = 0; i < count; i++) {
ValueObjectSP o = objects->GetChildAtIndex(i, true);
StructuredData::Dictionary *dict = new StructuredData::Dictionary();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264850 - Fix SocketAddressTest (again)
Author: labath
Date: Wed Mar 30 04:43:04 2016
New Revision: 264850
URL: http://llvm.org/viewvc/llvm-project?rev=264850&view=rev
Log:
Fix SocketAddressTest (again)
On some versions of Windows, the address is returned as "::1", while on others
it's
"0:0:...:0:1". Accept both versions, as they represent the same address.
Modified:
lldb/trunk/unittests/Host/SocketAddressTest.cpp
Modified: lldb/trunk/unittests/Host/SocketAddressTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/SocketAddressTest.cpp?rev=264850&r1=264849&r2=264850&view=diff
==
--- lldb/trunk/unittests/Host/SocketAddressTest.cpp (original)
+++ lldb/trunk/unittests/Host/SocketAddressTest.cpp Wed Mar 30 04:43:04 2016
@@ -33,7 +33,8 @@ TEST_F (SocketAddressTest, Set)
ASSERT_EQ (0, sa.GetPort ());
ASSERT_TRUE (sa.SetToLocalhost (AF_INET6, 1139));
-ASSERT_STREQ ("::1", sa.GetIPAddress ().c_str ());
+ASSERT_TRUE(sa.GetIPAddress() == "::1" || sa.GetIPAddress() ==
"0:0:0:0:0:0:0:1") << "Address was: "
+
<< sa.GetIPAddress();
ASSERT_EQ (1139, sa.GetPort ());
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264854 - Fix the ThreadSanitizer support to avoid creating empty SBThreads and to not crash when thread_id is unavailable. Plus a whitespace fix.
Author: kuba.brecka
Date: Wed Mar 30 05:50:24 2016
New Revision: 264854
URL: http://llvm.org/viewvc/llvm-project?rev=264854&view=rev
Log:
Fix the ThreadSanitizer support to avoid creating empty SBThreads and to not
crash when thread_id is unavailable. Plus a whitespace fix.
Modified:
lldb/trunk/source/API/SBThread.cpp
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
Modified: lldb/trunk/source/API/SBThread.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBThread.cpp?rev=264854&r1=264853&r2=264854&view=diff
==
--- lldb/trunk/source/API/SBThread.cpp (original)
+++ lldb/trunk/source/API/SBThread.cpp Wed Mar 30 05:50:24 2016
@@ -338,8 +338,12 @@ AddThreadsForPath(std::string path, Thre
pcs.push_back(pc->GetAsInteger()->GetValue());
return true;
});
+
+if (pcs.size() == 0)
+return true;
-tid_t tid =
o->GetObjectForDotSeparatedPath("thread_id")->GetIntegerValue();
+StructuredData::ObjectSP thread_id_obj =
o->GetObjectForDotSeparatedPath("thread_id");
+tid_t tid = thread_id_obj ? thread_id_obj->GetIntegerValue() : 0;
uint32_t stop_id = 0;
bool stop_id_is_valid = false;
HistoryThread *history_thread = new HistoryThread(*process_sp, tid,
pcs, stop_id, stop_id_is_valid);
Modified:
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp?rev=264854&r1=264853&r2=264854&view=diff
==
---
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
(original)
+++
lldb/trunk/source/Plugins/InstrumentationRuntime/ThreadSanitizer/ThreadSanitizerRuntime.cpp
Wed Mar 30 05:50:24 2016
@@ -259,7 +259,7 @@ for (int i = 0; i < t.thread_count; i++)
__tsan_get_report_thread(t.report, i, &t.threads[i].tid,
&t.threads[i].pid, &t.threads[i].running, &t.threads[i].name,
&t.threads[i].parent_tid, t.threads[i].trace, REPORT_TRACE_SIZE);
}
-if (t.unique_tid_count >Â REPORT_ARRAY_SIZE) t.unique_tid_count =
REPORT_ARRAY_SIZE;
+if (t.unique_tid_count > REPORT_ARRAY_SIZE) t.unique_tid_count =
REPORT_ARRAY_SIZE;
for (int i = 0; i < t.unique_tid_count; i++) {
t.unique_tids[i].idx = i;
__tsan_get_report_unique_tid(t.report, i, &t.unique_tids[i].tid);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18598: Don't vary debug info for lldb-server tests
labath created this revision.
labath added reviewers: tberghammer, tfiala.
labath added a subscriber: lldb-commits.
Debug info is used only by the client and lldb-server tests do not even have
the client component
running, as they communicate with the server directly. Therefore, running the
tests for each
debug info type is unnecessarry.
This adds general ability to mark a test class as not dependent on debug info,
and marks all
lldb-server tests as such.
http://reviews.llvm.org/D18598
Files:
packages/Python/lldbsuite/test/lldbtest.py
packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
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
@@ -29,6 +29,8 @@
class GdbRemoteTestCaseBase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
_TIMEOUT_SECONDS = 7
_GDBREMOTE_KILL_PACKET = "$k#6b"
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1422,9 +1422,15 @@
# Metaclass for TestBase to change the list of test metods when a new TestCase
is loaded.
# We change the test methods to create a new test method for each test for
each debug info we are
# testing. The name of the new test method will be
'_' and with adding
-# the new test method we remove the old method at the same time.
+# the new test method we remove the old method at the same time. This
functionality can be
+# supressed by at test case level setting the class attribute
NO_DEBUG_INFO_TESTCASE or at test
+# level by using the decorator @no_debug_info_test.
class LLDBTestCaseFactory(type):
def __new__(cls, name, bases, attrs):
+original_testcase = super(LLDBTestCaseFactory, cls).__new__(cls, name,
bases, attrs)
+if original_testcase.NO_DEBUG_INFO_TESTCASE:
+return original_testcase
+
newattrs = {}
for attrname, attrvalue in attrs.items():
if attrname.startswith("test") and not getattr(attrvalue,
"__no_debug_info_test__", False):
@@ -1526,6 +1532,10 @@
Mac OS X implementation is located in plugins/darwin.py.
"""
+# Subclasses can set this to true (if they don't depend on debug info) to
avoid running the
+# test multiple times with various debug info types.
+NO_DEBUG_INFO_TESTCASE = False
+
# Maximum allowed attempts when launching the inferior process.
# Can be overridden by the LLDB_MAX_LAUNCH_COUNT environment variable.
maxLaunchCount = 3;
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
@@ -29,6 +29,8 @@
class GdbRemoteTestCaseBase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
_TIMEOUT_SECONDS = 7
_GDBREMOTE_KILL_PACKET = "$k#6b"
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1422,9 +1422,15 @@
# Metaclass for TestBase to change the list of test metods when a new TestCase is loaded.
# We change the test methods to create a new test method for each test for each debug info we are
# testing. The name of the new test method will be '_' and with adding
-# the new test method we remove the old method at the same time.
+# the new test method we remove the old method at the same time. This functionality can be
+# supressed by at test case level setting the class attribute NO_DEBUG_INFO_TESTCASE or at test
+# level by using the decorator @no_debug_info_test.
class LLDBTestCaseFactory(type):
def __new__(cls, name, bases, attrs):
+original_testcase = super(LLDBTestCaseFactory, cls).__new__(cls, name, bases, attrs)
+if original_testcase.NO_DEBUG_INFO_TESTCASE:
+return original_testcase
+
newattrs = {}
for attrname, attrvalue in attrs.items():
if attrname.startswith("test") and not getattr(attrvalue, "__no_debug_info_test__", False):
@@ -1526,6 +1532,10 @@
Mac OS X implementation is located in plugins/darwin.py.
"""
+# Subclasses can set this to true (if they don't depend on debug info) to avoid running the
+# test multiple times with various debug info types.
+NO_DEBUG_INFO_TESTCASE = False
+
# Maximum allowed attempts when launching the inferior process.
# Can be overridden by the LLDB_MAX_LAUNCH_COUNT environment variable.
maxLaunchCount = 3;
___
Re: [Lldb-commits] [PATCH] D18598: Don't vary debug info for lldb-server tests
LGTM, thanks for getting to that, Pavel!
On Wednesday, March 30, 2016, Pavel Labath wrote:
> labath created this revision.
> labath added reviewers: tberghammer, tfiala.
> labath added a subscriber: lldb-commits.
>
> Debug info is used only by the client and lldb-server tests do not even
> have the client component
> running, as they communicate with the server directly. Therefore, running
> the tests for each
> debug info type is unnecessarry.
>
> This adds general ability to mark a test class as not dependent on debug
> info, and marks all
> lldb-server tests as such.
>
> http://reviews.llvm.org/D18598
>
> Files:
> packages/Python/lldbsuite/test/lldbtest.py
> packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
>
> 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
> @@ -29,6 +29,8 @@
>
> class GdbRemoteTestCaseBase(TestBase):
>
> +NO_DEBUG_INFO_TESTCASE = True
> +
> _TIMEOUT_SECONDS = 7
>
> _GDBREMOTE_KILL_PACKET = "$k#6b"
> Index: packages/Python/lldbsuite/test/lldbtest.py
> ===
> --- packages/Python/lldbsuite/test/lldbtest.py
> +++ packages/Python/lldbsuite/test/lldbtest.py
> @@ -1422,9 +1422,15 @@
> # Metaclass for TestBase to change the list of test metods when a new
> TestCase is loaded.
> # We change the test methods to create a new test method for each test
> for each debug info we are
> # testing. The name of the new test method will be
> '_' and with adding
> -# the new test method we remove the old method at the same time.
> +# the new test method we remove the old method at the same time. This
> functionality can be
> +# supressed by at test case level setting the class attribute
> NO_DEBUG_INFO_TESTCASE or at test
> +# level by using the decorator @no_debug_info_test.
> class LLDBTestCaseFactory(type):
> def __new__(cls, name, bases, attrs):
> +original_testcase = super(LLDBTestCaseFactory, cls).__new__(cls,
> name, bases, attrs)
> +if original_testcase.NO_DEBUG_INFO_TESTCASE:
> +return original_testcase
> +
> newattrs = {}
> for attrname, attrvalue in attrs.items():
> if attrname.startswith("test") and not getattr(attrvalue,
> "__no_debug_info_test__", False):
> @@ -1526,6 +1532,10 @@
>Mac OS X implementation is located in plugins/darwin.py.
> """
>
> +# Subclasses can set this to true (if they don't depend on debug
> info) to avoid running the
> +# test multiple times with various debug info types.
> +NO_DEBUG_INFO_TESTCASE = False
> +
> # Maximum allowed attempts when launching the inferior process.
> # Can be overridden by the LLDB_MAX_LAUNCH_COUNT environment variable.
> maxLaunchCount = 3;
>
>
>
--
-Todd
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
Any issues with this? Honestly you can probably just read the description and lgtm it based on that, because as I said it's 99% a code move, and there is no functional change except for the one bug fix in ClangUtil::RemoveFastQualifiers. I have a followup patch almost complete which moves some more function, and adds some more unit tests, and (so far) fixes 2 more bugs that were found as a result of the unit tests. So I think the work is a win just on the grounds that I've already found 3 bugs as a result, even disregarding the benefits to ClangASTContext in file size. Let me know if I can continue this effort without review, it would save all of us some time and obviously I can use my judgement if I think the change is non-trivial. On Mon, Mar 28, 2016 at 4:32 PM Zachary Turner wrote: > zturner created this revision. > zturner added reviewers: spyffe, clayborg. > zturner added a subscriber: lldb-commits. > > This is pretty mechanical, so you don't really have to look at this in too > much detail. I'm mostly posting it here to make sure people are ok with > the high level idea. Basically ClangASTContext is a monstrous file and I > want to reduce the size by splitting out some of the functionality. > There's a ton of functions in `ClangASTContext` that are static and are > basically helper functions, but then other people like > `DWARFASTParserClang`, or `ClangASTImporter`, or other places re-use those > functions. So the idea is just to move all these common clang helper > functions into a single place. > > In doing so, it makes testing this type of functionality very easy, > because you can write a unit test for every function in the file. I did > that in this patch, and actually found one bug as a result of my unittest > failing (yay for unit tests). Since that is the only functional change in > the patch, you may want to look at it specifically. It's > `ClangUtil::RemoveFastQualifiers`. The version before my patch did > nothing, it returned exactly the same value it was passed in, because > `QualType::getQualifiers()` returns a `clang::Qualifiers` by value, so it > was not modifying the `QualType`'s qualifiers, but a copy of them, which > was immediately discarded. > > If anyone can think of a way to exercise this in a public API test, let me > know. > > I'm hoping to gradually move some more of the `ClangASTContext` functions > over to `ClangUtil` in subsequent patches. It makes understanding the > important parts of `ClangASTContext` easier, and it will allow me to add > more unittests for the rest of the functions as well (hopefully turning up > more bugs). > > http://reviews.llvm.org/D18530 > > Files: > include/lldb/Symbol/ClangASTContext.h > include/lldb/Symbol/ClangUtil.h > source/API/SBTarget.cpp > source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp > source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp > source/Symbol/ClangASTContext.cpp > source/Symbol/ClangASTImporter.cpp > source/Symbol/ClangUtil.cpp > unittests/CMakeLists.txt > unittests/Symbol/CMakeLists.txt > unittests/Symbol/TestClangUtil.cpp > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. The main reason I don't like this is all of the merge headaches it will create for us. We merge to swift.org and then over into some internal git repos. We have like 5 branches that we are always propagating things over to. This kind of change looks good in top of tree, but causes a ton if issues down the line. So this is my main hesitation. If we could keep any functions that were in ClangASTContext in ClangASTContext, because that is where they really belong. I don't really like the ClangUtil.cpp file because it is actually doing clang::ASTContext related things so the functions actually belong in ClangASTContext from a design point of view. So I would rather see the ClangUtil.cpp file go away and have everything be back in ClangASTContext.cpp. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg added a comment. I do like the tests that you added and I think we can still do the tests in TestClangASTContext.cpp. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. One or two of the functions, you are right. They do `clang::ASTContext` related things. That was actually an oversight on my part. I meant to move only functions that specifically did NOT do `clang::ASTContext` things. Like `RemoveFastQualifiers`, or converting enums, or converting from qual types to canonical qual types. Very simple utility functions. The reason why I don't think they should be in `ClangASTContext` from a design point of view is because they are used from all over the places, including from places that aren't actually holding and don't need an `ASTContext`. What if I move the `clang::ASTContext` functions back but keep the truly independent ones here? `ClangASTContext` is a really egregiously oversized file, so I think splitting it up a bit would be helpful. I also find it helpful to break a lot of these cyclic dependencies, where A.cpp includes B.h and B.cpp includes A.h, and we're doing that all over the place in large part because B.cpp is `ClangASTContext` and A.cpp is anything else that has to do anything, no matter what it is, to a clang type, even if it doesn't need an `ASTContext`. What kind of merge conflict does it create? There's no tricky changes here, why wouldn't they be mergeable to the other branch? I'm not really crazy about the idea of having decisions about upstream being based on someone's downstream issues though :-/ If something is good for the upstream it seems like that's merit enough to get it in. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264883 - Fix header name.
Author: jingham Date: Wed Mar 30 13:14:36 2016 New Revision: 264883 URL: http://llvm.org/viewvc/llvm-project?rev=264883&view=rev Log: Fix header name. Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h?rev=264883&r1=264882&r2=264883&view=diff == --- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h (original) +++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangDiagnostic.h Wed Mar 30 13:14:36 2016 @@ -1,4 +1,4 @@ -//===-- DiagnosticManager.h -*- C++ -*-===// +//===-- ClangDiagnostic.h ---*- C++ -*-===// // // The LLVM Compiler Infrastructure // ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18531: Allow gdbremote process to read modules from memory
ted added a comment. Thanks for adding me, Tamas. It looks like removing the code in the Hexagon Dynamic Loader plugin will have lldb drill down into ObjectFileElf, and end up doing the same thing - set the load address of each section of the ELF file. So it should behave the same as before this patch. I don't think we'll ever need too load a module from memory, but if we do, we can now. LGTM. http://reviews.llvm.org/D18531 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg added a comment.
In http://reviews.llvm.org/D18530#387175, @zturner wrote:
> One or two of the functions, you are right. They do `clang::ASTContext`
> related things. That was actually an oversight on my part. I meant to move
> only functions that specifically did NOT do `clang::ASTContext` things. Like
> `RemoveFastQualifiers`, or converting enums, or converting from qual types to
> canonical qual types. Very simple utility functions.
They are still clang::ASTContext related things since clang::QualType is part
of that whole infrastructure.
> The reason why I don't think they should be in `ClangASTContext` from a
> design point of view is because they are used from all over the places,
> including from places that aren't actually holding and don't need an
> `ASTContext`.
Does it just come down to QualType stuff? Those are fine the exist in
ClangUtil.cpp, but again, we have a ton or merges we are doing daily and any
moving of code does cause merge conflicts when they are just moved to be
logically moved elsewhere. When we have a fix, it first goes into llvm.org SVN,
then we cherry pick it over to swift.org into two branches: master and
master-next, then we cherry pick these fixes over to our internal branches
where we at least have two more merges. Each merge is possibly going into older
code where we would not have ClangUtil.cpp in that branch. So then we need to
be very careful with our merges to make sure we do them right. We finally got
to a place after splitting using DWARFASTParser and all that where merges are
going very smoothy most of the time since anything language specific is off in
a separate file.
> What if I move the `clang::ASTContext` functions back but keep the truly
> independent ones here? `ClangASTContext` is a really egregiously oversized
> file, so I think splitting it up a bit would be helpful. I also find it
> helpful to break a lot of these cyclic dependencies, where A.cpp includes B.h
> and B.cpp includes A.h, and we're doing that all over the place in large part
> because B.cpp is `ClangASTContext` and A.cpp is anything else that has to do
> anything, no matter what it is, to a clang type, even if it doesn't need an
> `ASTContext`.
We can probably simplify our header includes. The only time you need to include
a header file is if it affects the layout of the class in question. That means
base classes and instance variables only. Any functions that take full fledged
types like:
class Bar
{
void Foo(lldb_private::FileSpec file_spec);
};
Doesn't require FileSpec.h, just a forward declaration of FileSpec, because it
doesn't affect the layout of the class. Anyone that includes the above header
might need to manually include "FileSpec.h", but we can probably simplify our
includes quite a bit, so that might help.
So again, moving anything can cause merging headaches. See below for more
details.
> What kind of merge conflict does it create? There's no tricky changes here,
> why wouldn't they be mergeable to the other branch? I'm not really crazy
> about the idea of having decisions about upstream being based on someone's
> downstream issues though :-/ If something is good for the upstream it seems
> like that's merit enough to get it in.
So one example is the RemoveFastQualifiers() fix. If we merge that back into a
branch that doesn't have ClangUtil.cpp, we need to take the contents from any
functions in ClangUtils.cpp and find the old corresponding functions and paste
the new code back into there.
So if we only had private branches at Apple I wouldn't be making this argument.
But on swift.org, we have public merges going on all the time with auto
mergers. They can often fail when we do things like this (move stuff for
organization sake), so then we have to manually intervene. There are 3 branches
on swift.org that are always merging from other places. The LLVM and Clang on
swift.org doesn't track top of tree SVN llvm and clang, but might be up to two
months behind.
So I really implore us to not make these kinds of disruptive changes as it ends
up causing our automation steps to fail and causes us to have to manually
intervene and spend a lot of time doing manual merges.
http://reviews.llvm.org/D18530
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a reviewer: rsmith. zturner added a comment. But wouldn't doing that manual merge once then make things easier for the future? For example, if you merge back to a branch that doesn't have `ClangUtil.cpp`, and then you just add `ClangUtil.cpp` to that branch, the problem is solved for the future. So while it's an annoying manual merge, it only has to happen once. Incidentally, splitting up code like this makes merges easier over the long run, just like the example you gave with `DWARFASTParserClang` where now language specific stuff is in its own file. idk, I just don't feel very good about starting from the premise that code re-organizations are discouraged because of X, where X is, well pretty much anything. It's impossible for everyone to know about all the issues that all the downstream customers have to deal with, and in principle I feel like changes such as this should even be able to go through without review because the technical merits of having a healthy code organization are well understood, and while discouraging code re-organization might make one particular customer's life easier, I think it weighs on the larger project and indirectly every other downstream customer as a result. I'm curious now what clang does in this regard, so +rsmith in case he has some insight into what happens in clang when someone wants to re-organize some code and how other downstream customers (for example, swift) deal with this. Just to be clear, I'm genuinely sympathetic to the issues other people have to face with regards to their downstream build issues, so if there's any way for me to make this less painful I will go out of my way and spend extra time to make it so. But I think we should only be discussing the technical merits of the design and whether the code organization. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. I have explained my beef with the changes. If you feel you must make them as you want to we will deal with the fallout and extra work. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
tberghammer added a subscriber: tberghammer. tberghammer added a comment. I don't maintain any downstream branch to worry about merges but my personal opinion is moving large amount of code around can cause some issue in the future even for upstream. The 2 main issue I can think about: - "git log" and "git blame" will not display the original change for the code what is problematic when we try to track down why a piece of code have been added (especially for special cases) - As an active LLDB developer I have a pretty good idea about where a given piece of code lives. Moving the code around invalidates this knowledge for every developer in the project So in general if we get some actual advantage from moving the code (e.g. cleaner API, better testing options, etc...) then I have no issue around it but if the only gain is the file size reduction and the removal of the cyclic dependencies then I think this causes more problem then the benefit of the change (same reason why we don't run clang-format over the full code base). In this concrete case I don't see the benefit neither in the API nor for testing as all functions were accessible before in the same way and the tests can call the functions from the ClangASTContext instead of the ClangUtils with the same functionality. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
rsmith added a comment. In http://reviews.llvm.org/D18530#387230, @zturner wrote: > I'm curious now what clang does in this regard, so +rsmith in case he has > some insight into what happens in clang when someone wants to re-organize > some code and how other downstream customers (for example, swift) deal with > this. Clang has no API stability guarantees for its C++ interface. We reserve the right to reorganize at will, and to update, rename, and remove interfaces. This applies doubly to our internal code organization. Yes, this creates a burden on people maintaining out-of-tree patches, but in some ways that's a benefit, as it encourages patches to be contributed upstream when they make sense, or at least for patches to be proposed to refactor upstream so that the local changes are cleanly separable from the upstream code. Organizational changes do have a cost to upstream development in many ways (people are no longer familiar with the code organization, merging fixes to point releases is harder, work-in-progress changes may need non-trivial work to rebase, ...), so we'd only make them when they make sense from a technical / organizational perspective, but in the long term, it's not possible to maintain a healthy codebase if cleanup changes are held back due to those short-term costs. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. In http://reviews.llvm.org/D18530#387328, @tberghammer wrote: > I don't maintain any downstream branch to worry about merges but my personal > opinion is moving large amount of code around can cause some issue in the > future even for upstream. The 2 main issue I can think about: > > - "git log" and "git blame" will not display the original change for the code > what is problematic when we try to track down why a piece of code have been > added (especially for special cases) > - As an active LLDB developer I have a pretty good idea about where a given > piece of code lives. Moving the code around invalidates this knowledge for > every developer in the project > > So in general if we get some actual advantage from moving the code (e.g. > cleaner API, better testing options, etc...) then I have no issue around it > but if the only gain is the file size reduction and the removal of the cyclic > dependencies then I think this causes more problem then the benefit of the > change (same reason why we don't run clang-format over the full code base). > > In this concrete case I don't see the benefit neither in the API nor for > testing as all functions were accessible before in the same way and the tests > can call the functions from the ClangASTContext instead of the ClangUtils > with the same functionality. In this case I only moved a few functions just to test the waters, but if you look through ClangASTContext.h there are probably 40-50 functions that could theory be moved under the same idea. It's a couple thousand lines of code of jsut generic helper functions, which is not insignificant. The corollary to your statement is that we can just keep adding everything clang related to this one file, which if so maybe it jumps from 10,000 lines to 20,000 lines. File size is not normally a major concern, but at the same time I don't think we should just allow files and classes to grow unbounded in lines of code and number of member functions without being willing to think about if there should be a split. But relevant code should be grouped together as much as possible. Small interfaces are easier to understand than big interfaces. Answering the question "is there a way to do X" is easier when you only have to look an interface containing 30 functions than when you have to look through an interface containing 200 functions. As for "git log", "git blame", and knowing where a piece of code lives, there will always be times where you have to do some code archaeology to trace a line of code back to its origin. It's usually only a few extra commands. For example, you git blame `ClangUtil.cpp`, the revision of a line is the first commit of that file. The diff (or the commit message) shows it was moved from `ClangASTContext.cpp`. So you git blame the corresponding lines of `ClangASTContext.cpp` starting with x~1 where x is the revision shown in the first diff. It doesn't really much extra effort at all, certainly not so much that the extra effort outweighs the benefits of maintaining healthy code. Just my 2c, if nobody likes the idea then so be it, but I think it's easy to get stuck viewing this from the lens of someone who's already spent a great deal of effort understanding the code. So I would encourage you to think about it from the viewpoint of a newcomer to the codebase trying to understand the code. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
> On Mar 30, 2016, at 12:31 PM, Tamas Berghammer via lldb-commits > wrote: > > So in general if we get some actual advantage from moving the code (e.g. > cleaner API, better testing options, etc...) then I have no issue around it > but if the only gain is the file size reduction and the removal of the cyclic > dependencies then I think this causes more problem then the benefit of the > change (same reason why we don't run clang-format over the full code base). > > In this concrete case I don't see the benefit neither in the API nor for > testing as all functions were accessible before in the same way and the tests > can call the functions from the ClangASTContext instead of the ClangUtils > with the same functionality. +1 to this I have seen this kind of pattern (splitting the semantics of a class across multiple implementation files) in other languages (e.g. I remember seeing some C# code using it), but I don’t see much of an advantage to it in C++ Actually, in this case it looks like the multiple implementation files all need to #include some common headers, so what you end up with is even more code being compiled, which negates any advantage of having smaller on-disk files. Thanks, - Enrico 📩 egranata@.com ☎️ 27683 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264909 - When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
Author: gclayton
Date: Wed Mar 30 15:14:35 2016
New Revision: 264909
URL: http://llvm.org/viewvc/llvm-project?rev=264909&view=rev
Log:
When support for DWO files was added, there were two ways to pass
lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile
unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would
be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64
bit value and the lower 32 bits would be the DIE offset
There was a mixing and matching of this and it wasn't done consistently.
Major changes include:
The DIERef constructor that takes a lldb::user_id_t now requires a
SymbolFileDWARF:
DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)
It is needed so that it can be decoded correctly. If it is DWARF in .o files
with debug map in executable, then we get the right compile unit from the
SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE
offset for DWO or normal DWARF.
The function:
lldb::user_id_t DIERef::GetUID() const;
Now becomes
lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;
Again, we need the DWARF file to encode it correctly.
This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const"
and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There
were also many places were doing things inneficiently like:
1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the
lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to
find that type.
There are many places that are now doing this more efficiently by storing
DW_AT_type form values as DWARFFormValue objects and then making a DIERef from
them and directly calling the underlying function to resolve the
lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl,
lldb_private::CompilerDeclContext.
If there are any regressions in DWARF with DWO, we will need to fix any issues
that arise since the original patch wasn't functional for the much more widely
used DWARF in .o files with debug map.
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserGo.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserJava.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDIECollection.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDIECollection.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp?rev=264909&r1=264908&r2=264909&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DIERef.cpp Wed Mar 30 15:14:35
2016
@@ -10,26 +10,49 @@
#include "DIERef.h"
#include "DWARFCompileUnit.h"
#include "DWARFFormValue.h"
+#include "DWARFDebugInfo.h"
+#include "SymbolFileDWARF.h"
+#include "SymbolFileDWARFDebugMap.h"
DIERef::DIERef() :
cu_offset(DW_INVALID_OFFSET),
die_offset(DW_INVALID_OFFSET)
{}
-DIERef::DIERef(dw_offset_t d) :
-cu_offset(DW_INVALID_OFFSET),
-die_offset(d)
-{}
-
DIERef::DIERef(dw_offset_t c, dw_offset_t d) :
cu_offset(c),
die_offset(d)
{}
-DIERef::DIERef(lldb::user_id_t uid) :
-cu_offset(uid>>32),
+DIERef::DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf) :
+cu_offset(DW_INVALID_OFFSET),
die_offset(uid&0x)
-{}
+{
+SymbolFileDWARFDebugMap *debug_map = dwarf->GetDebugMapSymfile();
+if (debug_map)
+{
+const uint32_t oso_idx = debug_map->GetOSOIndexFromUserID(uid);
+SymbolFileDWARF *actual_dwarf =
debug_map->GetSymbolFileByOSOIndex(oso_idx);
+if (actual_dwarf)
+{
+DWARFDebugInfo *debug_info = actual_dwarf->DebugInfo();
+if (debug_info)
+{
+DWARFCompileUnit *dwarf_cu =
d
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. So, in thinking about this some more, my end goal does not necessarily involve the creation of a new file. The primary goal is group related functions together into a more bite-sized interface in order to make it easier to understand the code. How about keeping everything in the same file, but still splitting these functions out into another class defined in that file? For example, the `ClangUtil` class could still be in `ClangASTContext.h`. I think that eliminates the concern about merging, and while it doesn't address the issue of the massive file (which I still think is an important consideration for the long term health of this code), it at least makes some progress in that it groups everything together so that it makes the interface more easily digestible, and makes a move to another file easier in the future if someone wanted to do it. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264914 - Fixed a problem where a dSYM wasn't properly found because it had the wrong name
Author: spyffe
Date: Wed Mar 30 15:17:41 2016
New Revision: 264914
URL: http://llvm.org/viewvc/llvm-project?rev=264914&view=rev
Log:
Fixed a problem where a dSYM wasn't properly found because it had the wrong name
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/Makefile?rev=264914&r1=264913&r2=264914&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/Makefile
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/Makefile
Wed Mar 30 15:17:41 2016
@@ -7,9 +7,10 @@ default:a.out.stripped
a.out.stripped: a.out.dSYM
strip -o a.out.stripped a.out
+ ln -sf a.out.dSYM a.out.stripped.dSYM
clean::
rm -f a.out.stripped
- rm -rf a.out.stripped.dSYM
+ rm -rf *.dSYM
include $(LEVEL)/Makefile.rules
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py?rev=264914&r1=264913&r2=264914&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
Wed Mar 30 15:17:41 2016
@@ -30,7 +30,7 @@ class TestObjCStaticMethodStripped(TestB
if self.getArchitecture() == 'i386':
self.skipTest("requires modern objc runtime")
self.build()
-exe = os.path.join(os.getcwd(), "a.out.stripped")
+exe = os.path.join(os.getcwd(), "a.out")
target = self.dbg.CreateTarget(exe)
self.assertTrue(target, VALID_TARGET)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg added a comment. In http://reviews.llvm.org/D18530#387377, @zturner wrote: > So, in thinking about this some more, my end goal does not necessarily > involve the creation of a new file. The primary goal is group related > functions together into a more bite-sized interface in order to make it > easier to understand the code. > > How about keeping everything in the same file, but still splitting these > functions out into another class defined in that file? For example, the > `ClangUtil` class could still be in `ClangASTContext.h`. I think that > eliminates the concern about merging, and while it doesn't address the issue > of the massive file (which I still think is an important consideration for > the long term health of this code), it at least makes some progress in that > it groups everything together so that it makes the interface more easily > digestible, and makes a move to another file easier in the future if someone > wanted to do it. That still doesn't help downstream merging. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. In http://reviews.llvm.org/D18530#387382, @clayborg wrote: > In http://reviews.llvm.org/D18530#387377, @zturner wrote: > > > So, in thinking about this some more, my end goal does not necessarily > > involve the creation of a new file. The primary goal is group related > > functions together into a more bite-sized interface in order to make it > > easier to understand the code. > > > > How about keeping everything in the same file, but still splitting these > > functions out into another class defined in that file? For example, the > > `ClangUtil` class could still be in `ClangASTContext.h`. I think that > > eliminates the concern about merging, and while it doesn't address the > > issue of the massive file (which I still think is an important > > consideration for the long term health of this code), it at least makes > > some progress in that it groups everything together so that it makes the > > interface more easily digestible, and makes a move to another file easier > > in the future if someone wanted to do it. > > > That still doesn't help downstream merging. I thought you said the issue was if you try to merge to a branch that didn't have the `ClangUtil.cpp` file. If you just copy and paste a function from one location in a file to another location and change the class it belongs to, that's still a problem? That's a mighty big burden for upstream developers to have to deal with. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. The last time we talked about this, you said something along the lines of "Changes to LLVM and LLDB at the same time are a problem, but any refactor that happens entirely within LLDB is fine" http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
clayborg added a comment. > I thought you said the issue was if you try to merge to a branch that didn't > have the `ClangUtil.cpp` file. If you just copy and paste a function from > one location in a file to another location and change the class it belongs > to, that's still a problem? So merging to current top of tree is easier than merging to a release branch. When merging to a top of tree for any repository that is currently mirroring a close relative of the current code is easy and the extra file doesn't matter. The issues arise when we find a bug deep in one of our released branches. Then to fix it we actually fix it into llvm.org SVN, then merge to swift.org into many branches, and then merge into many internal branches and eventually over to the release branch. We want minimal code changes so that we minimize our risk when taking fixes into release branches. Anytime we introduce manual merging where we have to say "Oh, this function in 'ClangUtil::DoSomething' used to be in 'ClangASTContext::DoSomething', so I will need to take the guts of the function and manually copy it over and make sure it actually works". This is when errors happen. The other worse case is where we actually just merge the ClangUtil.cpp and ClangUtil.h file into our older branch, make sure it gets built in the Xcode project file, and then none of our code gets fixed because we still have the "ClangASTContext::DoSomething" that is buggy, but our merging worked just fine by merging in a new source that compiles but no one uses. > That's a mighty big burden for upstream developers to have to deal with. But it is where we are and it is our reality. So I am trying to minimize and point out when these kinds of issues will cause problems as I review patches. I know it is tempting to move stuff around, and we used to just accept these patches, but as we have over the past year, we have run into many issues of exactly the flavor we are talking about here, so I am proactively trying to avoid it when the need to do so isn't as strong. Many times I agree that things were architected incorrectly, or just are architected the way they are because of the way the code has evolved over the years, and those I believe we should fix. I would rather avoid this when we can when there isn't a strong reason to do so. I believe this is one of those cases. http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18620: Print environment when dumping arch triple
fjricci created this revision.
fjricci added reviewers: tfiala, clayborg.
fjricci added subscribers: sas, lldb-commits.
Print environment from triple if it exists.
http://reviews.llvm.org/D18620
Files:
source/Core/ArchSpec.cpp
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1529,10 +1529,14 @@
llvm::StringRef arch_str = triple.getArchName();
llvm::StringRef vendor_str = triple.getVendorName();
llvm::StringRef os_str = triple.getOSName();
+llvm::StringRef environ_str = triple.getEnvironmentName();
s.Printf("%s-%s-%s",
arch_str.empty() ? "*" : arch_str.str().c_str(),
vendor_str.empty() ? "*" : vendor_str.str().c_str(),
os_str.empty() ? "*" : os_str.str().c_str()
);
+
+if (!environ_str.empty())
+s.Printf("-%s", environ_str.str().c_str());
}
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -1529,10 +1529,14 @@
llvm::StringRef arch_str = triple.getArchName();
llvm::StringRef vendor_str = triple.getVendorName();
llvm::StringRef os_str = triple.getOSName();
+llvm::StringRef environ_str = triple.getEnvironmentName();
s.Printf("%s-%s-%s",
arch_str.empty() ? "*" : arch_str.str().c_str(),
vendor_str.empty() ? "*" : vendor_str.str().c_str(),
os_str.empty() ? "*" : os_str.str().c_str()
);
+
+if (!environ_str.empty())
+s.Printf("-%s", environ_str.str().c_str());
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D18621: Allow remote to update individual arch triple components
fjricci created this revision.
fjricci added reviewers: clayborg, tfiala, tberghammer.
fjricci added subscribers: sas, lldb-commits.
Herald added subscribers: danalbert, tberghammer, aemerson.
If we determine an OS from the executable, but not an environment,
the existing code will not update the target triple to add an
environment provided by the remote.
This manifests if we have an android exe, where we could parse
arm-*-linux from the ELF, but then the remote gives a triple of
arm-*-linux-android. The existing code will not update the
environment in this case, because the OS has not changed.
http://reviews.llvm.org/D18621
Files:
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1220,19 +1220,20 @@
if (new_target_triple.getVendorName().size() == 0)
{
new_target_triple.setVendor
(remote_triple.getVendor());
+}
+if (new_target_triple.getOSName().size() == 0)
+{
+new_target_triple.setOS (remote_triple.getOS());
-if (new_target_triple.getOSName().size() == 0)
-{
-new_target_triple.setOS (remote_triple.getOS());
-
-if (new_target_triple.getEnvironmentName().size()
== 0)
-new_target_triple.setEnvironment
(remote_triple.getEnvironment());
-}
-
-ArchSpec new_target_arch = target_arch;
-new_target_arch.SetTriple(new_target_triple);
-GetTarget().SetArchitecture(new_target_arch);
}
+if (new_target_triple.getEnvironmentName().size() == 0)
+{
+new_target_triple.setEnvironment
(remote_triple.getEnvironment());
+}
+
+ArchSpec new_target_arch = target_arch;
+new_target_arch.SetTriple(new_target_triple);
+GetTarget().SetArchitecture(new_target_arch);
}
if (log)
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1220,19 +1220,20 @@
if (new_target_triple.getVendorName().size() == 0)
{
new_target_triple.setVendor (remote_triple.getVendor());
+}
+if (new_target_triple.getOSName().size() == 0)
+{
+new_target_triple.setOS (remote_triple.getOS());
-if (new_target_triple.getOSName().size() == 0)
-{
-new_target_triple.setOS (remote_triple.getOS());
-
-if (new_target_triple.getEnvironmentName().size() == 0)
-new_target_triple.setEnvironment (remote_triple.getEnvironment());
-}
-
-ArchSpec new_target_arch = target_arch;
-new_target_arch.SetTriple(new_target_triple);
-GetTarget().SetArchitecture(new_target_arch);
}
+if (new_target_triple.getEnvironmentName().size() == 0)
+{
+new_target_triple.setEnvironment (remote_triple.getEnvironment());
+}
+
+ArchSpec new_target_arch = target_arch;
+new_target_arch.SetTriple(new_target_triple);
+GetTarget().SetArchitecture(new_target_arch);
}
if (log)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18621: Allow remote to update individual arch triple components
fjricci abandoned this revision. fjricci added a comment. Doesn't appear necessary after applying http://reviews.llvm.org/D18620 http://reviews.llvm.org/D18621 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18530: Move some functions from ClangASTContext to ClangUtil
zturner added a comment. I will move most of this back to `ClangASTContext`, but I want to state again that I would like to reach a point where downstream merge issues are not even a topic that comes up in code reviews. I see many huge refactors coming through from people that do not go up for review, do not ask about other peoples' downstream build issues or how it affects them, and are not discussed in the open before going through. So I do not want there to be a double standard. Either everyone needs to run every change by everyone in the community before committing anything, or we adopt the LLVM policy of post commit review and downstream maintainers handling their downstream problems silently. It is not fair to even mention the issue of downstream merge issues, because it stifles improvements to code health (even if they are minor improvements), when LLVM has a clear policy that downstream problems are not the upstream's problem. I'm fine working together and compromising or whatever, but I am pretty strongly opposed to rejecting changes that improve code health because of someone's merge problems. That needs to be an issue that is dealt with downstream -- and more importantly not even mentioned as a point of discussion in the upstream. With that said, I will undo most of these changes (but continue writing the unittests) http://reviews.llvm.org/D18530 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264957 - Enhance the 'type X list' commands such that they actually alert the user if no formatters matching the constraints could be found
Author: enrico
Date: Wed Mar 30 17:45:13 2016
New Revision: 264957
URL: http://llvm.org/viewvc/llvm-project?rev=264957&view=rev
Log:
Enhance the 'type X list' commands such that they actually alert the user if no
formatters matching the constraints could be found
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-categories/TestDataFormatterCategories.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-named-summaries/TestDataFormatterNamedSummaries.py
lldb/trunk/source/Commands/CommandObjectType.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-categories/TestDataFormatterCategories.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-categories/TestDataFormatterCategories.py?rev=264957&r1=264956&r2=264957&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-categories/TestDataFormatterCategories.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-categories/TestDataFormatterCategories.py
Wed Mar 30 17:45:13 2016
@@ -155,6 +155,7 @@ class CategoriesDataFormatterTestCase(Te
self.runCmd("type category enable Category1")
self.runCmd("type summary list -w Category1")
+self.expect("type summary list -w NoSuchCategoryHere", substrs=['no
matching results found'])
self.expect("frame variable r1 r2 r3",
substrs = ['r1 = Category1',
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-named-summaries/TestDataFormatterNamedSummaries.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-named-summaries/TestDataFormatterNamedSummaries.py?rev=264957&r1=264956&r2=264957&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-named-summaries/TestDataFormatterNamedSummaries.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-named-summaries/TestDataFormatterNamedSummaries.py
Wed Mar 30 17:45:13 2016
@@ -48,7 +48,9 @@ class NamedSummariesDataFormatterTestCas
self.runCmd("type summary add --summary-string \"First: x=${var.x}
y=${var.y} dummy=${var.dummy}\" First")
self.runCmd("type summary add --summary-string \"Second: x=${var.x}
y=${var.y%hex}\" Second")
self.runCmd("type summary add --summary-string \"Third: x=${var.x}
z=${var.z}\" Third")
-
+
+self.expect('type summary list', substrs=['AllUseIt'])
+
self.expect("frame variable first",
substrs = ['First: x=12'])
Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=264957&r1=264956&r2=264957&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Wed Mar 30 17:45:13 2016
@@ -1310,9 +1310,10 @@ public:
~CommandObjectTypeFormatterList() override = default;
protected:
-virtual void
+virtual bool
FormatterSpecificList (CommandReturnObject &result)
{
+return false;
}
bool
@@ -1346,10 +1347,13 @@ protected:
}
}
-auto category_closure = [&result, &formatter_regex] (const
lldb::TypeCategoryImplSP& category) -> void {
+bool any_printed = false;
+
+auto category_closure = [&result, &formatter_regex, &any_printed]
(const lldb::TypeCategoryImplSP& category) -> void {
result.GetOutputStream().Printf("---\nCategory:
%s\n---\n", category->GetName());
+
TypeCategoryImpl::ForEachCallbacks foreach;
-foreach.SetExact([&result, &formatter_regex] (ConstString name,
const FormatterSharedPointer& format_sp) -> bool {
+foreach.SetExact([&result, &formatter_regex, &any_printed]
(ConstString name, const FormatterSharedPointer& format_sp) -> bool {
if (formatter_regex)
{
bool escape = true;
@@ -1365,13 +1369,13 @@ protected:
if (escape)
return true;
}
-
+
+any_printed = true;
result.GetOutputStream().Printf ("%s: %s\n", name.AsCString(),
format_sp->GetDescription().c_str());
-
[Lldb-commits] [PATCH] D18631: Make sure to update Target arch if environment changed
fjricci created this revision. fjricci added reviewers: jasonmolenda, tfiala, clayborg. fjricci added subscribers: sas, lldb-commits. Herald added subscribers: danalbert, tberghammer. Fixes "target list" for non-android linux platforms (ie gnu, gnueabi) http://reviews.llvm.org/D18631 Files: source/Target/Target.cpp Index: source/Target/Target.cpp === --- source/Target/Target.cpp +++ source/Target/Target.cpp @@ -1301,7 +1301,7 @@ os_ver_changed, env_changed); -if (!arch_changed && !vendor_changed && !os_changed) +if (!arch_changed && !vendor_changed && !os_changed && !env_changed) replace_local_arch = false; } } Index: source/Target/Target.cpp === --- source/Target/Target.cpp +++ source/Target/Target.cpp @@ -1301,7 +1301,7 @@ os_ver_changed, env_changed); -if (!arch_changed && !vendor_changed && !os_changed) +if (!arch_changed && !vendor_changed && !os_changed && !env_changed) replace_local_arch = false; } } ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r264980 - Add --help and --long-help options to 'command alias' such that one can now specify a help string for an alias as they are defining it
Author: enrico
Date: Wed Mar 30 20:10:54 2016
New Revision: 264980
URL: http://llvm.org/viewvc/llvm-project?rev=264980&view=rev
Log:
Add --help and --long-help options to 'command alias' such that one can now
specify a help string for an alias as they are defining it
Modified:
lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py
lldb/trunk/source/Commands/CommandObjectCommands.cpp
Modified: lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py?rev=264980&r1=264979&r2=264980&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py Wed Mar 30
20:10:54 2016
@@ -198,3 +198,16 @@ class HelpCommandTestCase(TestBase):
"Try 'help' to see a current list of commands.",
"Try 'apropos thisisnotadebuggercommand' for a list of related
commands.",
"Try 'type lookup thisisnotadebuggercommand' for information on
types, methods, functions, modules, etc."])
+
+@no_debug_info_test
+def test_custom_help_alias(self):
+"""Test that aliases pick up custom help text."""
+def cleanup():
+self.runCmd('command unalias afriendlyalias', check=False)
+self.runCmd('command unalias averyfriendlyalias', check=False)
+
+self.addTearDownHook(cleanup)
+self.runCmd('command alias --help "I am a friendly alias" --
afriendlyalias help')
+self.expect("help afriendlyalias", matching=True, substrs = ['I am a
friendly alias'])
+self.runCmd('command alias --long-help "I am a very friendly alias" --
averyfriendlyalias help')
+self.expect("help averyfriendlyalias", matching=True, substrs = ['I am
a very friendly alias'])
Modified: lldb/trunk/source/Commands/CommandObjectCommands.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectCommands.cpp?rev=264980&r1=264979&r2=264980&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectCommands.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectCommands.cpp Wed Mar 30 20:10:54
2016
@@ -24,6 +24,7 @@
#include "lldb/Interpreter/CommandObjectRegexCommand.h"
#include "lldb/Interpreter/CommandReturnObject.h"
#include "lldb/Interpreter/OptionValueBoolean.h"
+#include "lldb/Interpreter/OptionValueString.h"
#include "lldb/Interpreter/OptionValueUInt64.h"
#include "lldb/Interpreter/Options.h"
#include "lldb/Interpreter/ScriptInterpreter.h"
@@ -430,13 +431,94 @@ static const char *g_python_command_inst
class CommandObjectCommandsAlias : public CommandObjectRaw
{
+protected:
+class CommandOptions : public OptionGroup
+{
+public:
+CommandOptions () :
+OptionGroup(),
+m_help(),
+m_long_help()
+{}
+
+~CommandOptions() override = default;
+
+uint32_t
+GetNumDefinitions () override
+{
+return 3;
+}
+
+const OptionDefinition*
+GetDefinitions () override
+{
+return g_option_table;
+}
+
+Error
+SetOptionValue (CommandInterpreter &interpreter,
+uint32_t option_idx,
+const char *option_value) override
+{
+Error error;
+
+const int short_option = g_option_table[option_idx].short_option;
+
+switch (short_option)
+{
+case 'h':
+m_help.SetCurrentValue(option_value);
+m_help.SetOptionWasSet();
+break;
+
+case 'H':
+m_long_help.SetCurrentValue(option_value);
+m_long_help.SetOptionWasSet();
+break;
+
+default:
+error.SetErrorStringWithFormat("invalid short option
character '%c'", short_option);
+break;
+}
+
+return error;
+}
+
+void
+OptionParsingStarting (CommandInterpreter &interpreter) override
+{
+m_help.Clear();
+m_long_help.Clear();
+}
+
+// Options table: Required for subclasses of Options.
+
+static OptionDefinition g_option_table[];
+OptionValueString m_help;
+OptionValueString m_long_help;
+};
+
+OptionGroupOptions m_option_group;
+CommandOptions m_command_options;
+
public:
+Options *
+GetOptions () override
+{
+return &m_option_group;
+}
+
CommandObjectCommandsAlias (CommandInterpreter &interpreter) :
[Lldb-commits] [PATCH] D18638: [LLDB][MIPS] Provide ABI string to compiler for appropriate code generation for MIPS
nitesh.jain created this revision.
nitesh.jain added reviewers: clayborg, ovyalov.
nitesh.jain added subscribers: jaydeep, bhushan, sagar, mohit.bhakkad,
lldb-commits.
These patch will set clang::TargetOptions::ABI and accordingly code will be
generated For MIPS target.
http://reviews.llvm.org/D18638
Files:
include/lldb/Core/ArchSpec.h
source/Core/ArchSpec.cpp
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -268,6 +268,7 @@
bool overridden_target_opts = false;
lldb_private::LanguageRuntime *lang_rt = nullptr;
lldb::TargetSP target_sp;
+std::string abi;
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
@@ -333,6 +334,11 @@
// This will be empty for any CPU that doesn't really need to make a
special CPU string.
m_compiler->getTargetOpts().CPU = target_arch.GetClangTargetCPU();
+// Set the target ABI
+abi = target_arch.GetClangTargetABI();
+if (!abi.empty())
+m_compiler->getTargetOpts().ABI=abi;
+
// 3. Now allow the runtime to provide custom configuration options for
the target.
// In this case, a specialized language runtime is available and we can
query it for extra options.
// For 99% of use cases, this will not be needed and should be provided
when basic platform detection is not enough.
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -505,6 +505,31 @@
}
std::string
+ArchSpec::GetClangTargetABI ()
+{ std::string abi;
+const llvm::Triple::ArchType machine = GetMachine();
+
+if (machine == llvm::Triple::mips ||
+machine == llvm::Triple::mipsel ||
+machine == llvm::Triple::mips64 ||
+machine == llvm::Triple::mips64el)
+{
+switch (GetFlags () & eMIPSABI_mask)
+{
+case eMIPSABI_N64:
+ abi = "n64"; break;
+case eMIPSABI_N32:
+ abi = "n32"; break;
+case eMIPSABI_O32:
+ abi = "o32"; break;
+default:
+ break;
+}
+}
+return abi;
+}
+
+std::string
ArchSpec::GetClangTargetCPU ()
{
std::string cpu;
Index: include/lldb/Core/ArchSpec.h
===
--- include/lldb/Core/ArchSpec.h
+++ include/lldb/Core/ArchSpec.h
@@ -298,6 +298,15 @@
GetClangTargetCPU ();
//--
+/// Returns a string representing current ABI
+///
+/// @return A string representing target ABI for the current
+/// architecture
+//-
+std::string
+GetClangTargetABI ();
+
+//--
/// Clears the object state.
///
/// Clears the object state back to a default invalid state.
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -268,6 +268,7 @@
bool overridden_target_opts = false;
lldb_private::LanguageRuntime *lang_rt = nullptr;
lldb::TargetSP target_sp;
+std::string abi;
if (exe_scope)
target_sp = exe_scope->CalculateTarget();
@@ -333,6 +334,11 @@
// This will be empty for any CPU that doesn't really need to make a special CPU string.
m_compiler->getTargetOpts().CPU = target_arch.GetClangTargetCPU();
+// Set the target ABI
+abi = target_arch.GetClangTargetABI();
+if (!abi.empty())
+m_compiler->getTargetOpts().ABI=abi;
+
// 3. Now allow the runtime to provide custom configuration options for the target.
// In this case, a specialized language runtime is available and we can query it for extra options.
// For 99% of use cases, this will not be needed and should be provided when basic platform detection is not enough.
Index: source/Core/ArchSpec.cpp
===
--- source/Core/ArchSpec.cpp
+++ source/Core/ArchSpec.cpp
@@ -505,6 +505,31 @@
}
std::string
+ArchSpec::GetClangTargetABI ()
+{ std::string abi;
+const llvm::Triple::ArchType machine = GetMachine();
+
+if (machine == llvm::Triple::mips ||
+machine == llvm::Triple::mipsel ||
+machine == llvm::Triple::mips64 ||
+machine == llvm::Triple::mips64el)
+{
+switch (GetFlags () & eMIPSABI_mask)
+{
+case eMIPSABI_N64:
+
