Re: [Lldb-commits] [PATCH] D15428: Make debug info specification use categories system

[Pavel Labath via lldb-commits]

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

The interaction between the `add_test_categories` and the "magic test 
multiplier" is causing problems, which is evident in the fact how you needed to 
add the `@skip` decorator to make it work.

It sounds like we need to decide what will be the "correct" interaction of the 
"test multiplier" and tests manually marked with a specific debug info.

I think the most sensible behavior would be to treat a manual debuginfo mark as 
a signal that you don't want your test to be auto-multiplied, the test 
multiplier could then check whether the test is already marked with one of the 
debuginfo annotations, and if it is, then avoid touching it.

What do you think?



Comment at: 
packages/Python/lldbsuite/test/functionalities/unwind/standard/TestStandardUnwind.py:120
@@ -119,3 +119,3 @@
 if f.endswith(".cpp") or f.endswith(".c"):
-@dwarf_test
+@add_test_categories("dwarf")
 @unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long 
running test")

You need `[]` around the `"dwarf"`. Otherwise, you will get errors here, when 
the skipIf below does not actually skip.


Comment at: 
packages/Python/lldbsuite/test/lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py:10
@@ +9,3 @@
+@add_test_categories("dwarf")
+@skipIf(debug_info=not_in(["dwarf"]))
+def test_limit_debug_info(self):

It should not be necessary to annotate and skip at the same time.


Comment at: packages/Python/lldbsuite/test/lldbtest.py:2226
@@ -2267,2 +2225,3 @@
 for attrname, attrvalue in attrs.items():
 if attrname.startswith("test") and not getattr(attrvalue, 
"__no_debug_info_test__", False):
+target_platform = 
lldb.DBG.GetSelectedPlatform().GetTriple().split('-')[2]

Here, we would then also check `getCategoriesForTest(attrvalue)` for presence 
of debug info markers. It looks like you will need to move that function from 
test_result.py to somewhere else though...


Comment at: packages/Python/lldbsuite/test/lldbtest.py:2230
@@ +2229,3 @@
+dont_do_dsym_test = any(platform in target_platform for 
platform in ["linux", "freebsd", "windows"])
+dont_do_dwo_test = any(platform in target_platform for 
platform in ["darwin", "macosx", "ios"])
+

might as well use `getDarwinOSTriples()` here


Comment at: packages/Python/lldbsuite/test/lldbtest.py:2233
@@ +2232,3 @@
+if not dont_do_dsym_test:
+@add_test_categories(["dsym"])
+@wraps(attrvalue)

This annotation will overwrite any previous category annotations that the user 
has previously added. I wasn't sure whether we wanted this behavior when I was 
writing the decorator, but now that we have these automatic categorizations, it 
definitely sounds like a bad idea. `add_test_categories` should really "add" 
categories to the test.

Since this is quite orthogonal to your patch, I'll whip up a separate patch to 
do that.


http://reviews.llvm.org/D15428



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

[Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Dec 11 05:05:24 2015
New Revision: 255335

URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
Log:
Revert "Turn on new test summary results by default."

The new test summary formatter does not honor the "expected timeout" markings, 
which makes our
buildbots all red. I'm switching it off by default until we figure out a way to 
make this work.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11 05:05:24 2015
@@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
 if args.results_formatter_options:
 configuration.results_formatter_options = 
args.results_formatter_options
 
-# Default to using the BasicResultsFormatter if no formatter is specified
-# and we're not a test inferior.
-if not args.inferior and configuration.results_formatter_name is None:
-configuration.results_formatter_name = (
-"lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
-
 if args.lldb_platform_name:
 configuration.lldb_platform_name = args.lldb_platform_name
 if args.lldb_platform_url:

Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec 11 
05:05:24 2015
@@ -683,9 +683,8 @@ class ResultsFormatter(object):
 
 if event_type == "terminate":
 self.terminate_called = True
-elif event_type in [
-EventBuilder.TYPE_TEST_RESULT,
-EventBuilder.TYPE_JOB_RESULT]:
+elif (event_type == EventBuilder.TYPE_TEST_RESULT or
+event_type == EventBuilder.TYPE_JOB_RESULT):
 # Keep track of event counts per test/job result status type.
 # The only job (i.e. inferior process) results that make it
 # here are ones that cannot be remapped to the most recently


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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

The high level architecture looks reasonable but there are a few think I would 
like you to clean up a bit:

- Several of your function uses a raw "new ...()" and then returns a pointer. 
Please put the data into a smart pointer (usually std::unique_ptr) and return 
that one instead to eliminate the risk of a memory leak.
- I added a bunch of inline comments. Most of them are minor style issues but 
there are some more significant ones (e.g. unused data structures)

How much advantage do you expect from this change from the users point of view? 
Do you think we should try to make clang produce .debug_macros section also?

In case of split dwarf gcc produces several .debug_macro.dwo section for each 
compile unit what won't work with your current implementation. I haven't 
checked the spec if gcc-s behavior is correct or not but it might be a good 
idea to support it (not necessary with this change). If you decide to not 
support split dwarf then please mark the test as XFAIL(dwo) also



Comment at: include/lldb/Symbol/DebugMacros.h:56
@@ +55,3 @@
+
+~DebugMacroEntry() { }
+

(nit): "= default" (for all other similar function also)


Comment at: include/lldb/Symbol/DebugMacros.h:131
@@ +130,3 @@
+else
+return NULL;
+}

(nit): Please use nullptr (for all other similar case also)


Comment at: include/lldb/Symbol/DebugMacros.h:137
@@ +136,3 @@
+
+std::vector m_macro_entries;
+};

What is the benefit of storing unique pointers in the vector compared to the 
objects itself?


Comment at: source/Expression/ExpressionSourceCode.cpp:106
@@ +105,3 @@
+void
+AddMacros(const DebugMacros *dm, AddMacroState &state, StreamString &stream)
+{

(nit): Please mark this function static and move it out from the anonymous 
namespace


Comment at: source/Expression/ExpressionSourceCode.cpp:122
@@ +121,3 @@
+else
+return;
+break;

Should this function return an error in this case so the caller know the macro 
stream is only half ready?


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.cpp:56-58
@@ +55,5 @@
+{
+lldb::offset_t new_offset, str_offset;
+uint64_t line;
+const char *macro_str;
+

(nit): Please initialize


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h:28
@@ +27,3 @@
+
+enum DWARFMacroHeaderFlagMask
+{

Please move this enum out from the global namespace (preferably into one of the 
class) as we are currently leaking both the enum name and the enum fields into 
the global namespace.


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h:38
@@ +37,3 @@
+public:
+class Entry
+{

(nit): struct


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h:47
@@ +46,3 @@
+public:
+uint8_t entry_count;
+std::map entry_map; // Mapping from opcode number to its 
entry.

(nit): Member variable names should start with "m_"


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h:48
@@ +47,3 @@
+uint8_t entry_count;
+std::map entry_map; // Mapping from opcode number to its 
entry.
+

Why do we need this data structure? Currently nobody is using it.
Also should we store DWARFFormValue instead of llvm::dwarf::Form here? It have 
a lot of feature in it what makes it work with split dwarf (dwo).


http://reviews.llvm.org/D15437



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

[Lldb-commits] [lldb] r255338 - [RenderScript] Support for amd64 RS hooks

[Ewan Crawford via lldb-commits]

Author: ewancrawford
Date: Fri Dec 11 07:49:21 2015
New Revision: 255338

URL: http://llvm.org/viewvc/llvm-project?rev=255338&view=rev
Log:
[RenderScript] Support for amd64 RS hooks

Adds support for reading a maximum of six integer arguments from a renderscript 
hook on X86_64.
Author: Luke Drummond 

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=255338&r1=255337&r2=255338&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 Fri Dec 11 07:49:21 2015
@@ -612,6 +612,16 @@ RenderScriptRuntime::HookCallback(Runtim
 bool
 RenderScriptRuntime::GetArgSimple(ExecutionContext &context, uint32_t arg, 
uint64_t *data)
 {
+// Get a positional integer argument.
+// Given an ExecutionContext, ``context`` which should be a RenderScript
+// frame, get the value of the positional argument ``arg`` and save its 
value
+// to the address pointed to by ``data``.
+// returns true on success, false otherwise.
+// If unsuccessful, the value pointed to by ``data`` is undefined. 
Otherwise,
+// ``data`` will be set to the value of the the given ``arg``.
+// NOTE: only natural width integer arguments for the machine are 
supported.
+// Behaviour with non primitive arguments is undefined.
+
 if (!data)
 return false;
 
@@ -640,7 +650,7 @@ RenderScriptRuntime::GetArgSimple(Execut
 if (error.Fail())
 {
 if (log)
-log->Printf ("RenderScriptRuntime:: GetArgSimple - error 
reading X86 stack: %s.", error.AsCString());
+log->Printf("RenderScriptRuntime::GetArgSimple - error 
reading X86 stack: %s.", error.AsCString());
 }
 else
 {
@@ -650,6 +660,35 @@ RenderScriptRuntime::GetArgSimple(Execut
 
 break;
 }
+case llvm::Triple::ArchType::x86_64:
+{
+// amd64 has 6 integer registers, and 8 XMM registers for 
parameter passing.
+// Surplus args are spilled onto the stack.
+// rdi, rsi, rdx, rcx, r8, r9, (zmm0 - 7 for vectors)
+// ref: AMD64 ABI Draft 0.99.6 – October 7, 2013 – 10:35; 
Figure 3.4. Retrieved from
+// http://www.x86-64.org/documentation/abi.pdf
+if (arg > 5)
+{
+if (log)
+log->Warning("X86_64 register spill is not supported.");
+break;
+}
+const char * regnames[] = {"rdi", "rsi", "rdx", "rcx", "r8", "r9"};
+assert((sizeof(regnames) / sizeof(const char *)) > arg);
+const RegisterInfo *rArg = 
reg_ctx->GetRegisterInfoByName(regnames[arg]);
+RegisterValue rVal;
+success = reg_ctx->ReadRegister(rArg, rVal);
+if (success)
+{
+*data = rVal.GetAsUInt64(0u, &success);
+}
+else
+{
+if (log)
+log->Printf("RenderScriptRuntime::GetArgSimple - error 
reading x86_64 register: %d.", arg);
+}
+break;
+}
 case llvm::Triple::ArchType::arm:
 {
 // arm 32 bit
@@ -660,12 +699,12 @@ RenderScriptRuntime::GetArgSimple(Execut
 success = reg_ctx->ReadRegister(rArg, rVal);
 if (success)
 {
-(*data) = rVal.GetAsUInt32();
+(*data) = rVal.GetAsUInt32(0u, &success);
 }
 else
 {
 if (log)
-log->Printf ("RenderScriptRuntime:: GetArgSimple - 
error reading ARM register: %d.", arg);
+log->Printf("RenderScriptRuntime::GetArgSimple - error 
reading ARM register: %d.", arg);
 }
 }
 else
@@ -676,7 +715,7 @@ RenderScriptRuntime::GetArgSimple(Execut
 if (error.Fail())
 {
 if (log)
-log->Printf ("RenderScriptRuntime:: GetArgSimple - 
error reading ARM stack: %s.", error.AsCString());
+log->Printf("RenderScriptRuntime::GetArgSimple - error 
reading ARM stack: %s.", error.AsCString());
 }
 else
 {
@@ -697,7 +736,7 @@ RenderScriptRuntime::GetArgSimple(Execut
 success = reg_ctx->ReadRegister(rArg, rVal);
 if (success)

[Lldb-commits] [PATCH] D15451: Make test categories composable

[Pavel Labath via lldb-commits]

labath created this revision.
labath added reviewers: zturner, tfiala, tberghammer.
labath added a subscriber: lldb-commits.

Previously the add_test_categories would simply overwrite the current set of 
categories for a
method. This change makes the decorator truly "add" categories, by extending 
the current set of
categories instead of replacing it.

To do this, I have:
- replaced the getCategories() property on a method (which was itself a 
method), with a simple
  list property "categories". This makes add_test_categories easier to 
implement, and test
  categories isn't something which should change between calls anyway.
- rewritten the getCategoriesForTest function to merge method categories with 
the categories of
  the test case. Previously, it would just use the method categories if they 
were present. I have
  also greatly simplified this method. Originally, it would use a lot of 
introspection to enable
  it being called on various types of objects. Based on my tests, it was only 
ever being called
  on a test case. The new function uses much less introspection then the 
preivous one, so we
  should easily catch any stray uses, if there are any, as they will generate 
exceptions now.

http://reviews.llvm.org/D15451

Files:
  packages/Python/lldbsuite/test/lldbtest.py
  packages/Python/lldbsuite/test/test_categories.py
  packages/Python/lldbsuite/test/test_result.py

Index: packages/Python/lldbsuite/test/test_result.py
===
--- packages/Python/lldbsuite/test/test_result.py
+++ packages/Python/lldbsuite/test/test_result.py
@@ -23,7 +23,7 @@
 
 # LLDB Modules
 import lldbsuite
-from . import configuration
+from . import configuration, test_categories
 from .result_formatter import EventBuilder
 
 
@@ -101,32 +101,14 @@
 else:
 return str(test)
 
-def getCategoriesForTest(self,test):
-if hasattr(test,"_testMethodName"):
-test_method = getattr(test,"_testMethodName")
-test_method = getattr(test,test_method)
-else:
-test_method = None
-if test_method != None and hasattr(test_method,"getCategories"):
-test_categories = test_method.getCategories(test)
-elif hasattr(test,"getCategories"):
-test_categories = test.getCategories()
-elif inspect.ismethod(test) and test.__self__ != None and hasattr(test.__self__,"getCategories"):
-test_categories = test.__self__.getCategories()
-else:
-test_categories = []
-if test_categories == None:
-test_categories = []
-return test_categories
-
 def hardMarkAsSkipped(self,test):
 getattr(test, test._testMethodName).__func__.__unittest_skip__ = True
 getattr(test, test._testMethodName).__func__.__unittest_skip_why__ = "test case does not fall in any category of interest for this run"
 test.__class__.__unittest_skip__ = True
 test.__class__.__unittest_skip_why__ = "test case does not fall in any category of interest for this run"
 
 def startTest(self, test):
-if configuration.shouldSkipBecauseOfCategories(self.getCategoriesForTest(test)):
+if configuration.shouldSkipBecauseOfCategories(test_categories.getCategoriesForTest(test)):
 self.hardMarkAsSkipped(test)
 configuration.setCrashInfoHook("%s at %s" % (str(test),inspect.getfile(test.__class__)))
 self.counter += 1
Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -3,6 +3,7 @@
 """
 
 from __future__ import absolute_import
+from __future__ import print_function
 
 # System modules
 import sys
@@ -53,3 +54,16 @@
 sys.exit(1)
 result.append(category)
 return result
+
+def getCategoriesForTest(test):
+"""
+Gets all the categories for the currently running test method in test case
+"""
+test_categories = []
+test_method = getattr(test, test._testMethodName)
+if test_method != None and hasattr(test_method, "categories"):
+test_categories.extend(test_method.categories)
+
+test_categories.extend(test.getCategories())
+
+return test_categories
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -507,12 +507,18 @@
 # Decorators for categorizing test cases.
 #
 from functools import wraps
+
 def add_test_categories(cat):
-"""Decorate an item with test categories"""
+"""Add test categories to a test item"""
 cat = test_categories.validate(cat, True)
 def impl(func):
-func.getCategories = lambda test: cat
+if isinstance(func, type) and issubclass(func, unittest2.TestCase):

Re: [Lldb-commits] [PATCH] D15451: Make test categories composable

[Pavel Labath via lldb-commits]

labath updated this revision to Diff 42522.
labath added a comment.

I've changed my mind and I'm moving back the getCategoriesForTest function into 
test_result.py.
The function only works when the test is currently executing (because of the 
magic
_testMethodName hack), so it's usability as a general utility function is very 
limited. Let's keep it here until we have a reason to do otherwise.


http://reviews.llvm.org/D15451

Files:
  packages/Python/lldbsuite/test/lldbtest.py
  packages/Python/lldbsuite/test/test_categories.py
  packages/Python/lldbsuite/test/test_result.py

Index: packages/Python/lldbsuite/test/test_result.py
===
--- packages/Python/lldbsuite/test/test_result.py
+++ packages/Python/lldbsuite/test/test_result.py
@@ -101,22 +101,17 @@
 else:
 return str(test)
 
-def getCategoriesForTest(self,test):
-if hasattr(test,"_testMethodName"):
-test_method = getattr(test,"_testMethodName")
-test_method = getattr(test,test_method)
-else:
-test_method = None
-if test_method != None and hasattr(test_method,"getCategories"):
-test_categories = test_method.getCategories(test)
-elif hasattr(test,"getCategories"):
-test_categories = test.getCategories()
-elif inspect.ismethod(test) and test.__self__ != None and 
hasattr(test.__self__,"getCategories"):
-test_categories = test.__self__.getCategories()
-else:
-test_categories = []
-if test_categories == None:
-test_categories = []
+def getCategoriesForTest(self, test):
+"""
+Gets all the categories for the currently running test method in test 
case
+"""
+test_categories = []
+test_method = getattr(test, test._testMethodName)
+if test_method != None and hasattr(test_method, "categories"):
+test_categories.extend(test_method.categories)
+
+test_categories.extend(test.getCategories())
+
 return test_categories
 
 def hardMarkAsSkipped(self,test):
Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -3,6 +3,7 @@
 """
 
 from __future__ import absolute_import
+from __future__ import print_function
 
 # System modules
 import sys
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -507,12 +507,18 @@
 # Decorators for categorizing test cases.
 #
 from functools import wraps
+
 def add_test_categories(cat):
-"""Decorate an item with test categories"""
+"""Add test categories to a test item"""
 cat = test_categories.validate(cat, True)
 def impl(func):
-func.getCategories = lambda test: cat
+if isinstance(func, type) and issubclass(func, unittest2.TestCase):
+raise Exception("@add_test_categories can only be used to decorate 
a test method")
+if hasattr(func, "categories"):
+cat.extend(func.categories)
+func.categories = cat
 return func
+
 return impl
 
 def benchmarks_test(func):


Index: packages/Python/lldbsuite/test/test_result.py
===
--- packages/Python/lldbsuite/test/test_result.py
+++ packages/Python/lldbsuite/test/test_result.py
@@ -101,22 +101,17 @@
 else:
 return str(test)
 
-def getCategoriesForTest(self,test):
-if hasattr(test,"_testMethodName"):
-test_method = getattr(test,"_testMethodName")
-test_method = getattr(test,test_method)
-else:
-test_method = None
-if test_method != None and hasattr(test_method,"getCategories"):
-test_categories = test_method.getCategories(test)
-elif hasattr(test,"getCategories"):
-test_categories = test.getCategories()
-elif inspect.ismethod(test) and test.__self__ != None and hasattr(test.__self__,"getCategories"):
-test_categories = test.__self__.getCategories()
-else:
-test_categories = []
-if test_categories == None:
-test_categories = []
+def getCategoriesForTest(self, test):
+"""
+Gets all the categories for the currently running test method in test case
+"""
+test_categories = []
+test_method = getattr(test, test._testMethodName)
+if test_method != None and hasattr(test_method, "categories"):
+test_categories.extend(test_method.categories)
+
+test_categories.extend(test.getCategories())
+
 return test_categories
 
 def hardMarkAsSkipped(self,test):
Index: p

[Lldb-commits] [lldb] r255340 - Change finishSwigPythonLLDB.py to copy six.py instead of simlink it

[Ted Woodward via lldb-commits]

Author: ted
Date: Fri Dec 11 09:43:36 2015
New Revision: 255340

URL: http://llvm.org/viewvc/llvm-project?rev=255340&view=rev
Log:
Change finishSwigPythonLLDB.py to copy six.py instead of simlink it

Summary: If six.py is simlink'd, an installation won't be able to find it 
unless it has access to the source tree that lldb was built from.

Reviewers: zturner

Subscribers: lldb-commits

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

Modified:
lldb/trunk/scripts/Python/finishSwigPythonLLDB.py

Modified: lldb/trunk/scripts/Python/finishSwigPythonLLDB.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/finishSwigPythonLLDB.py?rev=255340&r1=255339&r2=255340&view=diff
==
--- lldb/trunk/scripts/Python/finishSwigPythonLLDB.py (original)
+++ lldb/trunk/scripts/Python/finishSwigPythonLLDB.py Fri Dec 11 09:43:36 2015
@@ -70,6 +70,8 @@ strErrMsgCreatePyPkgMissingSlash = "Para
 strErrMsgMkLinkExecute = "Command mklink failed: %s"
 strErrMsgMakeSymlink = "creating symbolic link"
 strErrMsgUnexpected = "Unexpected error: %s"
+strMsgCopySixPy = "Copying six.py from '%s' to '%s'"
+strErrMsgCopySixPyFailed = "Unable to copy '%s' to '%s'"
 
 def is_debug_interpreter():
 return hasattr(sys, 'gettotalrefcount')
@@ -336,14 +338,6 @@ def make_symlink(vDictArgs, vstrFramewor
 
 return make_symlink_native(vDictArgs, strSrc, strTarget)
 
-def make_symlink_six(vDictArgs, vstrFrameworkPythonDir):
-dbg = utilsDebug.CDebugFnVerbose("Python script make_symlink_six()")
-site_packages_dir = os.path.dirname(vstrFrameworkPythonDir)
-six_module_filename = "six.py"
-src_file = os.path.join(vDictArgs['--srcRoot'], "third_party", "Python", 
"module", "six", six_module_filename)
-src_file = os.path.normpath(src_file)
-target = os.path.join(site_packages_dir, six_module_filename)
-return make_symlink_native(vDictArgs, src_file, target)
 
 #++---
 # Details:  Make the symbolic that the script bridge for Python will need in
@@ -472,9 +466,6 @@ def create_symlinks(vDictArgs, vstrFrame
   vstrFrameworkPythonDir,
   strLibLldbFileName)
 
-if bOk:
-bOk, strErrMsg = make_symlink_six(vDictArgs, vstrFrameworkPythonDir)
-
 # Make symlink for darwin-debug on Darwin
 strDarwinDebugFileName = "darwin-debug"
 if bOk and eOSType == utilsOsType.EnumOsType.Darwin:
@@ -491,6 +482,27 @@ def create_symlinks(vDictArgs, vstrFrame
 
 return (bOk, strErrMsg)
 
+def copy_six(vDictArgs, vstrFrameworkPythonDir):
+dbg = utilsDebug.CDebugFnVerbose("Python script copy_six()")
+bDbg = "-d" in vDictArgs
+bOk = True
+strMsg = ""
+site_packages_dir = os.path.dirname(vstrFrameworkPythonDir)
+six_module_filename = "six.py"
+src_file = os.path.join(vDictArgs['--srcRoot'], "third_party", "Python", 
"module", "six", six_module_filename)
+src_file = os.path.normpath(src_file)
+target = os.path.join(site_packages_dir, six_module_filename)
+
+if bDbg:
+print((strMsgCopySixPy % (src_file, target)))
+try:
+shutil.copyfile(src_file, target)
+except:
+bOk = False
+strMsg = strErrMsgCopySixPyFailed % (src_file, target)
+
+return (bOk, strMsg)
+
 #++---
 # Details:  Look for the directory in which to put the Python files if it
 #   does not already exist, attempt to make it.
@@ -708,6 +720,9 @@ def main(vDictArgs):
 bOk, strMsg = create_symlinks(vDictArgs, strFrameworkPythonDir)
 
 if bOk:
+bOk, strMsg = copy_six(vDictArgs, strFrameworkPythonDir)
+
+if bOk:
 bOk, strMsg = copy_lldbpy_file_to_lldb_pkg_dir(vDictArgs,
strFrameworkPythonDir,
strCfgBldDir)


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

[Lldb-commits] [lldb] r255341 - XFAIL TestLoadUnload for Windows->Android

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Dec 11 10:16:51 2015
New Revision: 255341

URL: http://llvm.org/viewvc/llvm-project?rev=255341&view=rev
Log:
XFAIL TestLoadUnload for Windows->Android

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py?rev=255341&r1=255340&r2=255341&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
 Fri Dec 11 10:16:51 2015
@@ -180,6 +180,7 @@ class LoadUnloadTestCase(TestBase):
 # This time, the hidden library should be picked up.
 self.expect("run", substrs=["return", "12345"])
 
+@expectedFailureAll(bugnumber="llvm.org/pr25805", hostoslist=["windows"], 
compiler="gcc", archs=["i386"], triple='.*-android')
 @skipIfFreeBSD # llvm.org/pr14424 - missing FreeBSD Makefiles/testcase 
support
 @skipUnlessListedRemote(['android'])
 @skipIfWindows # Windows doesn't have dlopen and friends, dynamic 
libraries work differently


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

[Lldb-commits] [lldb] r255342 - Create test for llvm.org/pr25806

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Fri Dec 11 10:24:14 2015
New Revision: 255342

URL: http://llvm.org/viewvc/llvm-project?rev=255342&view=rev
Log:
Create test for llvm.org/pr25806

LLDB don't detect the loading of a shared object file linked against the
main executable before the static initializers are executed for the
given module. Because of this it is not possible to get breakpoint hits
in these static initializers and to display proper debug info in case of
a crash in these codes.

Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/a.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/a.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/b.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/b.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/c.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/c.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/d.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/d.c

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/hidden/d.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/hidden/d.c

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/main.cpp
  - copied, changed from r255341, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/main.c
Removed:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/a.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/b.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/c.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/d.c

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/hidden/d.c
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/main.c
Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/a.mk
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/b.mk
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/c.mk
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/d.mk

lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/hidden/Makefile

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/Makefile?rev=255342&r1=255341&r2=255342&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/Makefile 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/Makefile 
Fri Dec 11 10:24:14 2015
@@ -3,7 +3,7 @@ LEVEL := ../../make
 LIB_PREFIX := loadunload_
 
 LD_EXTRAS := -L. -l$(LIB_PREFIX)d -ldl
-C_SOURCES := main.c
+CXX_SOURCES := main.cpp
 
 include $(LEVEL)/Makefile.rules
 

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py?rev=255342&r1=255341&r2=255342&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
 Fri Dec 11 10:24:14 2015
@@ -24,9 +24,9 @@ class LoadUnloadTestCase(TestBase):
 # Call super's setUp().
 TestBase.setUp(self)
 # Find the line number to break for main.cpp.
-self.line = line_number('main.c',
+self.line = line_number('main.cpp',
 '// Set break point at this line for 
test_lldb_process_load_and_unload_commands().')
-self.line_d_function = line_number('d.c',
+self.line_d_function = line_number('d.cpp',
'// Find this line number within 
d_dunction().')
 if not self.platformIsDarwin():
 if not lldb.remote_platform and "LD_LIBRARY_PATH" in os.environ:
@@ -164,7 +164,7 @@ class LoadUnloadTestCase(TestBase):
 substrs = [os.path.basename(old_dylib)],
 matching=True)
 
-lldbutil.run_break_set_by_file_and_line (self, "d.c", 
self.line_d_function, num_expe

Re: [Lldb-commits] [PATCH] D15451: Make test categories composable

[Tamas Berghammer via lldb-commits]

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

LGTM



Comment at: packages/Python/lldbsuite/test/lldbtest.py:512
@@ -510,3 +511,3 @@
 def add_test_categories(cat):
-"""Decorate an item with test categories"""
+"""Add test categories to a test item"""
 cat = test_categories.validate(cat, True)

Can you be more specific about where can we add this decorator? "item" doesn't 
really tell anything to me


http://reviews.llvm.org/D15451



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

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Todd Fiala via lldb-commits]

"Expected timeout" - that concept is ridiculous.

Why not increase the timeout?

-Todd

On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: labath
> Date: Fri Dec 11 05:05:24 2015
> New Revision: 255335
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
> Log:
> Revert "Turn on new test summary results by default."
>
> The new test summary formatter does not honor the "expected timeout"
> markings, which makes our
> buildbots all red. I'm switching it off by default until we figure out a
> way to make this work.
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
> 05:05:24 2015
> @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
>  if args.results_formatter_options:
>  configuration.results_formatter_options =
> args.results_formatter_options
>
> -# Default to using the BasicResultsFormatter if no formatter is
> specified
> -# and we're not a test inferior.
> -if not args.inferior and configuration.results_formatter_name is None:
> -configuration.results_formatter_name = (
> -
> "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
> -
>  if args.lldb_platform_name:
>  configuration.lldb_platform_name = args.lldb_platform_name
>  if args.lldb_platform_url:
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
> (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec
> 11 05:05:24 2015
> @@ -683,9 +683,8 @@ class ResultsFormatter(object):
>
>  if event_type == "terminate":
>  self.terminate_called = True
> -elif event_type in [
> -EventBuilder.TYPE_TEST_RESULT,
> -EventBuilder.TYPE_JOB_RESULT]:
> +elif (event_type == EventBuilder.TYPE_TEST_RESULT or
> +event_type == EventBuilder.TYPE_JOB_RESULT):
>  # Keep track of event counts per test/job result status
> type.
>  # The only job (i.e. inferior process) results that make
> it
>  # here are ones that cannot be remapped to the most
> recently
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>



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

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Todd Fiala via lldb-commits]

I think this (the expected timeout) will go away once I'm done with the
low-load, single-worker follow up pass, fwiw.  If that is not the case, we
should be disabling tests that intermittently timeout for reasons other
than high load.

On Fri, Dec 11, 2015 at 9:21 AM, Todd Fiala  wrote:

> "Expected timeout" - that concept is ridiculous.
>
> Why not increase the timeout?
>
> -Todd
>
> On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: labath
>> Date: Fri Dec 11 05:05:24 2015
>> New Revision: 255335
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
>> Log:
>> Revert "Turn on new test summary results by default."
>>
>> The new test summary formatter does not honor the "expected timeout"
>> markings, which makes our
>> buildbots all red. I'm switching it off by default until we figure out a
>> way to make this work.
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>> lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>>
>> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
>> 05:05:24 2015
>> @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
>>  if args.results_formatter_options:
>>  configuration.results_formatter_options =
>> args.results_formatter_options
>>
>> -# Default to using the BasicResultsFormatter if no formatter is
>> specified
>> -# and we're not a test inferior.
>> -if not args.inferior and configuration.results_formatter_name is
>> None:
>> -configuration.results_formatter_name = (
>> -
>> "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
>> -
>>  if args.lldb_platform_name:
>>  configuration.lldb_platform_name = args.lldb_platform_name
>>  if args.lldb_platform_url:
>>
>> Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>> (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec
>> 11 05:05:24 2015
>> @@ -683,9 +683,8 @@ class ResultsFormatter(object):
>>
>>  if event_type == "terminate":
>>  self.terminate_called = True
>> -elif event_type in [
>> -EventBuilder.TYPE_TEST_RESULT,
>> -EventBuilder.TYPE_JOB_RESULT]:
>> +elif (event_type == EventBuilder.TYPE_TEST_RESULT or
>> +event_type == EventBuilder.TYPE_JOB_RESULT):
>>  # Keep track of event counts per test/job result status
>> type.
>>  # The only job (i.e. inferior process) results that make
>> it
>>  # here are ones that cannot be remapped to the most
>> recently
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Todd Fiala via lldb-commits]

(And by ridiculous, I mean the idea of having something time out, and
having that be an expected condition just to keep the test red, is a heavy
indication that something else needs to change --- feels like a bandaid on
top of a bad patch job --- something I think we want to address at a more
holistic level, which hopefully the low load test pass will help.  I think
increasing the timeout would be a better way to handle that in the short
term).

On Fri, Dec 11, 2015 at 9:22 AM, Todd Fiala  wrote:

> I think this (the expected timeout) will go away once I'm done with the
> low-load, single-worker follow up pass, fwiw.  If that is not the case, we
> should be disabling tests that intermittently timeout for reasons other
> than high load.
>
> On Fri, Dec 11, 2015 at 9:21 AM, Todd Fiala  wrote:
>
>> "Expected timeout" - that concept is ridiculous.
>>
>> Why not increase the timeout?
>>
>> -Todd
>>
>> On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: labath
>>> Date: Fri Dec 11 05:05:24 2015
>>> New Revision: 255335
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
>>> Log:
>>> Revert "Turn on new test summary results by default."
>>>
>>> The new test summary formatter does not honor the "expected timeout"
>>> markings, which makes our
>>> buildbots all red. I'm switching it off by default until we figure out a
>>> way to make this work.
>>>
>>> Modified:
>>> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>> lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>>>
>>> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff
>>>
>>> ==
>>> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>>> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
>>> 05:05:24 2015
>>> @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
>>>  if args.results_formatter_options:
>>>  configuration.results_formatter_options =
>>> args.results_formatter_options
>>>
>>> -# Default to using the BasicResultsFormatter if no formatter is
>>> specified
>>> -# and we're not a test inferior.
>>> -if not args.inferior and configuration.results_formatter_name is
>>> None:
>>> -configuration.results_formatter_name = (
>>> -
>>> "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
>>> -
>>>  if args.lldb_platform_name:
>>>  configuration.lldb_platform_name = args.lldb_platform_name
>>>  if args.lldb_platform_url:
>>>
>>> Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff
>>>
>>> ==
>>> --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>>> (original)
>>> +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri
>>> Dec 11 05:05:24 2015
>>> @@ -683,9 +683,8 @@ class ResultsFormatter(object):
>>>
>>>  if event_type == "terminate":
>>>  self.terminate_called = True
>>> -elif event_type in [
>>> -EventBuilder.TYPE_TEST_RESULT,
>>> -EventBuilder.TYPE_JOB_RESULT]:
>>> +elif (event_type == EventBuilder.TYPE_TEST_RESULT or
>>> +event_type == EventBuilder.TYPE_JOB_RESULT):
>>>  # Keep track of event counts per test/job result status
>>> type.
>>>  # The only job (i.e. inferior process) results that
>>> make it
>>>  # here are ones that cannot be remapped to the most
>>> recently
>>>
>>>
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Todd Fiala via lldb-commits]

FWIW we bumped up the default OS X timeout from 4 to 6 minutes to address
the same kind of thing, and that got rid of almost all of the timeouts we
see here on 4-core machines running the test suite.

On Fri, Dec 11, 2015 at 9:24 AM, Todd Fiala  wrote:

> (And by ridiculous, I mean the idea of having something time out, and
> having that be an expected condition just to keep the test red, is a heavy
> indication that something else needs to change --- feels like a bandaid on
> top of a bad patch job --- something I think we want to address at a more
> holistic level, which hopefully the low load test pass will help.  I think
> increasing the timeout would be a better way to handle that in the short
> term).
>
> On Fri, Dec 11, 2015 at 9:22 AM, Todd Fiala  wrote:
>
>> I think this (the expected timeout) will go away once I'm done with the
>> low-load, single-worker follow up pass, fwiw.  If that is not the case, we
>> should be disabling tests that intermittently timeout for reasons other
>> than high load.
>>
>> On Fri, Dec 11, 2015 at 9:21 AM, Todd Fiala  wrote:
>>
>>> "Expected timeout" - that concept is ridiculous.
>>>
>>> Why not increase the timeout?
>>>
>>> -Todd
>>>
>>> On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Author: labath
 Date: Fri Dec 11 05:05:24 2015
 New Revision: 255335

 URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
 Log:
 Revert "Turn on new test summary results by default."

 The new test summary formatter does not honor the "expected timeout"
 markings, which makes our
 buildbots all red. I'm switching it off by default until we figure out
 a way to make this work.

 Modified:
 lldb/trunk/packages/Python/lldbsuite/test/dotest.py
 lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

 Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff

 ==
 --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
 +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
 05:05:24 2015
 @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
  if args.results_formatter_options:
  configuration.results_formatter_options =
 args.results_formatter_options

 -# Default to using the BasicResultsFormatter if no formatter is
 specified
 -# and we're not a test inferior.
 -if not args.inferior and configuration.results_formatter_name is
 None:
 -configuration.results_formatter_name = (
 -
 "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
 -
  if args.lldb_platform_name:
  configuration.lldb_platform_name = args.lldb_platform_name
  if args.lldb_platform_url:

 Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff

 ==
 --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
 (original)
 +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri
 Dec 11 05:05:24 2015
 @@ -683,9 +683,8 @@ class ResultsFormatter(object):

  if event_type == "terminate":
  self.terminate_called = True
 -elif event_type in [
 -EventBuilder.TYPE_TEST_RESULT,
 -EventBuilder.TYPE_JOB_RESULT]:
 +elif (event_type == EventBuilder.TYPE_TEST_RESULT or
 +event_type == EventBuilder.TYPE_JOB_RESULT):
  # Keep track of event counts per test/job result
 status type.
  # The only job (i.e. inferior process) results that
 make it
  # here are ones that cannot be remapped to the most
 recently


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

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Pavel Labath via lldb-commits]

The concept is not there to protect against timeouts, which are caused
by processes being too slow, for these we have been increasing
timeouts where necessary. This is there to guard against hangs in the
test suite (so the name might not be most fortunate, it would be
something like "excpected deadlock"), where increasing the timeout
does not help. E.g. TestEvents takes 4 seconds normally, but it does
deadlock quite often even with the 4m timeout, as you can see from the
redness. I have been trying to fix these, and the number are going
down, but I just don't have enough time to address them all (for now).

I don't find the concept per se that ridiculous, I think it is a good
idea to be able to mark any failure mode as "expected", to prevent
long red streaks on the buildbot (btw, I haven't checked, is it
possible to XFAIL crashes now?), although the current code that does
that is horrible.


On 11 December 2015 at 17:24, Todd Fiala  wrote:
> (And by ridiculous, I mean the idea of having something time out, and having
> that be an expected condition just to keep the test red, is a heavy
> indication that something else needs to change --- feels like a bandaid on
> top of a bad patch job --- something I think we want to address at a more
> holistic level, which hopefully the low load test pass will help.  I think
> increasing the timeout would be a better way to handle that in the short
> term).
>
> On Fri, Dec 11, 2015 at 9:22 AM, Todd Fiala  wrote:
>>
>> I think this (the expected timeout) will go away once I'm done with the
>> low-load, single-worker follow up pass, fwiw.  If that is not the case, we
>> should be disabling tests that intermittently timeout for reasons other than
>> high load.
>>
>> On Fri, Dec 11, 2015 at 9:21 AM, Todd Fiala  wrote:
>>>
>>> "Expected timeout" - that concept is ridiculous.
>>>
>>> Why not increase the timeout?
>>>
>>> -Todd
>>>
>>> On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits
>>>  wrote:

 Author: labath
 Date: Fri Dec 11 05:05:24 2015
 New Revision: 255335

 URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
 Log:
 Revert "Turn on new test summary results by default."

 The new test summary formatter does not honor the "expected timeout"
 markings, which makes our
 buildbots all red. I'm switching it off by default until we figure out a
 way to make this work.

 Modified:
 lldb/trunk/packages/Python/lldbsuite/test/dotest.py
 lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

 Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff

 ==
 --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
 +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
 05:05:24 2015
 @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
  if args.results_formatter_options:
  configuration.results_formatter_options =
 args.results_formatter_options

 -# Default to using the BasicResultsFormatter if no formatter is
 specified
 -# and we're not a test inferior.
 -if not args.inferior and configuration.results_formatter_name is
 None:
 -configuration.results_formatter_name = (
 -
 "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
 -
  if args.lldb_platform_name:
  configuration.lldb_platform_name = args.lldb_platform_name
  if args.lldb_platform_url:

 Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff

 ==
 --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
 (original)
 +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri
 Dec 11 05:05:24 2015
 @@ -683,9 +683,8 @@ class ResultsFormatter(object):

  if event_type == "terminate":
  self.terminate_called = True
 -elif event_type in [
 -EventBuilder.TYPE_TEST_RESULT,
 -EventBuilder.TYPE_JOB_RESULT]:
 +elif (event_type == EventBuilder.TYPE_TEST_RESULT or
 +event_type == EventBuilder.TYPE_JOB_RESULT):
  # Keep track of event counts per test/job result status
 type.
  # The only job (i.e. inferior process) results that
 make it
  # here are ones that cannot be remapped to the most
 recently


 

Re: [Lldb-commits] [lldb] r255335 - Revert "Turn on new test summary results by default."

[Todd Fiala via lldb-commits]

(Sorry Pavel, missed your lldb-dev post on this.  See my comments there.
I'll pick it up there).

On Fri, Dec 11, 2015 at 9:36 AM, Pavel Labath  wrote:

> The concept is not there to protect against timeouts, which are caused
> by processes being too slow, for these we have been increasing
> timeouts where necessary. This is there to guard against hangs in the
> test suite (so the name might not be most fortunate, it would be
> something like "excpected deadlock"), where increasing the timeout
> does not help. E.g. TestEvents takes 4 seconds normally, but it does
> deadlock quite often even with the 4m timeout, as you can see from the
> redness. I have been trying to fix these, and the number are going
> down, but I just don't have enough time to address them all (for now).
>
> I don't find the concept per se that ridiculous, I think it is a good
> idea to be able to mark any failure mode as "expected", to prevent
> long red streaks on the buildbot (btw, I haven't checked, is it
> possible to XFAIL crashes now?), although the current code that does
> that is horrible.
>
>
> On 11 December 2015 at 17:24, Todd Fiala  wrote:
> > (And by ridiculous, I mean the idea of having something time out, and
> having
> > that be an expected condition just to keep the test red, is a heavy
> > indication that something else needs to change --- feels like a bandaid
> on
> > top of a bad patch job --- something I think we want to address at a more
> > holistic level, which hopefully the low load test pass will help.  I
> think
> > increasing the timeout would be a better way to handle that in the short
> > term).
> >
> > On Fri, Dec 11, 2015 at 9:22 AM, Todd Fiala 
> wrote:
> >>
> >> I think this (the expected timeout) will go away once I'm done with the
> >> low-load, single-worker follow up pass, fwiw.  If that is not the case,
> we
> >> should be disabling tests that intermittently timeout for reasons other
> than
> >> high load.
> >>
> >> On Fri, Dec 11, 2015 at 9:21 AM, Todd Fiala 
> wrote:
> >>>
> >>> "Expected timeout" - that concept is ridiculous.
> >>>
> >>> Why not increase the timeout?
> >>>
> >>> -Todd
> >>>
> >>> On Fri, Dec 11, 2015 at 3:06 AM, Pavel Labath via lldb-commits
> >>>  wrote:
> 
>  Author: labath
>  Date: Fri Dec 11 05:05:24 2015
>  New Revision: 255335
> 
>  URL: http://llvm.org/viewvc/llvm-project?rev=255335&view=rev
>  Log:
>  Revert "Turn on new test summary results by default."
> 
>  The new test summary formatter does not honor the "expected timeout"
>  markings, which makes our
>  buildbots all red. I'm switching it off by default until we figure
> out a
>  way to make this work.
> 
>  Modified:
>  lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>  lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
> 
>  Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>  URL:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255335&r1=255334&r2=255335&view=diff
> 
> 
> ==
>  --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
>  +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
>  05:05:24 2015
>  @@ -407,12 +407,6 @@ def parseOptionsAndInitTestdirs():
>   if args.results_formatter_options:
>   configuration.results_formatter_options =
>  args.results_formatter_options
> 
>  -# Default to using the BasicResultsFormatter if no formatter is
>  specified
>  -# and we're not a test inferior.
>  -if not args.inferior and configuration.results_formatter_name is
>  None:
>  -configuration.results_formatter_name = (
>  -
>  "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
>  -
>   if args.lldb_platform_name:
>   configuration.lldb_platform_name = args.lldb_platform_name
>   if args.lldb_platform_url:
> 
>  Modified:
> lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>  URL:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255335&r1=255334&r2=255335&view=diff
> 
> 
> ==
>  --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>  (original)
>  +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri
>  Dec 11 05:05:24 2015
>  @@ -683,9 +683,8 @@ class ResultsFormatter(object):
> 
>   if event_type == "terminate":
>   self.terminate_called = True
>  -elif event_type in [
>  -EventBuilder.TYPE_TEST_RESULT,
>  -EventBuilder.TYPE_JOB_RESULT]:
>  +elif (event_type == EventBu

Re: [Lldb-commits] [PATCH] D15428: Make debug info specification use categories system

[Zachary Turner via lldb-commits]

zturner added a comment.

In http://reviews.llvm.org/D15428#308131, @labath wrote:

> The interaction between the `add_test_categories` and the "magic test 
> multiplier" is causing problems, which is evident in the fact how you needed 
> to add the `@skip` decorator to make it work.
>
> It sounds like we need to decide what will be the "correct" interaction of 
> the "test multiplier" and tests manually marked with a specific debug info.
>
> I think the most sensible behavior would be to treat a manual debuginfo mark 
> as a signal that you don't want your test to be auto-multiplied, the test 
> multiplier could then check whether the test is already marked with one of 
> the debuginfo annotations, and if it is, then avoid touching it.


In hindsight I wonder if I even needed to manually mark the test with a debug 
info.  Maybe we can say that tests should *never* be manually marked with a 
debug info category, and only use the skip decorators.  That should still work, 
because it will be auto-multiplied to every debug format, and then some of them 
will be skipped.


http://reviews.llvm.org/D15428



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

[Lldb-commits] [lldb] r255351 - Add test event marking a test as explicitly eligible for rerun if it is marked flakey.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Fri Dec 11 12:06:47 2015
New Revision: 255351

URL: http://llvm.org/viewvc/llvm-project?rev=255351&view=rev
Log:
Add test event marking a test as explicitly eligible for rerun if it is marked 
flakey.

This will be used in a future change to support rerunning flakey tests
that hit a test result isue in a low-load, single worker test runner phase.

This is implemented as an additive-style event rather than being
evaluated and added to the start_test event because the decorator code
only runs after the start_test event is created and sent.  i.e.
LLDBTestResult.startTest() runs before the test method decorators run.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
lldb/trunk/packages/Python/lldbsuite/test/test_result.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=255351&r1=255350&r2=255351&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Fri Dec 11 12:06:47 
2015
@@ -63,6 +63,8 @@ from . import lldbtest_config
 from . import lldbutil
 from . import test_categories
 
+from .result_formatter import EventBuilder
+
 # dosep.py starts lots and lots of dotest instances
 # This option helps you find if two (or more) dotest instances are using the 
same
 # directory at the same time
@@ -784,6 +786,12 @@ def expectedFlakey(expected_fn, bugnumbe
 def wrapper(*args, **kwargs):
 from unittest2 import case
 self = args[0]
+if expected_fn(self):
+# Send event marking test as explicitly eligible for rerunning.
+if configuration.results_formatter_object is not None:
+# Mark this test as rerunnable.
+configuration.results_formatter_object.handle_event(
+EventBuilder.event_for_mark_test_rerun_eligible(self))
 try:
 func(*args, **kwargs)
 # don't retry if the test case is already decorated with xfail or 
skip

Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255351&r1=255350&r2=255351&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec 11 
12:06:47 2015
@@ -161,6 +161,7 @@ class EventBuilder(object):
 TYPE_JOB_RESULT = "job_result"
 TYPE_TEST_RESULT = "test_result"
 TYPE_TEST_START = "test_start"
+TYPE_MARK_TEST_RERUN_ELIGIBLE = "test_eligible_for_rerun"
 
 # Test/Job Status Tags
 STATUS_EXCEPTIONAL_EXIT = "exceptional_exit"
@@ -226,6 +227,7 @@ class EventBuilder(object):
 "test_name": test_name,
 "test_filename": inspect.getfile(test.__class__)
 })
+
 return event
 
 @staticmethod
@@ -486,6 +488,26 @@ class EventBuilder(object):
 return event
 
 @staticmethod
+def event_for_mark_test_rerun_eligible(test):
+"""Creates an event that indicates the specified test is explicitly
+eligible for rerun.
+
+Note there is a mode that will enable test rerun eligibility at the
+global level.  These markings for explicit rerun eligibility are
+intended for the mode of running where only explicitly rerunnable
+tests are rerun upon hitting an issue.
+
+@param test the TestCase instance to which this pertains.
+
+@return an event that specifies the given test as being eligible to
+be rerun.
+"""
+event = EventBuilder._event_dictionary_common(
+test,
+EventBuilder.TYPE_MARK_TEST_RERUN_ELIGIBLE)
+return event
+
+@staticmethod
 def add_entries_to_all_events(entries_dict):
 """Specifies a dictionary of entries to add to all test events.
 

Modified: lldb/trunk/packages/Python/lldbsuite/test/test_result.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/test_result.py?rev=255351&r1=255350&r2=255351&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/test_result.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/test_result.py Fri Dec 11 
12:06:47 2015
@@ -13,10 +13,6 @@ from __future__ import print_function
 
 # System modules
 import inspect
-import os
-import platform
-import subprocess
-
 
 # Third-party modules
 import unittest2


___
lldb-commits mailing list
lldb-commits@lists.l

[Lldb-commits] [PATCH] D15457: Remove hardcoded registers from Hexagon ABI

[Ted Woodward via lldb-commits]

ted created this revision.
ted added a reviewer: clayborg.
ted added a subscriber: lldb-commits.

The Hexagon ABI plugin uses hardcoded registers when setting up function calls. 
This is OK for the Hexagon simulator, but the register numbers are different on 
the gdbserver running on hardware. Change the hardcoded registers to LLDB 
generic registers.

http://reviews.llvm.org/D15457

Files:
  source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp

Index: source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
===
--- source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
+++ source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
@@ -226,7 +226,7 @@
 //  . handle 64bit values and their register / stack requirements
 
 */
-#define HEX_ABI_DEBUG 1
+#define HEX_ABI_DEBUG 0
 bool
 ABISysV_hexagon::PrepareTrivialCall ( Thread &thread, 
   lldb::addr_t  sp  , 
@@ -323,10 +323,12 @@
 }
 
 // update registers with current function call state
-reg_ctx->WriteRegisterFromUnsigned ( 41, pc );
-reg_ctx->WriteRegisterFromUnsigned ( 31, ra );
-reg_ctx->WriteRegisterFromUnsigned ( 29, sp );
-//  reg_ctx->WriteRegisterFromUnsigned ( FP ??? );
+uint32_t pc_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+reg_ctx->WriteRegisterFromUnsigned(pc_reg, pc);
+uint32_t ra_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_RA);
+reg_ctx->WriteRegisterFromUnsigned(ra_reg, ra);
+uint32_t sp_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_SP);
+reg_ctx->WriteRegisterFromUnsigned(sp_reg, sp);
 
 #if HEX_ABI_DEBUG
 // quick and dirty stack dumper for debugging


Index: source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
===
--- source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
+++ source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
@@ -226,7 +226,7 @@
 //  . handle 64bit values and their register / stack requirements
 
 */
-#define HEX_ABI_DEBUG 1
+#define HEX_ABI_DEBUG 0
 bool
 ABISysV_hexagon::PrepareTrivialCall ( Thread &thread, 
   lldb::addr_t  sp  , 
@@ -323,10 +323,12 @@
 }
 
 // update registers with current function call state
-reg_ctx->WriteRegisterFromUnsigned ( 41, pc );
-reg_ctx->WriteRegisterFromUnsigned ( 31, ra );
-reg_ctx->WriteRegisterFromUnsigned ( 29, sp );
-//  reg_ctx->WriteRegisterFromUnsigned ( FP ??? );
+uint32_t pc_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC);
+reg_ctx->WriteRegisterFromUnsigned(pc_reg, pc);
+uint32_t ra_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
+reg_ctx->WriteRegisterFromUnsigned(ra_reg, ra);
+uint32_t sp_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
+reg_ctx->WriteRegisterFromUnsigned(sp_reg, sp);
 
 #if HEX_ABI_DEBUG
 // quick and dirty stack dumper for debugging
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D15451: Make test categories composable

[Todd Fiala via lldb-commits]

tfiala accepted this revision.
tfiala added a comment.

LGTM.  I added a few optional comments on possible improvements, but I think 
they're orthogonal to what you're doing here.



Comment at: packages/Python/lldbsuite/test/lldbtest.py:512
@@ -510,3 +511,3 @@
 def add_test_categories(cat):
-"""Decorate an item with test categories"""
+"""Add test categories to a test item"""
 cat = test_categories.validate(cat, True)

tberghammer wrote:
> Can you be more specific about where can we add this decorator? "item" 
> doesn't really tell anything to me
I think we're talking TestCase test method, right?


Comment at: packages/Python/lldbsuite/test/lldbtest.py:518
@@ +517,3 @@
+if hasattr(func, "categories"):
+cat.extend(func.categories)
+func.categories = cat

This code could potentially accept a single category and drop the need for the 
list.  It could check the type of the input (i.e. the categories input) and, if 
a single element rather than a list, it could just cat.append() it.

That would enable a single argument passed to @add_test_categories()

Totally minor and you can skip this, it just makes for a nice usability 
enhancement provided the decorator is documented as such.


http://reviews.llvm.org/D15451



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

Re: [Lldb-commits] [PATCH] D15326: Rework breakpoint language filtering to use the symbol context's language.

[Jim Ingham via lldb-commits]

This patch is not acceptable as is.  It enshrines an incorrect usage of the 
function cstring_is_mangled which we shouldn’t do.  As I said in the previous 
comment, it’s okay to come up with a short term fix, and check the mangled 
flavor against Itanium and MSVC.  So it shouldn’t be hard to replace the errant 
usage.  Do that and its fine to go in.

Jim

> On Dec 10, 2015, at 4:14 PM, Dawn Perchik  wrote:
> 
> dawn added a comment.
> 
> ping?
> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D15326
> 
> 
> 

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

Re: [Lldb-commits] [PATCH] D15326: Rework breakpoint language filtering to use the symbol context's language.

[Jim Ingham via lldb-commits]

jingham added a subscriber: jingham.
jingham added a comment.

This patch is not acceptable as is.  It enshrines an incorrect usage of the 
function cstring_is_mangled which we shouldn’t do.  As I said in the previous 
comment, it’s okay to come up with a short term fix, and check the mangled 
flavor against Itanium and MSVC.  So it shouldn’t be hard to replace the errant 
usage.  Do that and its fine to go in.

Jim


Repository:
  rL LLVM

http://reviews.llvm.org/D15326



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Greg Clayton via lldb-commits]

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

My main concern here is efficient storage. See my inline comment regarding 
DebugMacroEntryStorage and let me know what you think.



Comment at: include/lldb/Symbol/DebugMacros.h:98
@@ +97,3 @@
+EntryType m_type;
+uint64_t m_line;
+ConstString m_str;

You can probably drop this to uint32_t. No one will have a file with more than 
4 billions lines of code. Then this class will pack better. 


Comment at: include/lldb/Symbol/DebugMacros.h:100
@@ +99,3 @@
+ConstString m_str;
+ConstString m_file;
+DebugMacrosSP m_debug_macros_sp;

m_file should be stored as an integer. CompileUnits has a 
CompileUnits::GetSupportFiles() which is the file list that is the same list 
from the DWARF line table file table. This doesn't mean that we have to hand it 
to consumers as an index, see my comments below about DebugMacroEntryStorage


Comment at: include/lldb/Symbol/DebugMacros.h:101
@@ +100,3 @@
+ConstString m_file;
+DebugMacrosSP m_debug_macros_sp;
+};

We are going to have a million of these objects and we should really store this 
as efficiently as possible:
```
DebugMacroEntryStorage
{
uint32_t m_type:3;
uint32_t m_line:29;
uint32_t m_file_idx; // Index to file in CompileUnit::GetSupportFiles() 
FileSpecList
ConstString m_str;
};
```
Then you can expand this into an instance of DebugMacroEntry and have that be 
what you hand out to external users and this DebugMacroEntry can be as big as 
you want. Can we inline the entries that are currently representing by adding 
the m_debug_macros_sp here? Do we really have many places in the macros for a 
file that include the same thing over and over? I would vote we get rid of the 
m_debug_macros_sp and just inline the entries where we need to unless we have a 
specific case where this would make us make way too many DebugMacroEntryStorage 
objects.


Comment at: include/lldb/Symbol/DebugMacros.h:137
@@ +136,3 @@
+
+std::vector m_macro_entries;
+};

tberghammer wrote:
> What is the benefit of storing unique pointers in the vector compared to the 
> objects itself?
I would rather see this as a vector of just the structs as well as tberghammer 
suggests. No need to scatter thousands of objects around the heap if we don't 
need to.


Comment at: source/Expression/ExpressionSourceCode.cpp:213
@@ +212,3 @@
+StreamString debug_macros_stream;
+debug_macros_stream << ""; // Start with an empty string.
+if (StackFrame *frame = exe_ctx.GetFramePtr())

Remove this as it isn't needed. The StreamString has a std::string and it 
doesn't need to have anything in it to say it is empty.


http://reviews.llvm.org/D15437



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

Re: [Lldb-commits] [PATCH] D15457: Remove hardcoded registers from Hexagon ABI

[Greg Clayton via lldb-commits]

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

You want to check if each reg num is not LLDB_INVALID_REGNUM and return an 
appropriate error.


http://reviews.llvm.org/D15457



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

Re: [Lldb-commits] [lldb] r255310 - test result details now print module.class.test_name in verbose mode.

[Todd Fiala via lldb-commits]

Sure thing :-)

On Thu, Dec 10, 2015 at 3:20 PM, Zachary Turner  wrote:

> That probably got turned on by default by me on accident when I removed
> some of the command line options that mucked with the verbosity setting.
> Thanks!
>
> On Thu, Dec 10, 2015 at 3:17 PM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: tfiala
>> Date: Thu Dec 10 17:14:24 2015
>> New Revision: 255310
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=255310&view=rev
>> Log:
>> test result details now print module.class.test_name in verbose mode.
>>
>> And, turns off verbose mode by default.  This must have been switched
>> on as the default when somebody was testing.
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
>> lldb/trunk/packages/Python/lldbsuite/test/configuration.py
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py?rev=255310&r1=255309&r2=255310&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
>> (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
>> Thu Dec 10 17:14:24 2015
>> @@ -13,6 +13,7 @@ from __future__ import print_function
>>  import os
>>
>>  # Our imports
>> +from . import configuration
>>  from . import result_formatter
>>  from .result_formatter import EventBuilder
>>  import lldbsuite
>> @@ -272,6 +273,13 @@ class BasicResultsFormatter(result_forma
>>  extra_info,
>>  event["test_filename"]))
>>  else:
>> +# Figure out the identity we will use for this test.
>> +if configuration.verbose and ("test_class" in event):
>> +test_id = "{}.{}".format(
>> +event["test_class"], event["test_name"])
>> +else:
>> +test_id = event["test_name"]
>> +
>>  # Test-method events have richer detail, use that
>> here.
>>  test_relative_path = os.path.relpath(
>>  os.path.realpath(event["test_filename"]),
>> @@ -279,7 +287,7 @@ class BasicResultsFormatter(result_forma
>>  self.out_file.write("{}: {}{} ({})\n".format(
>>  detail_label,
>>  extra_info,
>> -event["test_name"],
>> +test_id,
>>  test_relative_path))
>>
>>  def _finish_output_no_lock(self):
>>
>> Modified: lldb/trunk/packages/Python/lldbsuite/test/configuration.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/configuration.py?rev=255310&r1=255309&r2=255310&view=diff
>>
>> ==
>> --- lldb/trunk/packages/Python/lldbsuite/test/configuration.py (original)
>> +++ lldb/trunk/packages/Python/lldbsuite/test/configuration.py Thu Dec 10
>> 17:14:24 2015
>> @@ -120,7 +120,7 @@ sdir_has_content = False
>>  svn_info = ''
>>
>>  # Default verbosity is 0.
>> -verbose = 1
>> +verbose = 0
>>
>>  # By default, search from the script directory.
>>  # We can't use sys.path[0] to determine the script directory
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>


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

[Lldb-commits] [lldb] r255358 - DisassemblerLLVMC now gets the disassembler comments for an instruction

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Dec 11 13:10:04 2015
New Revision: 255358

URL: http://llvm.org/viewvc/llvm-project?rev=255358&view=rev
Log:
DisassemblerLLVMC now gets the disassembler comments for an instruction
and appends them to our list of comments (which can additionally include
things like decoded addresses).

Modified:
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h

Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp?rev=255358&r1=255357&r2=255358&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp Fri Dec 
11 13:10:04 2015
@@ -280,7 +280,8 @@ public:
 
 if (m_opcode.GetData(data))
 {
-char out_string[512];
+std::string out_string;
+std::string comment_string;
 
 DisassemblerLLVMC &llvm_disasm = GetDisassemblerLLVMC();
 
@@ -331,7 +332,12 @@ public:
 if (inst_size > 0)
 {
 mc_disasm_ptr->SetStyle(use_hex_immediates, hex_style);
-mc_disasm_ptr->PrintMCInst(inst, out_string, 
sizeof(out_string));
+mc_disasm_ptr->PrintMCInst(inst, out_string, comment_string);
+
+if (!comment_string.empty())
+{
+AppendComment(comment_string);
+}
 }
 
 llvm_disasm.Unlock();
@@ -413,10 +419,10 @@ public:
 
 RegularExpression::Match matches(3);
 
-if (s_regex.Execute(out_string, &matches))
+if (s_regex.Execute(out_string.c_str(), &matches))
 {
-matches.GetMatchAtIndex(out_string, 1, m_opcode_name);
-matches.GetMatchAtIndex(out_string, 2, m_mnemonics);
+matches.GetMatchAtIndex(out_string.c_str(), 1, m_opcode_name);
+matches.GetMatchAtIndex(out_string.c_str(), 2, m_mnemonics);
 }
 }
 }
@@ -543,21 +549,25 @@ DisassemblerLLVMC::LLVMCDisassembler::Ge
 return 0;
 }
 
-uint64_t
+void
 DisassemblerLLVMC::LLVMCDisassembler::PrintMCInst (llvm::MCInst &mc_inst,
-   char *dst,
-   size_t dst_len)
+   std::string &inst_string,
+   std::string 
&comments_string)
 {
-llvm::StringRef unused_annotations;
-llvm::SmallString<64> inst_string;
-llvm::raw_svector_ostream inst_stream(inst_string);
-m_instr_printer_ap->printInst (&mc_inst, inst_stream, unused_annotations,
-   *m_subtarget_info_ap);
-const size_t output_size = std::min(dst_len - 1, inst_string.size());
-std::memcpy(dst, inst_string.data(), output_size);
-dst[output_size] = '\0';
+llvm::raw_string_ostream inst_stream(inst_string);
+llvm::raw_string_ostream comments_stream(comments_string);
 
-return output_size;
+m_instr_printer_ap->setCommentStream(comments_stream);
+m_instr_printer_ap->printInst (&mc_inst, inst_stream, llvm::StringRef(), 
*m_subtarget_info_ap);
+m_instr_printer_ap->setCommentStream(llvm::nulls());
+comments_stream.flush();
+
+static std::string g_newlines("\r\n");
+
+for (size_t newline_pos = 0; (newline_pos = 
comments_string.find_first_of(g_newlines, newline_pos)) != 
comments_string.npos; /**/)
+{
+comments_string.replace(comments_string.begin() + newline_pos, 
comments_string.begin() + newline_pos + 1, 1, ' ');
+}
 }
 
 void

Modified: lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h?rev=255358&r1=255357&r2=255358&view=diff
==
--- lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h (original)
+++ lldb/trunk/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.h Fri Dec 11 
13:10:04 2015
@@ -51,7 +51,7 @@ class DisassemblerLLVMC : public lldb_pr
 ~LLVMCDisassembler();
 
 uint64_t GetMCInst (const uint8_t *opcode_data, size_t 
opcode_data_len, lldb::addr_t pc, llvm::MCInst &mc_inst);
-uint64_t PrintMCInst (llvm::MCInst &mc_inst, char *output_buffer, 
size_t out_buffer_len);
+void PrintMCInst (llvm::MCInst &mc_inst, std::string &inst_string, 
std::string &comments_string);
 void SetStyle (bool use_hex_immed, HexImmediateStyle hex_style);
 bool CanBranch (llvm::MCInst &mc_inst);
 bool HasDelaySlot (llvm::MCIns

[Lldb-commits] [lldb] r255360 - Remove -r and -R options from dotest.py.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Dec 11 13:21:34 2015
New Revision: 255360

URL: http://llvm.org/viewvc/llvm-project?rev=255360&view=rev
Log:
Remove -r and -R options from dotest.py.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/configuration.py
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/configuration.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/configuration.py?rev=255360&r1=255359&r2=255360&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/configuration.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/configuration.py Fri Dec 11 
13:21:34 2015
@@ -102,12 +102,6 @@ parsable = False
 # The regular expression pattern to match against eligible filenames as our 
test cases.
 regexp = None
 
-# By default, tests are executed in place and cleanups are performed 
afterwards.
-# Use '-r dir' option to relocate the tests and their intermediate files to a
-# different directory and to forgo any cleanups.  The directory specified must
-# not exist yet.
-rdir = None
-
 # By default, recorded session info for errored/failed test are dumped into its
 # own file under a session directory named after the timestamp of the test 
suite
 # run.  Use '-s session-dir-name' to specify a specific dir name.

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255360&r1=255359&r2=255360&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11 13:21:34 2015
@@ -327,23 +327,6 @@ def parseOptionsAndInitTestdirs():
 if args.q:
 configuration.parsable = True
 
-if args.R:
-if args.R.startswith('-'):
-usage(parser)
-configuration.rdir = os.path.abspath(args.R)
-if os.path.exists(configuration.rdir):
-import shutil
-print('Removing tree:', configuration.rdir)
-shutil.rmtree(configuration.rdir)
-
-if args.r:
-if args.r.startswith('-'):
-usage(parser)
-configuration.rdir = os.path.abspath(args.r)
-if os.path.exists(configuration.rdir):
-print('Relocated directory:', configuration.rdir, 'must not 
exist!')
-usage(parser)
-
 if args.S:
 configuration.skip_build_and_cleanup = True
 
@@ -438,47 +421,6 @@ def parseOptionsAndInitTestdirs():
 # Shut off multiprocessing mode when test directories are specified.
 configuration.no_multiprocess_test_runner = True
 
-# If '-r dir' is specified, the tests should be run under the relocated
-# directory.  Let's copy the testdirs over.
-if configuration.rdir:
-from shutil import copytree, ignore_patterns
-
-tmpdirs = []
-orig_testdirs = configuration.testdirs[:]
-for srcdir in configuration.testdirs:
-# For example, 
/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/hello_watchpoint
-# shall be split into ['/Volumes/data/lldb/svn/ToT/', 
'functionalities/watchpoint/hello_watchpoint'].
-# Utilize the relative path to the 'test' directory to make our 
destination dir path.
-if ("test" + os.sep) in srcdir:
-to_split_on = "test" + os.sep
-else:
-to_split_on = "test"
-dstdir = os.path.join(configuration.rdir, 
srcdir.split(to_split_on)[1])
-dstdir = dstdir.rstrip(os.sep)
-# Don't copy the *.pyc and .svn stuffs.
-copytree(srcdir, dstdir, ignore=ignore_patterns('*.pyc', '.svn'))
-tmpdirs.append(dstdir)
-
-# This will be our modified testdirs.
-configuration.testdirs = tmpdirs
-
-# With '-r dir' specified, there's no cleanup of intermediate test 
files.
-os.environ["LLDB_DO_CLEANUP"] = 'NO'
-
-# If the original testdirs is ['test'], the make directory has already 
been copied
-# recursively and is contained within the rdir/test dir.  For anything
-# else, we would need to copy over the make directory and its contents,
-# so that, os.listdir(rdir) looks like, for example:
-#
-# array_types conditional_break make
-#
-# where the make directory contains the Makefile.rules file.
-if len(configuration.testdirs) != 1 or 
os.path.basename(orig_testdirs[0]) != 'test':
-scriptdir = os.path.dirname(__file__)
-# Don't copy the .svn stuffs.
-copytree(os.path.join(scriptdir, 'make'), os.path.join(rdir, 
'make'),
- ignore=ignore_patterns('.svn'))
-
 #p

[Lldb-commits] [lldb] r255361 - Remove -S option from dotest.py.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Dec 11 13:21:49 2015
New Revision: 255361

URL: http://llvm.org/viewvc/llvm-project?rev=255361&view=rev
Log:
Remove -S option from dotest.py.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/configuration.py
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

lldb/trunk/packages/Python/lldbsuite/test/source-manager/TestSourceManager.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/configuration.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/configuration.py?rev=255361&r1=255360&r2=255361&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/configuration.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/configuration.py Fri Dec 11 
13:21:49 2015
@@ -89,9 +89,6 @@ cflags_extras = ''
 # The filters (testclass.testmethod) used to admit tests into our test suite.
 filters = []
 
-# By default, we do not skip build and cleanup.  Use '-S' option to override.
-skip_build_and_cleanup = False
-
 # By default, we skip long running test case.  Use '-l' option to override.
 skip_long_running_test = True
 

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255361&r1=255360&r2=255361&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11 13:21:49 2015
@@ -327,9 +327,6 @@ def parseOptionsAndInitTestdirs():
 if args.q:
 configuration.parsable = True
 
-if args.S:
-configuration.skip_build_and_cleanup = True
-
 if args.s:
 if args.s.startswith('-'):
 usage(parser)

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py?rev=255361&r1=255360&r2=255361&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest_args.py Fri Dec 11 
13:21:49 2015
@@ -86,7 +86,6 @@ def create_parser():
 group = parser.add_argument_group('Runtime behaviour options')
 X('-d', 'Suspend the process after launch to wait indefinitely for a 
debugger to attach')
 X('-q', "Don't print extra output from this script.")
-X('-S', "Skip the build and cleanup while running the test. Use this 
option with care as you would need to build the inferior(s) by hand and build 
the executable(s) with the correct name(s). This can be used with '-# n' to 
stress test certain test cases for n number of times")
 X('-t', 'Turn on tracing of lldb command and other detailed test 
executions')
 group.add_argument('-u', dest='unset_env_varnames', metavar='variable', 
action='append', help='Specify an environment variable to unset before running 
the test cases. e.g., -u DYLD_INSERT_LIBRARIES -u MallocScribble')
 group.add_argument('--env', dest='set_env_vars', metavar='variable', 
action='append', help='Specify an environment variable to set to the given 
value before running the test cases e.g.: --env CXXFLAGS=-O3 --env 
DYLD_INSERT_LIBRARIES')

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=255361&r1=255360&r2=255361&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Fri Dec 11 13:21:49 
2015
@@ -1349,7 +1349,7 @@ class Base(unittest2.TestCase):
 Do class-wide cleanup.
 """
 
-if doCleanup and not configuration.skip_build_and_cleanup:
+if doCleanup:
 # First, let's do the platform-specific cleanup.
 module = builder_module()
 module.cleanup()
@@ -2133,8 +2133,6 @@ class Base(unittest2.TestCase):
 
 def buildDefault(self, architecture=None, compiler=None, dictionary=None, 
clean=True):
 """Platform specific way to build the default binaries."""
-if configuration.skip_build_and_cleanup:
-return
 module = builder_module()
 if target_is_android():
 dictionary = append_android_envs(dictionary)
@@ -2143,16 +2141,12 @@ class Base(unittest2.TestCase):
 
 def buildDsym(self, architecture=None, compiler=None, dictionary=None, 
clean=True):
 """Platform specific way to build binaries with dsym info."""
-if configuration.skip_build_and_cleanup:
-retur

Re: [Lldb-commits] [PATCH] D15428: Make debug info specification use categories system

[Zachary Turner via lldb-commits]

zturner updated this revision to Diff 42550.
zturner added a comment.

Updated with comments from previous review.  Also change the multiplication 
logic to use a loop instead of writing each one separately.


http://reviews.llvm.org/D15428

Files:
  packages/Python/lldbsuite/test/configuration.py
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/dotest_args.py
  
packages/Python/lldbsuite/test/functionalities/unwind/standard/TestStandardUnwind.py
  packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py
  
packages/Python/lldbsuite/test/lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py
  packages/Python/lldbsuite/test/lldbtest.py
  packages/Python/lldbsuite/test/test_categories.py

Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -11,8 +11,15 @@
 
 # LLDB modules
 
+debug_info_categories = [
+'dwarf', 'dwo', 'dsym'
+]
+
 all_categories = {
 'dataformatters': 'Tests related to the type command and the data formatters subsystem',
+'dwarf' : 'Tests that can be run with DWARF debug information',
+'dwo'   : 'Tests that can be run with DWO debug information',
+'dsym'  : 'Tests that can be run with DSYM debug information',
 'expression': 'Tests related to the expression parser',
 'objc'  : 'Tests related to the Objective-C programming language support',
 'pyapi' : 'Tests related to the Python API',
@@ -34,6 +41,13 @@
 candidate = item
 return candidate
 
+def is_supported_on_platform(category, platform):
+if category == "dwo":
+return platform in ["linux", "freebsd", "windows"]
+elif category == "dsym":
+return platform in ["darwin", "macosx", "ios"]
+return True
+
 def validate(categories, exact_match):
 """
 For each category in categories, ensure that it's a valid category (if exact_match is false,
Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -543,48 +543,6 @@
 wrapper.__no_debug_info_test__ = True
 return wrapper
 
-def dsym_test(func):
-"""Decorate the item as a dsym test."""
-if isinstance(func, type) and issubclass(func, unittest2.TestCase):
-raise Exception("@dsym_test can only be used to decorate a test method")
-@wraps(func)
-def wrapper(self, *args, **kwargs):
-if configuration.dont_do_dsym_test:
-self.skipTest("dsym tests")
-return func(self, *args, **kwargs)
-
-# Mark this function as such to separate them from the regular tests.
-wrapper.__dsym_test__ = True
-return wrapper
-
-def dwarf_test(func):
-"""Decorate the item as a dwarf test."""
-if isinstance(func, type) and issubclass(func, unittest2.TestCase):
-raise Exception("@dwarf_test can only be used to decorate a test method")
-@wraps(func)
-def wrapper(self, *args, **kwargs):
-if configuration.dont_do_dwarf_test:
-self.skipTest("dwarf tests")
-return func(self, *args, **kwargs)
-
-# Mark this function as such to separate them from the regular tests.
-wrapper.__dwarf_test__ = True
-return wrapper
-
-def dwo_test(func):
-"""Decorate the item as a dwo test."""
-if isinstance(func, type) and issubclass(func, unittest2.TestCase):
-raise Exception("@dwo_test can only be used to decorate a test method")
-@wraps(func)
-def wrapper(self, *args, **kwargs):
-if configuration.dont_do_dwo_test:
-self.skipTest("dwo tests")
-return func(self, *args, **kwargs)
-
-# Mark this function as such to separate them from the regular tests.
-wrapper.__dwo_test__ = True
-return wrapper
-
 def debugserver_test(func):
 """Decorate the item as a debugserver test."""
 if isinstance(func, type) and issubclass(func, unittest2.TestCase):
@@ -2264,32 +,26 @@
 newattrs = {}
 for attrname, attrvalue in attrs.items():
 if attrname.startswith("test") and not getattr(attrvalue, "__no_debug_info_test__", False):
-@dsym_test
-@wraps(attrvalue)
-def dsym_test_method(self, attrvalue=attrvalue):
-self.debug_info = "dsym"
-return attrvalue(self)
-dsym_method_name = attrname + "_dsym"
-dsym_test_method.__name__ = dsym_method_name
-newattrs[dsym_method_name] = dsym_test_method
-
-@dwarf_test
-@wraps(attrvalue)
-def dwarf_test_method(self, attrvalue=attrvalue):
-self.debug_info = "dwarf"
-return attrvalue(self)
-dwa

[Lldb-commits] [lldb] r255363 - Add expected timeout support to test event architecture.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Fri Dec 11 13:44:23 2015
New Revision: 255363

URL: http://llvm.org/viewvc/llvm-project?rev=255363&view=rev
Log:
Add expected timeout support to test event architecture.

Added:

lldb/trunk/packages/Python/lldbsuite/test/issue_verification/TestExpectedTimeout.py.park
Modified:
lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
lldb/trunk/packages/Python/lldbsuite/test/dosep.py
lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py?rev=255363&r1=255362&r2=255363&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/basic_results_formatter.py Fri 
Dec 11 13:44:23 2015
@@ -315,6 +315,11 @@ class BasicResultsFormatter(result_forma
 [result_formatter.EventBuilder.STATUS_SKIP, "Skip", False, None],
 [result_formatter.EventBuilder.STATUS_TIMEOUT,
  "Timeout", True, "TIMEOUT"],
+[result_formatter.EventBuilder.STATUS_EXPECTED_TIMEOUT,
+ # Intentionally using the unusual hyphenation in TIME-OUT to
+ # prevent buildbots from thinking it is an issue when scanning
+ # for TIMEOUT.
+ "Expected Timeout", True, "EXPECTED TIME-OUT"]
 ]
 
 # Partition all the events by test result status

Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=255363&r1=255362&r2=255363&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Fri Dec 11 13:44:23 2015
@@ -1128,6 +1128,7 @@ def getExpectedTimeouts(platform_name):
 target = m.group(1)
 
 expected_timeout = set()
+expected_timeout.add("TestExpectedTimeout.py")
 
 if target.startswith("linux"):
 expected_timeout |= {
@@ -1475,6 +1476,12 @@ def main(num_threads, test_subdir, test_
 
 system_info = " ".join(platform.uname())
 
+# Figure out which test files should be enabled for expected
+# timeout
+expected_timeout = getExpectedTimeouts(dotest_options.lldb_platform_name)
+if results_formatter is not None:
+results_formatter.set_expected_timeouts_by_basename(expected_timeout)
+
 # Figure out which testrunner strategy we'll use.
 runner_strategies_by_name = get_test_runner_strategies(num_threads)
 
@@ -1514,7 +1521,6 @@ def main(num_threads, test_subdir, test_
 os.rename(core, os.path.join(session_dir, dst))
 
 # remove expected timeouts from failures
-expected_timeout = getExpectedTimeouts(dotest_options.lldb_platform_name)
 for xtime in expected_timeout:
 if xtime in timed_out:
 timed_out.remove(xtime)

Added: 
lldb/trunk/packages/Python/lldbsuite/test/issue_verification/TestExpectedTimeout.py.park
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/issue_verification/TestExpectedTimeout.py.park?rev=255363&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/issue_verification/TestExpectedTimeout.py.park
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/issue_verification/TestExpectedTimeout.py.park
 Fri Dec 11 13:44:23 2015
@@ -0,0 +1,19 @@
+"""Tests that a timeout is detected by the testbot."""
+from __future__ import print_function
+
+import time
+
+import lldbsuite.test.lldbtest as lldbtest
+
+
+class ExpectedTimeoutTestCase(lldbtest.TestBase):
+"""Forces test timeout."""
+mydir = lldbtest.TestBase.compute_mydir(__file__)
+
+def test_buildbot_sees_expected_timeout(self):
+"""Tests that expected timeout logic kicks in and is picked up."""
+while True:
+try:
+time.sleep(1)
+except:
+print("ignoring exception during sleep")

Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255363&r1=255362&r2=255363&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec 11 
13:44:23 2015
@@ -163,11 +163,16 @@ class EventBuilder(object):
 TYPE_TEST_START = "test_start"
 TYPE_MARK_TEST_RERUN_ELIGIBLE = "test_eligible_for_rerun"
 
+RESULT_TYPES = set([
+TYPE_JOB_RESULT,
+TYPE_TEST_RE

[Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Eugene Zelenko via lldb-commits]

Author: eugenezelenko
Date: Fri Dec 11 13:52:15 2015
New Revision: 255364

URL: http://llvm.org/viewvc/llvm-project?rev=255364&view=rev
Log:
Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr 
warnings in source/Target/Target.cpp.

Simplify smart pointers checks in conditions.

Modified:
lldb/trunk/source/Target/Target.cpp

Modified: lldb/trunk/source/Target/Target.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Target.cpp?rev=255364&r1=255363&r2=255364&view=diff
==
--- lldb/trunk/source/Target/Target.cpp (original)
+++ lldb/trunk/source/Target/Target.cpp Fri Dec 11 13:52:15 2015
@@ -178,7 +178,7 @@ Target::CleanupProcess ()
 void
 Target::DeleteCurrentProcess ()
 {
-if (m_process_sp.get())
+if (m_process_sp)
 {
 m_section_load_history.Clear();
 if (m_process_sp->IsAlive())
@@ -333,7 +333,7 @@ Target::CreateSourceRegexBreakpoint (con
 SearchFilterSP filter_sp(GetSearchFilterForModuleAndCUList 
(containingModules, source_file_spec_list));
 if (move_to_nearest_code == eLazyBoolCalculate)
 move_to_nearest_code = GetMoveToNearestCode() ? eLazyBoolYes : 
eLazyBoolNo;
-BreakpointResolverSP resolver_sp(new BreakpointResolverFileRegex (NULL, 
source_regex, !static_cast(move_to_nearest_code)));
+BreakpointResolverSP resolver_sp(new BreakpointResolverFileRegex(nullptr, 
source_regex, !static_cast(move_to_nearest_code)));
 return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware, true);
 }
 
@@ -385,12 +385,12 @@ Target::CreateBreakpoint (const FileSpec
 if (move_to_nearest_code == eLazyBoolCalculate)
 move_to_nearest_code = GetMoveToNearestCode() ? eLazyBoolYes : 
eLazyBoolNo;
 
-BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine (NULL,
- file,
- line_no,
- 
check_inlines,
- 
skip_prologue,
- 
!static_cast(move_to_nearest_code)));
+BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(nullptr,
+file,
+line_no,
+
check_inlines,
+
skip_prologue,
+
!static_cast(move_to_nearest_code)));
 return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware, true);
 }
 
@@ -420,7 +420,7 @@ BreakpointSP
 Target::CreateBreakpoint (const Address &addr, bool internal, bool hardware)
 {
 SearchFilterSP filter_sp(new SearchFilterForUnconstrainedSearches 
(shared_from_this()));
-BreakpointResolverSP resolver_sp (new BreakpointResolverAddress (NULL, 
addr));
+BreakpointResolverSP resolver_sp(new BreakpointResolverAddress(nullptr, 
addr));
 return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware, 
false);
 }
 
@@ -431,7 +431,7 @@ Target::CreateAddressInModuleBreakpoint
  bool request_hardware)
 {
 SearchFilterSP filter_sp(new SearchFilterForUnconstrainedSearches 
(shared_from_this()));
-BreakpointResolverSP resolver_sp (new BreakpointResolverAddress (NULL, 
file_addr, file_spec));
+BreakpointResolverSP resolver_sp(new BreakpointResolverAddress(nullptr, 
file_addr, file_spec));
 return CreateBreakpoint (filter_sp, resolver_sp, internal, 
request_hardware, false);
 }
 
@@ -455,12 +455,12 @@ Target::CreateBreakpoint (const FileSpec
 if (language == lldb::eLanguageTypeUnknown)
 language = GetLanguage();
 
-BreakpointResolverSP resolver_sp (new BreakpointResolverName (NULL, 
-  
func_name, 
-  
func_name_type_mask, 
-  language,
-  
Breakpoint::Exact, 
-  
skip_prologue));
+BreakpointResolverSP resolver_sp(new BreakpointResolverName(nullptr, 
+func_name, 
+
func_name_type_mask, 
+language,
+
Breakpoint::Exact, 
+   

Re: [Lldb-commits] [PATCH] D15457: Remove hardcoded registers from Hexagon ABI

[Ted Woodward via lldb-commits]

ted updated this revision to Diff 42555.
ted added a comment.

Updated to check for invalid register numbers.


http://reviews.llvm.org/D15457

Files:
  source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp

Index: source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
===
--- source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
+++ source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
@@ -226,7 +226,7 @@
 //  . handle 64bit values and their register / stack requirements
 
 */
-#define HEX_ABI_DEBUG 1
+#define HEX_ABI_DEBUG 0
 bool
 ABISysV_hexagon::PrepareTrivialCall ( Thread &thread, 
   lldb::addr_t  sp  , 
@@ -242,6 +242,23 @@
 // grab the process so we have access to the memory for spilling
 lldb::ProcessSP proc = thread.GetProcess( );
 
+// get the register context for modifying all of the registers
+RegisterContext *reg_ctx = thread.GetRegisterContext().get();
+if (!reg_ctx)
+return false;
+
+uint32_t pc_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+if (pc_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t ra_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_RA);
+if (ra_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t sp_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_SP);
+if (sp_reg == LLDB_INVALID_REGNUM)
+return false;
+
 // push host data onto target
 for ( size_t i = 0; i < args.size( ); i++ )
 {
@@ -276,11 +293,6 @@
 // check if this is a variable argument function
 bool isVArg = prototype.isFunctionVarArg();
 
-// get the register context for modifying all of the registers
-RegisterContext *reg_ctx = thread.GetRegisterContext().get();
-if (!reg_ctx)
-return false;
-
 // number of arguments passed by register
 int nRegArgs = nVArgRegParams;
 if (! isVArg )
@@ -323,10 +335,9 @@
 }
 
 // update registers with current function call state
-reg_ctx->WriteRegisterFromUnsigned ( 41, pc );
-reg_ctx->WriteRegisterFromUnsigned ( 31, ra );
-reg_ctx->WriteRegisterFromUnsigned ( 29, sp );
-//  reg_ctx->WriteRegisterFromUnsigned ( FP ??? );
+reg_ctx->WriteRegisterFromUnsigned(pc_reg, pc);
+reg_ctx->WriteRegisterFromUnsigned(ra_reg, ra);
+reg_ctx->WriteRegisterFromUnsigned(sp_reg, sp);
 
 #if HEX_ABI_DEBUG
 // quick and dirty stack dumper for debugging


Index: source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
===
--- source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
+++ source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
@@ -226,7 +226,7 @@
 //  . handle 64bit values and their register / stack requirements
 
 */
-#define HEX_ABI_DEBUG 1
+#define HEX_ABI_DEBUG 0
 bool
 ABISysV_hexagon::PrepareTrivialCall ( Thread &thread, 
   lldb::addr_t  sp  , 
@@ -242,6 +242,23 @@
 // grab the process so we have access to the memory for spilling
 lldb::ProcessSP proc = thread.GetProcess( );
 
+// get the register context for modifying all of the registers
+RegisterContext *reg_ctx = thread.GetRegisterContext().get();
+if (!reg_ctx)
+return false;
+
+uint32_t pc_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_PC);
+if (pc_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t ra_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_RA);
+if (ra_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t sp_reg = reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_SP);
+if (sp_reg == LLDB_INVALID_REGNUM)
+return false;
+
 // push host data onto target
 for ( size_t i = 0; i < args.size( ); i++ )
 {
@@ -276,11 +293,6 @@
 // check if this is a variable argument function
 bool isVArg = prototype.isFunctionVarArg();
 
-// get the register context for modifying all of the registers
-RegisterContext *reg_ctx = thread.GetRegisterContext().get();
-if (!reg_ctx)
-return false;
-
 // number of arguments passed by register
 int nRegArgs = nVArgRegParams;
 if (! isVArg )
@@ -323,10 +335,9 @@
 }
 
 // update registers with current function call state
-reg_ctx->WriteRegisterFromUnsigned ( 41, pc );
-reg_ctx->WriteRegisterFromUnsigned ( 31, ra );
-reg_ctx->WriteRegisterFromUnsigned ( 29, sp );
-//  reg_ctx->WriteRegisterFromUnsigned ( FP ??? );
+reg_ctx->WriteRegisterFromUnsigned(pc_reg, pc);
+reg_ctx->WriteRegisterFromUnsigned(ra_reg, ra);
+reg_ctx->WriteRegisterFromUnsigned(sp_reg, sp);
 
 #if HEX_ABI_DEBUG
 // quick and dirty stack dumper

Re: [Lldb-commits] [PATCH] D15407: When stepping in/over source lines, combine the addr ranges of all line table entries w/ same line num

[Jim Ingham via lldb-commits]

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

This looks good.  I have one worry.  If the plan is stepping through a range of 
line 10, and that code branches to:

0x120 - line 0
0x128 - line 11
0x130 - line 12

You will see that we are starting at line 0, so you will choose 11 as the NEW 
line number to match, extend the range to 0x130 and then step through that.  So 
we would have effectively stepped through lines 10 and 11.  There are actually 
times the stepping will do this - for instance if you jump into the middle of 
another line we step out of the line for you, since being mid-source line is 
disconcerting.

It is important not to stop the stepping at line 0, since being "nowhere" is 
even more disconcerting.  So consuming the line 0 range is important.  But 
somewhere you need to add the notion of "expected completion line" so that you 
don't extend past an initial line 0 if the following line is not the expected 
one.



Comment at: include/lldb/Symbol/LineEntry.h:143-154
@@ -142,1 +142,14 @@
 
+//--
+/// Give the range for this LineEntry + any additional LineEntries for
+/// this same source line that are contiguous.
+///
+/// A compiler may emit multiple line entries for a single source line,
+/// e.g. to indicate subexpressions at different columns.  This method
+/// will get the AddressRange for all of the LineEntries for this source 
+/// line that are contiguous.
+///
+/// @return
+/// The contiguous AddressRange for this source line.
+//--
+AddressRange

Do you want to mention the treatment of line number 0 here?  You also glom 
those into the extended line range, which isn't obvious from the name or 
comment.


Comment at: source/Target/Thread.cpp:1546-1547
@@ +1545,4 @@
+{
+return QueueThreadPlanForStepOverRange (abort_other_plans, 
line_entry.GetSameLineContiguousAddressRange(), addr_context, 
stop_other_threads, step_out_avoids_code_withoug_debug_info);
+}
+

This should get broken up across more lines.


Comment at: source/Target/Thread.cpp:1583-1584
@@ +1582,4 @@
+{
+return QueueThreadPlanForStepInRange (abort_other_plans, 
line_entry.GetSameLineContiguousAddressRange(), addr_context, step_in_target, 
stop_other_threads, step_in_avoids_code_without_debug_info, 
step_out_avoids_code_without_debug_info);
+}
+

This line is too long.


Repository:
  rL LLVM

http://reviews.llvm.org/D15407



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

Re: [Lldb-commits] [PATCH] D15407: When stepping in/over source lines, combine the addr ranges of all line table entries w/ same line num

[Jim Ingham via lldb-commits]

jingham added a comment.

The comment about "sometimes we step through another line" wasn't clear.  I 
wanted to say - as a last recourse we do this, but we shouldn't if we can avoid 
it, which in this case I think we can.


Repository:
  rL LLVM

http://reviews.llvm.org/D15407



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Siva Chandra via lldb-commits]

sivachandra updated this revision to Diff 42563.
sivachandra marked 11 inline comments as done.
sivachandra added a comment.

Address comments.


http://reviews.llvm.org/D15437

Files:
  include/lldb/Symbol/CompileUnit.h
  include/lldb/Symbol/DebugMacros.h
  include/lldb/Symbol/SymbolFile.h
  include/lldb/Symbol/SymbolVendor.h
  include/lldb/lldb-enumerations.h
  packages/Python/lldbsuite/test/expression_command/macros/Makefile
  packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
  packages/Python/lldbsuite/test/expression_command/macros/macro1.h
  packages/Python/lldbsuite/test/expression_command/macros/macro2.h
  packages/Python/lldbsuite/test/expression_command/macros/main.cpp
  packages/Python/lldbsuite/test/make/Makefile.rules
  source/Expression/ExpressionSourceCode.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/SymbolFile/DWARF/CMakeLists.txt
  source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.cpp
  source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.cpp
  source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.h
  source/Symbol/CMakeLists.txt
  source/Symbol/CompileUnit.cpp
  source/Symbol/DebugMacros.cpp
  source/Symbol/ObjectFile.cpp
  source/Symbol/SymbolVendor.cpp
  source/Utility/ConvertEnum.cpp

Index: source/Utility/ConvertEnum.cpp
===
--- source/Utility/ConvertEnum.cpp
+++ source/Utility/ConvertEnum.cpp
@@ -77,6 +77,8 @@
 return "dwarf-loc";
 case eSectionTypeDWARFDebugMacInfo:
 return "dwarf-macinfo";
+case eSectionTypeDWARFDebugMacro:
+return "dwarf-macro";
 case eSectionTypeDWARFDebugPubNames:
 return "dwarf-pubnames";
 case eSectionTypeDWARFDebugPubTypes:
Index: source/Symbol/SymbolVendor.cpp
===
--- source/Symbol/SymbolVendor.cpp
+++ source/Symbol/SymbolVendor.cpp
@@ -186,6 +186,18 @@
 }
 
 bool
+SymbolVendor::ParseCompileUnitDebugMacros (const SymbolContext &sc)
+{
+ModuleSP module_sp(GetModule());
+if (module_sp)
+{
+lldb_private::Mutex::Locker locker(module_sp->GetMutex());
+if (m_sym_file_ap.get())
+return m_sym_file_ap->ParseCompileUnitDebugMacros(sc);
+}
+return false;
+}
+bool
 SymbolVendor::ParseCompileUnitSupportFiles (const SymbolContext& sc, FileSpecList& support_files)
 {
 ModuleSP module_sp(GetModule());
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -362,6 +362,7 @@
 case eSectionTypeDWARFDebugLine:
 case eSectionTypeDWARFDebugLoc:
 case eSectionTypeDWARFDebugMacInfo:
+case eSectionTypeDWARFDebugMacro:
 case eSectionTypeDWARFDebugPubNames:
 case eSectionTypeDWARFDebugPubTypes:
 case eSectionTypeDWARFDebugRanges:
Index: source/Symbol/DebugMacros.cpp
===
--- /dev/null
+++ source/Symbol/DebugMacros.cpp
@@ -0,0 +1,55 @@
+//===-- DebugMacros.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Symbol/DebugMacros.h"
+
+using namespace lldb_private;
+
+DebugMacroEntry::DebugMacroEntry(EntryType type,
+ uint32_t line,
+ const char *str)
+: m_type(type),
+  m_line(line),
+  m_str(str)
+{ }
+
+DebugMacroEntry::DebugMacroEntry(EntryType type,
+ const DebugMacrosSP &debug_macros_sp)
+: m_type(type), m_debug_macros_sp(debug_macros_sp)
+{ }
+
+DebugMacroEntry
+DebugMacroEntry::CreateDefineEntry(uint32_t line, const char *str)
+{
+return DebugMacroEntry(DebugMacroEntry::DEFINE, line, str);
+}
+
+DebugMacroEntry
+DebugMacroEntry::CreateUndefEntry(uint32_t line, const char *str)
+{
+return DebugMacroEntry(DebugMacroEntry::UNDEF, line, str);
+}
+
+DebugMacroEntry
+DebugMacroEntry::CreateStartFileEntry(uint32_t line)
+{
+return DebugMacroEntry(DebugMacroEntry::START_FILE, line, nullptr);
+}
+
+DebugMacroEntry
+DebugMacroEntry::CreateEndFileEntry()
+{
+return DebugMacroEntry(DebugMacroEntry::END_FILE, 0, nullptr);
+}
+
+DebugMacroEntry
+D

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Siva Chandra via lldb-commits]

sivachandra added a comment.

I have addressed all the comments (with changes or my own comments).

About the problem with dwo, I have sent a mail to the GCC guys asking for 
guidance. Will fix it when I get clarity on that.

And yes, it would definitely be good if clang can also produce .debug_macro 
sections.



Comment at: include/lldb/Symbol/DebugMacros.h:101
@@ +100,3 @@
+ConstString m_file;
+DebugMacrosSP m_debug_macros_sp;
+};

clayborg wrote:
> We are going to have a million of these objects and we should really store 
> this as efficiently as possible:
> ```
> DebugMacroEntryStorage
> {
> uint32_t m_type:3;
> uint32_t m_line:29;
> uint32_t m_file_idx; // Index to file in CompileUnit::GetSupportFiles() 
> FileSpecList
> ConstString m_str;
> };
> ```
> Then you can expand this into an instance of DebugMacroEntry and have that be 
> what you hand out to external users and this DebugMacroEntry can be as big as 
> you want. Can we inline the entries that are currently representing by adding 
> the m_debug_macros_sp here? Do we really have many places in the macros for a 
> file that include the same thing over and over? I would vote we get rid of 
> the m_debug_macros_sp and just inline the entries where we need to unless we 
> have a specific case where this would make us make way too many 
> DebugMacroEntryStorage objects.
1. I have taken in other changes but did not remove m_debug_macros_sp. 
2. I have removed the file name / file index member completely as we are not 
using it now anyway!
3. I did not understand the benefit of creating a new class/struct.
4. For a simple source file like in the test, I see a 100+ defines inserted by 
default. If we inline them, and if a symbol file contains a 100 simple source 
files, we will be storing 1+ duplicate entries. If each of the source files 
actually includes a standard library header, I would image there would be many 
more common entries exploding the number of duplicate entries we will be 
storing.


Comment at: source/Expression/ExpressionSourceCode.cpp:122
@@ +121,3 @@
+else
+return;
+break;

tberghammer wrote:
> Should this function return an error in this case so the caller know the 
> macro stream is only half ready?
The return here does not mean it is "half ready". The function returns from 
here as macro entries after this appear on or after the current line in the 
main source file.


Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h:48
@@ +47,3 @@
+uint8_t entry_count;
+std::map entry_map; // Mapping from opcode number to its 
entry.
+

tberghammer wrote:
> Why do we need this data structure? Currently nobody is using it.
> Also should we store DWARFFormValue instead of llvm::dwarf::Form here? It 
> have a lot of feature in it what makes it work with split dwarf (dwo).
I have refactored the code around this now. Since the entire header has to be 
read past to get to the macro entries, I have collected the data in a 
data-structure. After the refactor, it is only lives on the stack. While I am 
OK to take it off if you want, I see no harm in keeping it as a data structure.

Also, since the form value is unused anyway, I have now made it dw_form_t.


http://reviews.llvm.org/D15437



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

[Lldb-commits] [lldb] r255374 - Remove hardcoded registers from Hexagon ABI

[Ted Woodward via lldb-commits]

Author: ted
Date: Fri Dec 11 15:52:47 2015
New Revision: 255374

URL: http://llvm.org/viewvc/llvm-project?rev=255374&view=rev
Log:
Remove hardcoded registers from Hexagon ABI

Summary: The Hexagon ABI plugin uses hardcoded registers when setting up 
function calls. This is OK for the Hexagon simulator, but the register numbers 
are different on the gdbserver running on hardware. Change the hardcoded 
registers to LLDB generic registers.

Reviewers: clayborg

Subscribers: lldb-commits

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

Modified:
lldb/trunk/source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp

Modified: lldb/trunk/source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp?rev=255374&r1=255373&r2=255374&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-hexagon/ABISysV_hexagon.cpp Fri Dec 11 
15:52:47 2015
@@ -226,7 +226,7 @@ ABISysV_hexagon::PrepareTrivialCall ( Th
 //  . handle 64bit values and their register / stack requirements
 
 */
-#define HEX_ABI_DEBUG 1
+#define HEX_ABI_DEBUG 0
 bool
 ABISysV_hexagon::PrepareTrivialCall ( Thread &thread, 
   lldb::addr_t  sp  , 
@@ -242,6 +242,23 @@ ABISysV_hexagon::PrepareTrivialCall ( Th
 // grab the process so we have access to the memory for spilling
 lldb::ProcessSP proc = thread.GetProcess( );
 
+// get the register context for modifying all of the registers
+RegisterContext *reg_ctx = thread.GetRegisterContext().get();
+if (!reg_ctx)
+return false;
+
+uint32_t pc_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_PC);
+if (pc_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t ra_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_RA);
+if (ra_reg == LLDB_INVALID_REGNUM)
+return false;
+
+uint32_t sp_reg = 
reg_ctx->ConvertRegisterKindToRegisterNumber(eRegisterKindGeneric, 
LLDB_REGNUM_GENERIC_SP);
+if (sp_reg == LLDB_INVALID_REGNUM)
+return false;
+
 // push host data onto target
 for ( size_t i = 0; i < args.size( ); i++ )
 {
@@ -276,11 +293,6 @@ ABISysV_hexagon::PrepareTrivialCall ( Th
 // check if this is a variable argument function
 bool isVArg = prototype.isFunctionVarArg();
 
-// get the register context for modifying all of the registers
-RegisterContext *reg_ctx = thread.GetRegisterContext().get();
-if (!reg_ctx)
-return false;
-
 // number of arguments passed by register
 int nRegArgs = nVArgRegParams;
 if (! isVArg )
@@ -323,10 +335,9 @@ ABISysV_hexagon::PrepareTrivialCall ( Th
 }
 
 // update registers with current function call state
-reg_ctx->WriteRegisterFromUnsigned ( 41, pc );
-reg_ctx->WriteRegisterFromUnsigned ( 31, ra );
-reg_ctx->WriteRegisterFromUnsigned ( 29, sp );
-//  reg_ctx->WriteRegisterFromUnsigned ( FP ??? );
+reg_ctx->WriteRegisterFromUnsigned(pc_reg, pc);
+reg_ctx->WriteRegisterFromUnsigned(ra_reg, ra);
+reg_ctx->WriteRegisterFromUnsigned(sp_reg, sp);
 
 #if HEX_ABI_DEBUG
 // quick and dirty stack dumper for debugging


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

Re: [Lldb-commits] [PATCH] D15435: Add tests to inspect a stack and local variables from a mini dump

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

I found the "test minimal amount" argument compelling, and I tried to do that 
with a saved core file, but that doesn't work because stack unwinding depends 
on debug information, which is the binary, and we don't want to check in 
binaries for the inferiors.


http://reviews.llvm.org/D15435



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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Hey Eugene and Greg,
>
> I thought we were doing spaces before the open parens in places like this:
>
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
> nullptr,
>
> (see the removal of the space after BreakpointResolverFileLine from the
> clang-tidy settings I presume).
>
> Did I misunderstand that?
>

This was officially removed from the coding standard some months ago, but
not everyone has adopted this unfortunately.  See r228860.  It pains me to
no end that we differ from LLVM, because it leads to exactly these type of
problems where people aren't sure what the exact set of rules are.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner  wrote:

> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Hey Eugene and Greg,
>>
>> I thought we were doing spaces before the open parens in places like this:
>>
>> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
>> (NULL,
>> ...
>> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
>> nullptr,
>>
>> (see the removal of the space after BreakpointResolverFileLine from the
>> clang-tidy settings I presume).
>>
>> Did I misunderstand that?
>>
>
> This was officially removed from the coding standard some months ago,
>

Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
can just look there to see what we're supposed to be doing.


> but not everyone has adopted this unfortunately.  See r228860.  It pains
> me to no end that we differ from LLVM, because it leads to exactly these
> type of problems where people aren't sure what the exact set of rules are.
>



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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Eugene Zelenko via lldb-commits]

Hi, Todd!

As far as I know Clang-format doesn't leave spaces. Somebody pointed
to old discussion on this matter, but I forgot it locations :-(

I think will be good idea to implement automatic run of Clang-format
as pre-commit hook, since LLDB code have too much diversity in code
formatting for single project.

Eugene.

On Fri, Dec 11, 2015 at 1:55 PM, Todd Fiala  wrote:
> Hey Eugene and Greg,
>
> I thought we were doing spaces before the open parens in places like this:
>
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new
> BreakpointResolverFileLine(nullptr,
>
> (see the removal of the space after BreakpointResolverFileLine from the
> clang-tidy settings I presume).
>
> Did I misunderstand that?
>
> -Todd
>
> On Fri, Dec 11, 2015 at 11:52 AM, Eugene Zelenko via lldb-commits
>  wrote:
>>
>> Author: eugenezelenko
>> Date: Fri Dec 11 13:52:15 2015
>> New Revision: 255364
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=255364&view=rev
>> Log:
>> Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr
>> warnings in source/Target/Target.cpp.
>>
>> Simplify smart pointers checks in conditions.
>>
>> Modified:
>> lldb/trunk/source/Target/Target.cpp
>>
>> Modified: lldb/trunk/source/Target/Target.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Target.cpp?rev=255364&r1=255363&r2=255364&view=diff
>>
>> ==
>> --- lldb/trunk/source/Target/Target.cpp (original)
>> +++ lldb/trunk/source/Target/Target.cpp Fri Dec 11 13:52:15 2015
>> @@ -178,7 +178,7 @@ Target::CleanupProcess ()
>>  void
>>  Target::DeleteCurrentProcess ()
>>  {
>> -if (m_process_sp.get())
>> +if (m_process_sp)
>>  {
>>  m_section_load_history.Clear();
>>  if (m_process_sp->IsAlive())
>> @@ -333,7 +333,7 @@ Target::CreateSourceRegexBreakpoint (con
>>  SearchFilterSP filter_sp(GetSearchFilterForModuleAndCUList
>> (containingModules, source_file_spec_list));
>>  if (move_to_nearest_code == eLazyBoolCalculate)
>>  move_to_nearest_code = GetMoveToNearestCode() ? eLazyBoolYes :
>> eLazyBoolNo;
>> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileRegex
>> (NULL, source_regex, !static_cast(move_to_nearest_code)));
>> +BreakpointResolverSP resolver_sp(new
>> BreakpointResolverFileRegex(nullptr, source_regex,
>> !static_cast(move_to_nearest_code)));
>>  return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware,
>> true);
>>  }
>>
>> @@ -385,12 +385,12 @@ Target::CreateBreakpoint (const FileSpec
>>  if (move_to_nearest_code == eLazyBoolCalculate)
>>  move_to_nearest_code = GetMoveToNearestCode() ? eLazyBoolYes :
>> eLazyBoolNo;
>>
>> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
>> (NULL,
>> -
>> file,
>> -
>> line_no,
>> -
>> check_inlines,
>> -
>> skip_prologue,
>> -
>> !static_cast(move_to_nearest_code)));
>> +BreakpointResolverSP resolver_sp(new
>> BreakpointResolverFileLine(nullptr,
>> +file,
>> +
>> line_no,
>> +
>> check_inlines,
>> +
>> skip_prologue,
>> +
>> !static_cast(move_to_nearest_code)));
>>  return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware,
>> true);
>>  }
>>
>> @@ -420,7 +420,7 @@ BreakpointSP
>>  Target::CreateBreakpoint (const Address &addr, bool internal, bool
>> hardware)
>>  {
>>  SearchFilterSP filter_sp(new SearchFilterForUnconstrainedSearches
>> (shared_from_this()));
>> -BreakpointResolverSP resolver_sp (new BreakpointResolverAddress
>> (NULL, addr));
>> +BreakpointResolverSP resolver_sp(new
>> BreakpointResolverAddress(nullptr, addr));
>>  return CreateBreakpoint (filter_sp, resolver_sp, internal, hardware,
>> false);
>>  }
>>
>> @@ -431,7 +431,7 @@ Target::CreateAddressInModuleBreakpoint
>>   bool request_hardware)
>>  {
>>  SearchFilterSP filter_sp(new SearchFilterForUnconstrainedSearches
>> (shared_from_this()));
>> -BreakpointResolverSP resolver_sp (new BreakpointResolverAddress
>> (NULL, file_addr, file_spec));
>> +BreakpointResolverSP resolver_sp(new
>> BreakpointResolverAddress(nullptr, file_addr, file_spec));
>>  return CreateBreakpoint (filter_sp, resolver_sp, internal,
>> request_hardware, false);
>>  }
>>
>> @@ -455,12 +455,12 @@ Target::CreateBreakpoint (const FileSpec
>>  if (language == lldb::eLanguageTypeUnknown)
>>  language = GetLanguage();
>>
>> -BreakpointResolverSP resolver_sp (new BreakpointResolverName
>> (NULL,
>> -
>> func_name,
>> -
>> func_name_type_mask,
>> -
>> language,
>> -
>> Breakpoint::Exact,
>> -
>> skip_prologue));
>> +BreakpointResolverSP resolver_sp(new
>> BreakpointResolverName(nullptr,
>> +
>> func_name,
>> +
>> func_name_type_mask,
>> +
>> language,
>> +
>> Breakpoint::Exact,
>> +
>> 

Re: [Lldb-commits] [PATCH] D15435: Add tests to inspect a stack and local variables from a mini dump

[Adrian McCarthy via lldb-commits]

amccarth updated this revision to Diff 42575.
amccarth added a comment.

Moved loading of fizzbuzz mini dump to only the tests that needed it.

Moved @skipUnlessWindows to the individual tests.  (I'm not sure how that 
worked before.)

Improved some comments.


http://reviews.llvm.org/D15435

Files:
  packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
  
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
  packages/Python/lldbsuite/test/functionalities/postmortem/minidump/main.cpp

Index: packages/Python/lldbsuite/test/functionalities/postmortem/minidump/main.cpp
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/postmortem/minidump/main.cpp
@@ -0,0 +1,21 @@
+int global = 42;
+
+int
+bar(int x)
+{
+  int y = 4*x + global;
+  return y;
+}
+
+int
+foo(int x)
+{
+  int y = 2*bar(3*x);
+  return y;
+}
+
+int
+main()
+{
+  return 0 * foo(1);
+}
Index: packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
===
--- packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
+++ packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
@@ -10,31 +10,45 @@
 from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
-@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 class MiniDumpTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_process_info_in_mini_dump(self):
 """Test that lldb can read the process information from the minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertTrue(self.process, PROCESS_IS_VALID)
 self.assertEqual(self.process.GetNumThreads(), 1)
 self.assertEqual(self.process.GetProcessID(), 4440)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_thread_info_in_mini_dump(self):
 """Test that lldb can read the thread information from the minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 # This process crashed due to an access violation (0xc005) in its one and only thread.
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
 self.assertEqual(thread.GetStopReason(), lldb.eStopReasonException)
 stop_description = thread.GetStopDescription(256);
 self.assertTrue("0xc005" in stop_description);
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_stack_info_in_mini_dump(self):
-"""Test that we can see the stack."""
+"""Test that we can see a trivial stack in a VS-generate mini dump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
 # The crash is in main, so there should be one frame on the stack.
@@ -46,10 +60,69 @@
 self.assertTrue(eip.IsValid())
 self.assertEqual(pc, eip.GetValueAsUnsigned())
 
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# target create -c fizzbuzz_no_heap.dmp
-self.dbg.CreateTarget("")
-self.target = self.dbg.GetSelectedTarget()
-self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
+@skipUnlessWindows
+@not_remote_testsuite_ready
+def test_deeper_stack_in_mini_dump(self):
+"""Test that we can examine a more interesting stack in a mini dump."""
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+core = os.path.join(os.getcwd(), "core.dmp")
+try:
+# Set a breakpoint and capture a mini dump.
+target = self.dbg.CreateTarget(exe)
+breakpoint = target.BreakpointCreateByName("bar")
+process = target.LaunchSimple(None, None, self.get_process_working_directory())
+self.assertEqual(process.GetState(), lldb.eStateStopped)
+self.assertTrue(process.SaveCore(core))
+self.assertTrue(os.path.isfile(core))
+self.assertTrue(process.Kill().Success())
+
+# Launch with the mini dump

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

On Fri, Dec 11, 2015 at 2:04 PM Zachary Turner  wrote:

> No, sadly.  We still have 4 space indentation, allman style braces, 120
> line character limit, return-type-on-separate-line, and a few other
> differences .  I've
> tried on a couple of occasions to remove some of these differences and move
> closer to LLDB's style, but it has never gone over well.  I plan to keep
> trying until I'm dead or working on something else, so if there's anything
> you can do to help, it would be great :)
>

s/move closer to LLDB's style/move closer to LLVM's style/
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

No, sadly.  We still have 4 space indentation, allman style braces, 120
line character limit, return-type-on-separate-line, and a few other
differences .  I've
tried on a couple of occasions to remove some of these differences and move
closer to LLDB's style, but it has never gone over well.  I plan to keep
trying until I'm dead or working on something else, so if there's anything
you can do to help, it would be great :)

On Fri, Dec 11, 2015 at 2:01 PM Todd Fiala  wrote:

> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
> wrote:
>
>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Hey Eugene and Greg,
>>>
>>> I thought we were doing spaces before the open parens in places like
>>> this:
>>>
>>> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
>>> (NULL,
>>> ...
>>> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
>>> nullptr,
>>>
>>> (see the removal of the space after BreakpointResolverFileLine from the
>>> clang-tidy settings I presume).
>>>
>>> Did I misunderstand that?
>>>
>>
>> This was officially removed from the coding standard some months ago,
>>
>
> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
> can just look there to see what we're supposed to be doing.
>
>
>> but not everyone has adopted this unfortunately.  See r228860.  It pains
>> me to no end that we differ from LLVM, because it leads to exactly these
>> type of problems where people aren't sure what the exact set of rules are.
>>
>
>
>
> --
> -Todd
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

On Fri, Dec 11, 2015 at 2:04 PM, Zachary Turner  wrote:

> No, sadly.  We still have 4 space indentation, allman style braces, 120
> line character limit, return-type-on-separate-line, and a few other
> differences .  I've
> tried on a couple of occasions to remove some of these differences and move
> closer to LLDB's style, but it has never gone over well.  I plan to keep
> trying until I'm dead
>

Eek, hopefully we can solve that before then!


> or working on something else,
>

I vote for us fixing it rather than that :-)


> so if there's anything you can do to help, it would be great :)
>

Okay.  I thought I heard rumor we were adopting LLVM coding style.  I'll
find out what our position is on this.  I just thought the LLVM standard
did include the spaces, but only because of the prolific use of it I saw
over here.

I'll do some digging here.


>
> On Fri, Dec 11, 2015 at 2:01 PM Todd Fiala  wrote:
>
>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>> wrote:
>>
>>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Hey Eugene and Greg,

 I thought we were doing spaces before the open parens in places like
 this:

 -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
 (NULL,
 ...
 +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
 nullptr,

 (see the removal of the space after BreakpointResolverFileLine from the
 clang-tidy settings I presume).

 Did I misunderstand that?

>>>
>>> This was officially removed from the coding standard some months ago,
>>>
>>
>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
>> can just look there to see what we're supposed to be doing.
>>
>>
>>> but not everyone has adopted this unfortunately.  See r228860.  It pains
>>> me to no end that we differ from LLVM, because it leads to exactly these
>>> type of problems where people aren't sure what the exact set of rules are.
>>>
>>
>>
>>
>> --
>> -Todd
>>
>


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

On Fri, Dec 11, 2015 at 2:10 PM, Todd Fiala  wrote:

>
>
> On Fri, Dec 11, 2015 at 2:04 PM, Zachary Turner 
> wrote:
>
>> No, sadly.  We still have 4 space indentation, allman style braces, 120
>> line character limit, return-type-on-separate-line, and a few other
>> differences .  I've
>> tried on a couple of occasions to remove some of these differences and move
>> closer to LLDB's style, but it has never gone over well.  I plan to keep
>> trying until I'm dead
>>
>
> Eek, hopefully we can solve that before then!
>
>
>> or working on something else,
>>
>
> I vote for us fixing it rather than that :-)
>
>
>> so if there's anything you can do to help, it would be great :)
>>
>
> Okay.  I thought I heard rumor we were adopting LLVM coding style.
>

Er, rather that we already did.


> I'll find out what our position is on this.  I just thought the LLVM
> standard did include the spaces, but only because of the prolific use of it
> I saw over here.
>
> I'll do some digging here.
>
>
>>
>> On Fri, Dec 11, 2015 at 2:01 PM Todd Fiala  wrote:
>>
>>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>>> wrote:
>>>
 On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Hey Eugene and Greg,
>
> I thought we were doing spaces before the open parens in places like
> this:
>
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
> (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
> nullptr,
>
> (see the removal of the space after BreakpointResolverFileLine from
> the clang-tidy settings I presume).
>
> Did I misunderstand that?
>

 This was officially removed from the coding standard some months ago,

>>>
>>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so
>>> I can just look there to see what we're supposed to be doing.
>>>
>>>
 but not everyone has adopted this unfortunately.  See r228860.  It
 pains me to no end that we differ from LLVM, because it leads to exactly
 these type of problems where people aren't sure what the exact set of rules
 are.

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>
>
> --
> -Todd
>



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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Jim Ingham via lldb-commits]

> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits 
>  wrote:
> 
> 
> 
> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner  > wrote:
> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Hey Eugene and Greg,
> 
> I thought we were doing spaces before the open parens in places like this:
> 
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(nullptr,
> 
> (see the removal of the space after BreakpointResolverFileLine from the 
> clang-tidy settings I presume).
> 
> Did I misunderstand that?
> 
> This was officially removed from the coding standard some months ago,
> 
> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I can 
> just look there to see what we're supposed to be doing.

No, the differences between the lldb and llvm coding standards are documented 
in:

http://lldb.llvm.org/lldb-coding-conventions.html

Jim

>  
> but not everyone has adopted this unfortunately.  See r228860.  It pains me 
> to no end that we differ from LLVM, because it leads to exactly these type of 
> problems where people aren't sure what the exact set of rules are.
> 
> 
> 
> -- 
> -Todd
> ___
> 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] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

On Fri, Dec 11, 2015 at 2:11 PM Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> On Fri, Dec 11, 2015 at 2:02 PM, Eugene Zelenko 
> wrote:
>
>> Hi, Todd!
>>
>> As far as I know Clang-format doesn't leave spaces. Somebody pointed
>> to old discussion on this matter, but I forgot it locations :-(
>>
>> I think will be good idea to implement automatic run of Clang-format
>> as pre-commit hook, since LLDB code have too much diversity in code
>> formatting for single project.
>>
>
> I like the pre-commit hook idea.  Have we attempted to pursue this in the
> past?
>

Biggest problem with commit hook is that it will format lines that you
specifically don't want formatted.  See for example all the option tables
in Command*.cpp files
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

It would be a great start if we could just get everyone to actually run
clang-format manually.  There are two outstanding issues with clang-format
that dont' support LLDB style.  Those two issues would go away if: 1) LLDB
abandoned those styles and adoped LLVM's style (preferred), or 2) I fix
clang-format to support them.  I keep promising to do #2, but I haven't yet
because it seems like I'm the only using clang-format anyway.  If there
were assurances that more people would start using it, I would
re-prioritize.

On Fri, Dec 11, 2015 at 2:12 PM Zachary Turner  wrote:

> On Fri, Dec 11, 2015 at 2:11 PM Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> On Fri, Dec 11, 2015 at 2:02 PM, Eugene Zelenko > > wrote:
>>
>>> Hi, Todd!
>>>
>>> As far as I know Clang-format doesn't leave spaces. Somebody pointed
>>> to old discussion on this matter, but I forgot it locations :-(
>>>
>>> I think will be good idea to implement automatic run of Clang-format
>>> as pre-commit hook, since LLDB code have too much diversity in code
>>> formatting for single project.
>>>
>>
>> I like the pre-commit hook idea.  Have we attempted to pursue this in the
>> past?
>>
>
> Biggest problem with commit hook is that it will format lines that you
> specifically don't want formatted.  See for example all the option tables
> in Command*.cpp files
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

Yep - sorry.  I had been talking to Greg about this and misunderstood his
comment on it. My mistake entirely.  Kate and I just talked and she pointed
me to your document, Jim.

The description was:
where we had a clearly adhered to standard, keep it.
whee we didn't, we adopted LLVM.

Sorry for rehashing!

-Todd

On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:

>
> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
>
> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
> wrote:
>
>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Hey Eugene and Greg,
>>>
>>> I thought we were doing spaces before the open parens in places like
>>> this:
>>>
>>> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
>>> (NULL,
>>> ...
>>> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
>>> nullptr,
>>>
>>> (see the removal of the space after BreakpointResolverFileLine from the
>>> clang-tidy settings I presume).
>>>
>>> Did I misunderstand that?
>>>
>>
>> This was officially removed from the coding standard some months ago,
>>
>
> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
> can just look there to see what we're supposed to be doing.
>
>
> No, the differences between the lldb and llvm coding standards are
> documented in:
>
> http://lldb.llvm.org/lldb-coding-conventions.html
>
> Jim
>
>
>
>> but not everyone has adopted this unfortunately.  See r228860.  It pains
>> me to no end that we differ from LLVM, because it leads to exactly these
>> type of problems where people aren't sure what the exact set of rules are.
>>
>
>
>
> --
> -Todd
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
>


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

Back on the topic of clang-format, what would it take to make clang-format
a regular part of peoples' workflows?

On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala  wrote:

> Yep - sorry.  I had been talking to Greg about this and misunderstood his
> comment on it. My mistake entirely.  Kate and I just talked and she pointed
> me to your document, Jim.
>
> The description was:
> where we had a clearly adhered to standard, keep it.
> whee we didn't, we adopted LLVM.
>
> Sorry for rehashing!
>
> -Todd
>
> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
>
>>
>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>
>>
>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>> wrote:
>>
>>> On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Hey Eugene and Greg,

 I thought we were doing spaces before the open parens in places like
 this:

 -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
 (NULL,
 ...
 +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
 nullptr,

 (see the removal of the space after BreakpointResolverFileLine from the
 clang-tidy settings I presume).

 Did I misunderstand that?

>>>
>>> This was officially removed from the coding standard some months ago,
>>>
>>
>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
>> can just look there to see what we're supposed to be doing.
>>
>>
>> No, the differences between the lldb and llvm coding standards are
>> documented in:
>>
>> http://lldb.llvm.org/lldb-coding-conventions.html
>>
>> Jim
>>
>>
>>
>>> but not everyone has adopted this unfortunately.  See r228860.  It pains
>>> me to no end that we differ from LLVM, because it leads to exactly these
>>> type of problems where people aren't sure what the exact set of rules are.
>>>
>>
>>
>>
>> --
>> -Todd
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>>
>>
>
>
> --
> -Todd
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r255379 - Add some tests for stack and local variable inspection for mini dumps.

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Fri Dec 11 16:27:57 2015
New Revision: 255379

URL: http://llvm.org/viewvc/llvm-project?rev=255379&view=rev
Log:
Add some tests for stack and local variable inspection for mini dumps.

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

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/main.cpp
Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile?rev=255379&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
 Fri Dec 11 16:27:57 2015
@@ -0,0 +1,6 @@
+LEVEL = ../../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules
+

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py?rev=255379&r1=255378&r2=255379&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
 Fri Dec 11 16:27:57 2015
@@ -10,21 +10,30 @@ import lldb
 from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
-@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 class MiniDumpTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows 
hosts
 @no_debug_info_test
 def test_process_info_in_mini_dump(self):
 """Test that lldb can read the process information from the 
minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertTrue(self.process, PROCESS_IS_VALID)
 self.assertEqual(self.process.GetNumThreads(), 1)
 self.assertEqual(self.process.GetProcessID(), 4440)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows 
hosts
 @no_debug_info_test
 def test_thread_info_in_mini_dump(self):
 """Test that lldb can read the thread information from the minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 # This process crashed due to an access violation (0xc005) in its 
one and only thread.
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
@@ -32,9 +41,14 @@ class MiniDumpTestCase(TestBase):
 stop_description = thread.GetStopDescription(256);
 self.assertTrue("0xc005" in stop_description);
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows 
hosts
 @no_debug_info_test
 def test_stack_info_in_mini_dump(self):
-"""Test that we can see the stack."""
+"""Test that we can see a trivial stack in a VS-generate mini dump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
 # The crash is in main, so there should be one frame on the stack.
@@ -46,10 +60,69 @@ class MiniDumpTestCase(TestBase):
 self.assertTrue(eip.IsValid())
 self.assertEqual(pc, eip.GetValueAsUnsigned())
 
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# target create -c fizzbuzz_no_heap.dmp
-self.dbg.CreateTarget("")
-self.target = self.dbg.GetSelectedTarget()
-self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
+@skipUnlessWindows
+@not_remote_testsuite_ready
+def test_deeper_stack_in_mini_dump(self):
+"""Test that we can examine a more interesting stack in a mini dump."""
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+core = os.path.join(os.getcwd(), "core.dmp")
+try:
+# Set a 

Re: [Lldb-commits] [PATCH] D15435: Add tests to inspect a stack and local variables from a mini dump

[Adrian McCarthy via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL255379: Add some tests for stack and local variable 
inspection for mini dumps. (authored by amccarth).

Changed prior to commit:
  http://reviews.llvm.org/D15435?vs=42575&id=42585#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D15435

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/main.cpp

Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../../make
+
+CXX_SOURCES := main.cpp
+
+include $(LEVEL)/Makefile.rules
+
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
@@ -10,31 +10,45 @@
 from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
-@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 class MiniDumpTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_process_info_in_mini_dump(self):
 """Test that lldb can read the process information from the minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertTrue(self.process, PROCESS_IS_VALID)
 self.assertEqual(self.process.GetNumThreads(), 1)
 self.assertEqual(self.process.GetProcessID(), 4440)
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_thread_info_in_mini_dump(self):
 """Test that lldb can read the thread information from the minidump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 # This process crashed due to an access violation (0xc005) in its one and only thread.
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
 self.assertEqual(thread.GetStopReason(), lldb.eStopReasonException)
 stop_description = thread.GetStopDescription(256);
 self.assertTrue("0xc005" in stop_description);
 
+@skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
 @no_debug_info_test
 def test_stack_info_in_mini_dump(self):
-"""Test that we can see the stack."""
+"""Test that we can see a trivial stack in a VS-generate mini dump."""
+# target create -c fizzbuzz_no_heap.dmp
+self.dbg.CreateTarget("")
+self.target = self.dbg.GetSelectedTarget()
+self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
 self.assertEqual(self.process.GetNumThreads(), 1)
 thread = self.process.GetThreadAtIndex(0)
 # The crash is in main, so there should be one frame on the stack.
@@ -46,10 +60,69 @@
 self.assertTrue(eip.IsValid())
 self.assertEqual(pc, eip.GetValueAsUnsigned())
 
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# target create -c fizzbuzz_no_heap.dmp
-self.dbg.CreateTarget("")
-self.target = self.dbg.GetSelectedTarget()
-self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
+@skipUnlessWindows
+@not_remote_testsuite_ready
+def test_deeper_stack_in_mini_dump(self):
+"""Test that we can examine a more interesting stack in a mini dump."""
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+core = os.path.join(os.getcwd(), "core.dmp")
+try:
+# Set a breakpoint and capture a mini dump.
+target = self.dbg.CreateTarget(exe)
+breakpoint = target.BreakpointCreateByName("bar")
+process = target.LaunchSimple(None, None, self.get_process_working_directory())
+self.assertEqual(process.GetState(), lldb.eStateStopped)
+self.assertTrue(process.SaveCore(core))
+self.assertTrue(os.path.isf

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Eugene Zelenko via lldb-commits]

At least clang-format should be applied to all newly added files before commit.

Eugene.

On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner  wrote:
> Back on the topic of clang-format, what would it take to make clang-format a
> regular part of peoples' workflows?
>
> On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala  wrote:
>>
>> Yep - sorry.  I had been talking to Greg about this and misunderstood his
>> comment on it. My mistake entirely.  Kate and I just talked and she pointed
>> me to your document, Jim.
>>
>> The description was:
>> where we had a clearly adhered to standard, keep it.
>> whee we didn't, we adopted LLVM.
>>
>> Sorry for rehashing!
>>
>> -Todd
>>
>> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
>>>
>>>
>>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>>>  wrote:
>>>
>>>
>>>
>>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>>> wrote:

 On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
  wrote:
>
> Hey Eugene and Greg,
>
> I thought we were doing spaces before the open parens in places like
> this:
>
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
> (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new
> BreakpointResolverFileLine(nullptr,
>
> (see the removal of the space after BreakpointResolverFileLine from the
> clang-tidy settings I presume).
>
> Did I misunderstand that?


 This was officially removed from the coding standard some months ago,
>>>
>>>
>>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
>>> can just look there to see what we're supposed to be doing.
>>>
>>>
>>> No, the differences between the lldb and llvm coding standards are
>>> documented in:
>>>
>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>
>>> Jim
>>>
>>>

 but not everyone has adopted this unfortunately.  See r228860.  It pains
 me to no end that we differ from LLVM, because it leads to exactly these
 type of problems where people aren't sure what the exact set of rules are.
>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>>
>>>
>>
>>
>>
>> --
>> -Todd
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

As long as we have a style that matches our style guidelines, I imagine we
can ask "set it up like so" if we can hook it into svn or git.  I haven't
done the pre-commit hooks myself, so I'd need somebody to tell me how to do
that.  But I suppose that's a good start.

On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner  wrote:

> Back on the topic of clang-format, what would it take to make clang-format
> a regular part of peoples' workflows?
>
> On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala  wrote:
>
>> Yep - sorry.  I had been talking to Greg about this and misunderstood his
>> comment on it. My mistake entirely.  Kate and I just talked and she pointed
>> me to your document, Jim.
>>
>> The description was:
>> where we had a clearly adhered to standard, keep it.
>> whee we didn't, we adopted LLVM.
>>
>> Sorry for rehashing!
>>
>> -Todd
>>
>> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
>>
>>>
>>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
>>>
>>>
>>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>>> wrote:
>>>
 On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Hey Eugene and Greg,
>
> I thought we were doing spaces before the open parens in places like
> this:
>
> -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
> (NULL,
> ...
> +BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine(
> nullptr,
>
> (see the removal of the space after BreakpointResolverFileLine from
> the clang-tidy settings I presume).
>
> Did I misunderstand that?
>

 This was officially removed from the coding standard some months ago,

>>>
>>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so
>>> I can just look there to see what we're supposed to be doing.
>>>
>>>
>>> No, the differences between the lldb and llvm coding standards are
>>> documented in:
>>>
>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>
>>> Jim
>>>
>>>
>>>
 but not everyone has adopted this unfortunately.  See r228860.  It
 pains me to no end that we differ from LLVM, because it leads to exactly
 these type of problems where people aren't sure what the exact set of rules
 are.

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


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

[Lldb-commits] [lldb] r255381 - Revert "Revert "Turn on new test summary results by default.""

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Fri Dec 11 16:29:34 2015
New Revision: 255381

URL: http://llvm.org/viewvc/llvm-project?rev=255381&view=rev
Log:
Revert "Revert "Turn on new test summary results by default.""

This reverts commit f994b46a2028c8a8b9b55fe010a95122bca07540.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/dotest.py
lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255381&r1=255380&r2=255381&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11 16:29:34 2015
@@ -387,6 +387,12 @@ def parseOptionsAndInitTestdirs():
 if args.results_formatter_options:
 configuration.results_formatter_options = 
args.results_formatter_options
 
+# Default to using the BasicResultsFormatter if no formatter is specified
+# and we're not a test inferior.
+if not args.inferior and configuration.results_formatter_name is None:
+configuration.results_formatter_name = (
+"lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
+
 if args.lldb_platform_name:
 configuration.lldb_platform_name = args.lldb_platform_name
 if args.lldb_platform_url:

Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255381&r1=255380&r2=255381&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec 11 
16:29:34 2015
@@ -738,8 +738,9 @@ class ResultsFormatter(object):
 
 if event_type == "terminate":
 self.terminate_called = True
-elif (event_type == EventBuilder.TYPE_TEST_RESULT or
-event_type == EventBuilder.TYPE_JOB_RESULT):
+elif event_type in [
+EventBuilder.TYPE_TEST_RESULT,
+EventBuilder.TYPE_JOB_RESULT]:
 # Keep track of event counts per test/job result status type.
 # The only job (i.e. inferior process) results that make it
 # here are ones that cannot be remapped to the most recently


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

Re: [Lldb-commits] [lldb] r255381 - Revert "Revert "Turn on new test summary results by default.""

[Todd Fiala via lldb-commits]

Hopefully we're good with this now that r255363 went in.

We'll revert this again if we still have trouble on the Ubuntu 14.04
builder.

On Fri, Dec 11, 2015 at 2:29 PM, Todd Fiala via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: tfiala
> Date: Fri Dec 11 16:29:34 2015
> New Revision: 255381
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255381&view=rev
> Log:
> Revert "Revert "Turn on new test summary results by default.""
>
> This reverts commit f994b46a2028c8a8b9b55fe010a95122bca07540.
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dotest.py?rev=255381&r1=255380&r2=255381&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/dotest.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py Fri Dec 11
> 16:29:34 2015
> @@ -387,6 +387,12 @@ def parseOptionsAndInitTestdirs():
>  if args.results_formatter_options:
>  configuration.results_formatter_options =
> args.results_formatter_options
>
> +# Default to using the BasicResultsFormatter if no formatter is
> specified
> +# and we're not a test inferior.
> +if not args.inferior and configuration.results_formatter_name is None:
> +configuration.results_formatter_name = (
> +
> "lldbsuite.test.basic_results_formatter.BasicResultsFormatter")
> +
>  if args.lldb_platform_name:
>  configuration.lldb_platform_name = args.lldb_platform_name
>  if args.lldb_platform_url:
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255381&r1=255380&r2=255381&view=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
> (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec
> 11 16:29:34 2015
> @@ -738,8 +738,9 @@ class ResultsFormatter(object):
>
>  if event_type == "terminate":
>  self.terminate_called = True
> -elif (event_type == EventBuilder.TYPE_TEST_RESULT or
> -event_type == EventBuilder.TYPE_JOB_RESULT):
> +elif event_type in [
> +EventBuilder.TYPE_TEST_RESULT,
> +EventBuilder.TYPE_JOB_RESULT]:
>  # Keep track of event counts per test/job result status
> type.
>  # The only job (i.e. inferior process) results that make
> it
>  # here are ones that cannot be remapped to the most
> recently
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>



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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

With git you can already run "git clang-format".  You just need
`git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
sure how to hook it into SVN

On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
wrote:

> At least clang-format should be applied to all newly added files before
> commit.
>
> Eugene.
>
> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
> wrote:
> > Back on the topic of clang-format, what would it take to make
> clang-format a
> > regular part of peoples' workflows?
> >
> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala  wrote:
> >>
> >> Yep - sorry.  I had been talking to Greg about this and misunderstood
> his
> >> comment on it. My mistake entirely.  Kate and I just talked and she
> pointed
> >> me to your document, Jim.
> >>
> >> The description was:
> >> where we had a clearly adhered to standard, keep it.
> >> whee we didn't, we adopted LLVM.
> >>
> >> Sorry for rehashing!
> >>
> >> -Todd
> >>
> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
> >>>
> >>>
> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
> >>>  wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
> >>> wrote:
> 
>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>   wrote:
> >
> > Hey Eugene and Greg,
> >
> > I thought we were doing spaces before the open parens in places like
> > this:
> >
> > -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
> > (NULL,
> > ...
> > +BreakpointResolverSP resolver_sp(new
> > BreakpointResolverFileLine(nullptr,
> >
> > (see the removal of the space after BreakpointResolverFileLine from
> the
> > clang-tidy settings I presume).
> >
> > Did I misunderstand that?
> 
> 
>  This was officially removed from the coding standard some months ago,
> >>>
> >>>
> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If
> so I
> >>> can just look there to see what we're supposed to be doing.
> >>>
> >>>
> >>> No, the differences between the lldb and llvm coding standards are
> >>> documented in:
> >>>
> >>> http://lldb.llvm.org/lldb-coding-conventions.html
> >>>
> >>> Jim
> >>>
> >>>
> 
>  but not everyone has adopted this unfortunately.  See r228860.  It
> pains
>  me to no end that we differ from LLVM, because it leads to exactly
> these
>  type of problems where people aren't sure what the exact set of rules
> are.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -Todd
> >>> ___
> >>> lldb-commits mailing list
> >>> lldb-commits@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> -Todd
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

Okay, but does the format match the LLDB-modified format with some kind of
configuration file?  We still need to match our guidelines here:

http://lldb.llvm.org/lldb-coding-conventions.html

We can achieve that with a config file for it, right?  (Maybe already
existing, maybe in the lldb source tree already?)

On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner  wrote:

> With git you can already run "git clang-format".  You just need
> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
> sure how to hook it into SVN
>
> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
> wrote:
>
>> At least clang-format should be applied to all newly added files before
>> commit.
>>
>> Eugene.
>>
>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>> wrote:
>> > Back on the topic of clang-format, what would it take to make
>> clang-format a
>> > regular part of peoples' workflows?
>> >
>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>> wrote:
>> >>
>> >> Yep - sorry.  I had been talking to Greg about this and misunderstood
>> his
>> >> comment on it. My mistake entirely.  Kate and I just talked and she
>> pointed
>> >> me to your document, Jim.
>> >>
>> >> The description was:
>> >> where we had a clearly adhered to standard, keep it.
>> >> whee we didn't, we adopted LLVM.
>> >>
>> >> Sorry for rehashing!
>> >>
>> >> -Todd
>> >>
>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
>> >>>
>> >>>
>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>> >>>  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>> >>> wrote:
>> 
>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>   wrote:
>> >
>> > Hey Eugene and Greg,
>> >
>> > I thought we were doing spaces before the open parens in places like
>> > this:
>> >
>> > -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
>> > (NULL,
>> > ...
>> > +BreakpointResolverSP resolver_sp(new
>> > BreakpointResolverFileLine(nullptr,
>> >
>> > (see the removal of the space after BreakpointResolverFileLine from
>> the
>> > clang-tidy settings I presume).
>> >
>> > Did I misunderstand that?
>> 
>> 
>>  This was officially removed from the coding standard some months ago,
>> >>>
>> >>>
>> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If
>> so I
>> >>> can just look there to see what we're supposed to be doing.
>> >>>
>> >>>
>> >>> No, the differences between the lldb and llvm coding standards are
>> >>> documented in:
>> >>>
>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>> >>>
>> >>> Jim
>> >>>
>> >>>
>> 
>>  but not everyone has adopted this unfortunately.  See r228860.  It
>> pains
>>  me to no end that we differ from LLVM, because it leads to exactly
>> these
>>  type of problems where people aren't sure what the exact set of
>> rules are.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> -Todd
>> >>> ___
>> >>> lldb-commits mailing list
>> >>> lldb-commits@lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> -Todd
>>
>


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Eugene Zelenko via lldb-commits]

Yes, it's in the .clang-format at LLDB source root.

Eugene.

On Fri, Dec 11, 2015 at 2:37 PM, Todd Fiala  wrote:
> Okay, but does the format match the LLDB-modified format with some kind of
> configuration file?  We still need to match our guidelines here:
>
> http://lldb.llvm.org/lldb-coding-conventions.html
>
> We can achieve that with a config file for it, right?  (Maybe already
> existing, maybe in the lldb source tree already?)
>
> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner  wrote:
>>
>> With git you can already run "git clang-format".  You just need
>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>> sure how to hook it into SVN
>>
>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
>> wrote:
>>>
>>> At least clang-format should be applied to all newly added files before
>>> commit.
>>>
>>> Eugene.
>>>
>>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>>> wrote:
>>> > Back on the topic of clang-format, what would it take to make
>>> > clang-format a
>>> > regular part of peoples' workflows?
>>> >
>>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>>> > wrote:
>>> >>
>>> >> Yep - sorry.  I had been talking to Greg about this and misunderstood
>>> >> his
>>> >> comment on it. My mistake entirely.  Kate and I just talked and she
>>> >> pointed
>>> >> me to your document, Jim.
>>> >>
>>> >> The description was:
>>> >> where we had a clearly adhered to standard, keep it.
>>> >> whee we didn't, we adopted LLVM.
>>> >>
>>> >> Sorry for rehashing!
>>> >>
>>> >> -Todd
>>> >>
>>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  wrote:
>>> >>>
>>> >>>
>>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>>> >>>  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>>> >>> wrote:
>>> 
>>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>>   wrote:
>>> >
>>> > Hey Eugene and Greg,
>>> >
>>> > I thought we were doing spaces before the open parens in places
>>> > like
>>> > this:
>>> >
>>> > -BreakpointResolverSP resolver_sp(new
>>> > BreakpointResolverFileLine
>>> > (NULL,
>>> > ...
>>> > +BreakpointResolverSP resolver_sp(new
>>> > BreakpointResolverFileLine(nullptr,
>>> >
>>> > (see the removal of the space after BreakpointResolverFileLine from
>>> > the
>>> > clang-tidy settings I presume).
>>> >
>>> > Did I misunderstand that?
>>> 
>>> 
>>>  This was officially removed from the coding standard some months
>>>  ago,
>>> >>>
>>> >>>
>>> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If
>>> >>> so I
>>> >>> can just look there to see what we're supposed to be doing.
>>> >>>
>>> >>>
>>> >>> No, the differences between the lldb and llvm coding standards are
>>> >>> documented in:
>>> >>>
>>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>>> >>>
>>> >>> Jim
>>> >>>
>>> >>>
>>> 
>>>  but not everyone has adopted this unfortunately.  See r228860.  It
>>>  pains
>>>  me to no end that we differ from LLVM, because it leads to exactly
>>>  these
>>>  type of problems where people aren't sure what the exact set of
>>>  rules are.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> -Todd
>>> >>> ___
>>> >>> lldb-commits mailing list
>>> >>> lldb-commits@lists.llvm.org
>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> -Todd
>
>
>
>
> --
> -Todd
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

Yes, but as I mentioned, two things are still unsupported due to
limitations in clang-format.  They are return-type-on-new-line (only in
declarations.  clang-format supports it for definitions) and the
constructor initializer list comma at the end (clang-format puts it at the
beginning).

That said, the comma at the end of initializer list isn't documented on
that page, and where we don't have a clearly documented rule, prefer the
LLVM guidelines, so

On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:

> Okay, but does the format match the LLDB-modified format with some kind of
> configuration file?  We still need to match our guidelines here:
>
> http://lldb.llvm.org/lldb-coding-conventions.html
>
> We can achieve that with a config file for it, right?  (Maybe already
> existing, maybe in the lldb source tree already?)
>
> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
> wrote:
>
>> With git you can already run "git clang-format".  You just need
>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>> sure how to hook it into SVN
>>
>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
>> wrote:
>>
>>> At least clang-format should be applied to all newly added files before
>>> commit.
>>>
>>> Eugene.
>>>
>>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>>> wrote:
>>> > Back on the topic of clang-format, what would it take to make
>>> clang-format a
>>> > regular part of peoples' workflows?
>>> >
>>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>>> wrote:
>>> >>
>>> >> Yep - sorry.  I had been talking to Greg about this and misunderstood
>>> his
>>> >> comment on it. My mistake entirely.  Kate and I just talked and she
>>> pointed
>>> >> me to your document, Jim.
>>> >>
>>> >> The description was:
>>> >> where we had a clearly adhered to standard, keep it.
>>> >> whee we didn't, we adopted LLVM.
>>> >>
>>> >> Sorry for rehashing!
>>> >>
>>> >> -Todd
>>> >>
>>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
>>> wrote:
>>> >>>
>>> >>>
>>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>>> >>>  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner 
>>> >>> wrote:
>>> 
>>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>>   wrote:
>>> >
>>> > Hey Eugene and Greg,
>>> >
>>> > I thought we were doing spaces before the open parens in places
>>> like
>>> > this:
>>> >
>>> > -BreakpointResolverSP resolver_sp(new
>>> BreakpointResolverFileLine
>>> > (NULL,
>>> > ...
>>> > +BreakpointResolverSP resolver_sp(new
>>> > BreakpointResolverFileLine(nullptr,
>>> >
>>> > (see the removal of the space after BreakpointResolverFileLine
>>> from the
>>> > clang-tidy settings I presume).
>>> >
>>> > Did I misunderstand that?
>>> 
>>> 
>>>  This was officially removed from the coding standard some months
>>> ago,
>>> >>>
>>> >>>
>>> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If
>>> so I
>>> >>> can just look there to see what we're supposed to be doing.
>>> >>>
>>> >>>
>>> >>> No, the differences between the lldb and llvm coding standards are
>>> >>> documented in:
>>> >>>
>>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>>> >>>
>>> >>> Jim
>>> >>>
>>> >>>
>>> 
>>>  but not everyone has adopted this unfortunately.  See r228860.  It
>>> pains
>>>  me to no end that we differ from LLVM, because it leads to exactly
>>> these
>>>  type of problems where people aren't sure what the exact set of
>>> rules are.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> -Todd
>>> >>> ___
>>> >>> lldb-commits mailing list
>>> >>> lldb-commits@lists.llvm.org
>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> -Todd
>>>
>>
>
>
> --
> -Todd
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

Okay.  Ending a line with arbitrary whitespace seems wrong as just about
any colorizing editor or diff will flag, but I'll survive :-)

On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner  wrote:

> Yes, but as I mentioned, two things are still unsupported due to
> limitations in clang-format.  They are return-type-on-new-line (only in
> declarations.  clang-format supports it for definitions) and the
> constructor initializer list comma at the end (clang-format puts it at the
> beginning).
>
> That said, the comma at the end of initializer list isn't documented on
> that page, and where we don't have a clearly documented rule, prefer the
> LLVM guidelines, so
>
>
> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>
>> Okay, but does the format match the LLDB-modified format with some kind
>> of configuration file?  We still need to match our guidelines here:
>>
>> http://lldb.llvm.org/lldb-coding-conventions.html
>>
>> We can achieve that with a config file for it, right?  (Maybe already
>> existing, maybe in the lldb source tree already?)
>>
>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>> wrote:
>>
>>> With git you can already run "git clang-format".  You just need
>>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>>> sure how to hook it into SVN
>>>
>>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
>>> wrote:
>>>
 At least clang-format should be applied to all newly added files before
 commit.

 Eugene.

 On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
 wrote:
 > Back on the topic of clang-format, what would it take to make
 clang-format a
 > regular part of peoples' workflows?
 >
 > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
 wrote:
 >>
 >> Yep - sorry.  I had been talking to Greg about this and
 misunderstood his
 >> comment on it. My mistake entirely.  Kate and I just talked and she
 pointed
 >> me to your document, Jim.
 >>
 >> The description was:
 >> where we had a clearly adhered to standard, keep it.
 >> whee we didn't, we adopted LLVM.
 >>
 >> Sorry for rehashing!
 >>
 >> -Todd
 >>
 >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
 wrote:
 >>>
 >>>
 >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
 >>>  wrote:
 >>>
 >>>
 >>>
 >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner >>> >
 >>> wrote:
 
  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
   wrote:
 >
 > Hey Eugene and Greg,
 >
 > I thought we were doing spaces before the open parens in places
 like
 > this:
 >
 > -BreakpointResolverSP resolver_sp(new
 BreakpointResolverFileLine
 > (NULL,
 > ...
 > +BreakpointResolverSP resolver_sp(new
 > BreakpointResolverFileLine(nullptr,
 >
 > (see the removal of the space after BreakpointResolverFileLine
 from the
 > clang-tidy settings I presume).
 >
 > Did I misunderstand that?
 
 
  This was officially removed from the coding standard some months
 ago,
 >>>
 >>>
 >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?
 If so I
 >>> can just look there to see what we're supposed to be doing.
 >>>
 >>>
 >>> No, the differences between the lldb and llvm coding standards are
 >>> documented in:
 >>>
 >>> http://lldb.llvm.org/lldb-coding-conventions.html
 >>>
 >>> Jim
 >>>
 >>>
 
  but not everyone has adopted this unfortunately.  See r228860.  It
 pains
  me to no end that we differ from LLVM, because it leads to exactly
 these
  type of problems where people aren't sure what the exact set of
 rules are.
 >>>
 >>>
 >>>
 >>>
 >>> --
 >>> -Todd
 >>> ___
 >>> lldb-commits mailing list
 >>> lldb-commits@lists.llvm.org
 >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
 >>>
 >>>
 >>
 >>
 >>
 >> --
 >> -Todd

>>>
>>
>>
>> --
>> -Todd
>>
>


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner  wrote:

> Yes, but as I mentioned, two things are still unsupported due to
> limitations in clang-format.  They are return-type-on-new-line (only in
> declarations.  clang-format supports it for definitions) and the
> constructor initializer list comma at the end (clang-format puts it at the
> beginning).
>
>
What's the right workaround (i.e. as good as it gets) for a workflow with
clang-tidy and the issue above, while adhering to our coding standard?  Is
this something we can add an option for in clang-tidy, and should we do
that?


> That said, the comma at the end of initializer list isn't documented on
> that page, and where we don't have a clearly documented rule, prefer the
> LLVM guidelines, so
>
>
> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>
>> Okay, but does the format match the LLDB-modified format with some kind
>> of configuration file?  We still need to match our guidelines here:
>>
>> http://lldb.llvm.org/lldb-coding-conventions.html
>>
>> We can achieve that with a config file for it, right?  (Maybe already
>> existing, maybe in the lldb source tree already?)
>>
>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>> wrote:
>>
>>> With git you can already run "git clang-format".  You just need
>>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>>> sure how to hook it into SVN
>>>
>>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
>>> wrote:
>>>
 At least clang-format should be applied to all newly added files before
 commit.

 Eugene.

 On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
 wrote:
 > Back on the topic of clang-format, what would it take to make
 clang-format a
 > regular part of peoples' workflows?
 >
 > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
 wrote:
 >>
 >> Yep - sorry.  I had been talking to Greg about this and
 misunderstood his
 >> comment on it. My mistake entirely.  Kate and I just talked and she
 pointed
 >> me to your document, Jim.
 >>
 >> The description was:
 >> where we had a clearly adhered to standard, keep it.
 >> whee we didn't, we adopted LLVM.
 >>
 >> Sorry for rehashing!
 >>
 >> -Todd
 >>
 >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
 wrote:
 >>>
 >>>
 >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
 >>>  wrote:
 >>>
 >>>
 >>>
 >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner >>> >
 >>> wrote:
 
  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
   wrote:
 >
 > Hey Eugene and Greg,
 >
 > I thought we were doing spaces before the open parens in places
 like
 > this:
 >
 > -BreakpointResolverSP resolver_sp(new
 BreakpointResolverFileLine
 > (NULL,
 > ...
 > +BreakpointResolverSP resolver_sp(new
 > BreakpointResolverFileLine(nullptr,
 >
 > (see the removal of the space after BreakpointResolverFileLine
 from the
 > clang-tidy settings I presume).
 >
 > Did I misunderstand that?
 
 
  This was officially removed from the coding standard some months
 ago,
 >>>
 >>>
 >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?
 If so I
 >>> can just look there to see what we're supposed to be doing.
 >>>
 >>>
 >>> No, the differences between the lldb and llvm coding standards are
 >>> documented in:
 >>>
 >>> http://lldb.llvm.org/lldb-coding-conventions.html
 >>>
 >>> Jim
 >>>
 >>>
 
  but not everyone has adopted this unfortunately.  See r228860.  It
 pains
  me to no end that we differ from LLVM, because it leads to exactly
 these
  type of problems where people aren't sure what the exact set of
 rules are.
 >>>
 >>>
 >>>
 >>>
 >>> --
 >>> -Todd
 >>> ___
 >>> lldb-commits mailing list
 >>> lldb-commits@lists.llvm.org
 >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
 >>>
 >>>
 >>
 >>
 >>
 >> --
 >> -Todd

>>>
>>
>>
>> --
>> -Todd
>>
>


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

No I'm not talking about whitespace at the end of a line, I'm saying LLVM's
style (and what clang-format does) is this:

Foo::Foo()
   : member_1()
   , member_2()
   , member_3()

and what LLDB wants is this:

Foo::Foo() :
member1(),
member2(),
member3()

Neither one have whitespace at the end of a line.

On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala  wrote:

> Okay.  Ending a line with arbitrary whitespace seems wrong as just about
> any colorizing editor or diff will flag, but I'll survive :-)
>
> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
> wrote:
>
>> Yes, but as I mentioned, two things are still unsupported due to
>> limitations in clang-format.  They are return-type-on-new-line (only in
>> declarations.  clang-format supports it for definitions) and the
>> constructor initializer list comma at the end (clang-format puts it at the
>> beginning).
>>
>> That said, the comma at the end of initializer list isn't documented on
>> that page, and where we don't have a clearly documented rule, prefer the
>> LLVM guidelines, so
>>
>>
>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>>
>>> Okay, but does the format match the LLDB-modified format with some kind
>>> of configuration file?  We still need to match our guidelines here:
>>>
>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>
>>> We can achieve that with a config file for it, right?  (Maybe already
>>> existing, maybe in the lldb source tree already?)
>>>
>>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>>> wrote:
>>>
 With git you can already run "git clang-format".  You just need
 `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
 sure how to hook it into SVN

 On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
 eugene.zele...@gmail.com> wrote:

> At least clang-format should be applied to all newly added files
> before commit.
>
> Eugene.
>
> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
> wrote:
> > Back on the topic of clang-format, what would it take to make
> clang-format a
> > regular part of peoples' workflows?
> >
> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
> wrote:
> >>
> >> Yep - sorry.  I had been talking to Greg about this and
> misunderstood his
> >> comment on it. My mistake entirely.  Kate and I just talked and she
> pointed
> >> me to your document, Jim.
> >>
> >> The description was:
> >> where we had a clearly adhered to standard, keep it.
> >> whee we didn't, we adopted LLVM.
> >>
> >> Sorry for rehashing!
> >>
> >> -Todd
> >>
> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
> wrote:
> >>>
> >>>
> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
> >>>  wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
> ztur...@google.com>
> >>> wrote:
> 
>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>   wrote:
> >
> > Hey Eugene and Greg,
> >
> > I thought we were doing spaces before the open parens in places
> like
> > this:
> >
> > -BreakpointResolverSP resolver_sp(new
> BreakpointResolverFileLine
> > (NULL,
> > ...
> > +BreakpointResolverSP resolver_sp(new
> > BreakpointResolverFileLine(nullptr,
> >
> > (see the removal of the space after BreakpointResolverFileLine
> from the
> > clang-tidy settings I presume).
> >
> > Did I misunderstand that?
> 
> 
>  This was officially removed from the coding standard some months
> ago,
> >>>
> >>>
> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?
> If so I
> >>> can just look there to see what we're supposed to be doing.
> >>>
> >>>
> >>> No, the differences between the lldb and llvm coding standards are
> >>> documented in:
> >>>
> >>> http://lldb.llvm.org/lldb-coding-conventions.html
> >>>
> >>> Jim
> >>>
> >>>
> 
>  but not everyone has adopted this unfortunately.  See r228860.
> It pains
>  me to no end that we differ from LLVM, because it leads to
> exactly these
>  type of problems where people aren't sure what the exact set of
> rules are.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -Todd
> >>> ___
> >>> lldb-commits mailing list
> >>> lldb-commits@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> -Todd
>

>>>
>>>
>>> --
>>> -Todd
>>>
>>
>
>
> --
> -Todd
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail

[Lldb-commits] [lldb] r255385 - Use new set when checking if a test event type matches the job/test result types

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Fri Dec 11 16:45:52 2015
New Revision: 255385

URL: http://llvm.org/viewvc/llvm-project?rev=255385&view=rev
Log:
Use new set when checking if a test event type matches the job/test result types

Modified:
lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py?rev=255385&r1=255384&r2=255385&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/result_formatter.py Fri Dec 11 
16:45:52 2015
@@ -738,9 +738,7 @@ class ResultsFormatter(object):
 
 if event_type == "terminate":
 self.terminate_called = True
-elif event_type in [
-EventBuilder.TYPE_TEST_RESULT,
-EventBuilder.TYPE_JOB_RESULT]:
+elif event_type in EventBuilder.RESULT_TYPES:
 # Keep track of event counts per test/job result status type.
 # The only job (i.e. inferior process) results that make it
 # here are ones that cannot be remapped to the most recently


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

clang-tidy is a little more problematic, because the source for clang-tidy
isn't even in the same repository.  You literally have to clone an entirely
separate repo to get it, so it's not built by default.  This kind of raises
the barrier to entry for using clang-tidy IMO, which is unfortunate since
it's a pretty nice tool.

On Fri, Dec 11, 2015 at 2:46 PM Zachary Turner  wrote:

> No I'm not talking about whitespace at the end of a line, I'm saying
> LLVM's style (and what clang-format does) is this:
>
> Foo::Foo()
>: member_1()
>, member_2()
>, member_3()
>
> and what LLDB wants is this:
>
> Foo::Foo() :
> member1(),
> member2(),
> member3()
>
> Neither one have whitespace at the end of a line.
>
> On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala  wrote:
>
>> Okay.  Ending a line with arbitrary whitespace seems wrong as just about
>> any colorizing editor or diff will flag, but I'll survive :-)
>>
>> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
>> wrote:
>>
>>> Yes, but as I mentioned, two things are still unsupported due to
>>> limitations in clang-format.  They are return-type-on-new-line (only in
>>> declarations.  clang-format supports it for definitions) and the
>>> constructor initializer list comma at the end (clang-format puts it at the
>>> beginning).
>>>
>>> That said, the comma at the end of initializer list isn't documented on
>>> that page, and where we don't have a clearly documented rule, prefer the
>>> LLVM guidelines, so
>>>
>>>
>>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>>>
 Okay, but does the format match the LLDB-modified format with some kind
 of configuration file?  We still need to match our guidelines here:

 http://lldb.llvm.org/lldb-coding-conventions.html

 We can achieve that with a config file for it, right?  (Maybe already
 existing, maybe in the lldb source tree already?)

 On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
 wrote:

> With git you can already run "git clang-format".  You just need
> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
> sure how to hook it into SVN
>
> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
> eugene.zele...@gmail.com> wrote:
>
>> At least clang-format should be applied to all newly added files
>> before commit.
>>
>> Eugene.
>>
>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>> wrote:
>> > Back on the topic of clang-format, what would it take to make
>> clang-format a
>> > regular part of peoples' workflows?
>> >
>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>> wrote:
>> >>
>> >> Yep - sorry.  I had been talking to Greg about this and
>> misunderstood his
>> >> comment on it. My mistake entirely.  Kate and I just talked and
>> she pointed
>> >> me to your document, Jim.
>> >>
>> >> The description was:
>> >> where we had a clearly adhered to standard, keep it.
>> >> whee we didn't, we adopted LLVM.
>> >>
>> >> Sorry for rehashing!
>> >>
>> >> -Todd
>> >>
>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
>> wrote:
>> >>>
>> >>>
>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>> >>>  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
>> ztur...@google.com>
>> >>> wrote:
>> 
>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>   wrote:
>> >
>> > Hey Eugene and Greg,
>> >
>> > I thought we were doing spaces before the open parens in places
>> like
>> > this:
>> >
>> > -BreakpointResolverSP resolver_sp(new
>> BreakpointResolverFileLine
>> > (NULL,
>> > ...
>> > +BreakpointResolverSP resolver_sp(new
>> > BreakpointResolverFileLine(nullptr,
>> >
>> > (see the removal of the space after BreakpointResolverFileLine
>> from the
>> > clang-tidy settings I presume).
>> >
>> > Did I misunderstand that?
>> 
>> 
>>  This was officially removed from the coding standard some months
>> ago,
>> >>>
>> >>>
>> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?
>> If so I
>> >>> can just look there to see what we're supposed to be doing.
>> >>>
>> >>>
>> >>> No, the differences between the lldb and llvm coding standards are
>> >>> documented in:
>> >>>
>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>> >>>
>> >>> Jim
>> >>>
>> >>>
>> 
>>  but not everyone has adopted this unfortunately.  See r228860.
>> It pains
>>  me to no end that we differ from LLVM, because it leads to
>> exactly these
>>  type of problems where people aren't sure what the exact set of
>> rules are.
>>>

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

On Fri, Dec 11, 2015 at 2:46 PM, Zachary Turner  wrote:

> No I'm not talking about whitespace at the end of a line, I'm saying
> LLVM's style (and what clang-format does) is this:
>
> Foo::Foo()
>: member_1()
>, member_2()
>, member_3()
>
> and what LLDB wants is this:
>
> Foo::Foo() :
> member1(),
> member2(),
> member3()
>

Oh I see.


>
>
Neither one have whitespace at the end of a line.
>
> On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala  wrote:
>
>> Okay.  Ending a line with arbitrary whitespace seems wrong as just about
>> any colorizing editor or diff will flag, but I'll survive :-)
>>
>> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
>> wrote:
>>
>>> Yes, but as I mentioned, two things are still unsupported due to
>>> limitations in clang-format.  They are return-type-on-new-line (only in
>>> declarations.  clang-format supports it for definitions) and the
>>> constructor initializer list comma at the end (clang-format puts it at the
>>> beginning).
>>>
>>> That said, the comma at the end of initializer list isn't documented on
>>> that page, and where we don't have a clearly documented rule, prefer the
>>> LLVM guidelines, so
>>>
>>>
>>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>>>
 Okay, but does the format match the LLDB-modified format with some kind
 of configuration file?  We still need to match our guidelines here:

 http://lldb.llvm.org/lldb-coding-conventions.html

 We can achieve that with a config file for it, right?  (Maybe already
 existing, maybe in the lldb source tree already?)

 On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
 wrote:

> With git you can already run "git clang-format".  You just need
> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
> sure how to hook it into SVN
>
> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
> eugene.zele...@gmail.com> wrote:
>
>> At least clang-format should be applied to all newly added files
>> before commit.
>>
>> Eugene.
>>
>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>> wrote:
>> > Back on the topic of clang-format, what would it take to make
>> clang-format a
>> > regular part of peoples' workflows?
>> >
>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>> wrote:
>> >>
>> >> Yep - sorry.  I had been talking to Greg about this and
>> misunderstood his
>> >> comment on it. My mistake entirely.  Kate and I just talked and
>> she pointed
>> >> me to your document, Jim.
>> >>
>> >> The description was:
>> >> where we had a clearly adhered to standard, keep it.
>> >> whee we didn't, we adopted LLVM.
>> >>
>> >> Sorry for rehashing!
>> >>
>> >> -Todd
>> >>
>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
>> wrote:
>> >>>
>> >>>
>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>> >>>  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
>> ztur...@google.com>
>> >>> wrote:
>> 
>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>   wrote:
>> >
>> > Hey Eugene and Greg,
>> >
>> > I thought we were doing spaces before the open parens in places
>> like
>> > this:
>> >
>> > -BreakpointResolverSP resolver_sp(new
>> BreakpointResolverFileLine
>> > (NULL,
>> > ...
>> > +BreakpointResolverSP resolver_sp(new
>> > BreakpointResolverFileLine(nullptr,
>> >
>> > (see the removal of the space after BreakpointResolverFileLine
>> from the
>> > clang-tidy settings I presume).
>> >
>> > Did I misunderstand that?
>> 
>> 
>>  This was officially removed from the coding standard some months
>> ago,
>> >>>
>> >>>
>> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?
>> If so I
>> >>> can just look there to see what we're supposed to be doing.
>> >>>
>> >>>
>> >>> No, the differences between the lldb and llvm coding standards are
>> >>> documented in:
>> >>>
>> >>> http://lldb.llvm.org/lldb-coding-conventions.html
>> >>>
>> >>> Jim
>> >>>
>> >>>
>> 
>>  but not everyone has adopted this unfortunately.  See r228860.
>> It pains
>>  me to no end that we differ from LLVM, because it leads to
>> exactly these
>>  type of problems where people aren't sure what the exact set of
>> rules are.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> -Todd
>> >>> ___
>> >>> lldb-commits mailing list
>> >>> lldb-commits@lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> >>>
>> >>>
>> >>
>

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

What if we embedded a version?  Made whatever modifications we needed, and
just merged occasionally from the source?  That would lower the barrier, at
the cost of raising the need to refresh occasionally.  But then you could
count on it being there.

Seems like a lot of work, though.  A simple alternative is to learn the
coding standard.

On Fri, Dec 11, 2015 at 2:49 PM, Zachary Turner  wrote:

> clang-tidy is a little more problematic, because the source for clang-tidy
> isn't even in the same repository.  You literally have to clone an entirely
> separate repo to get it, so it's not built by default.  This kind of raises
> the barrier to entry for using clang-tidy IMO, which is unfortunate since
> it's a pretty nice tool.
>
> On Fri, Dec 11, 2015 at 2:46 PM Zachary Turner  wrote:
>
>> No I'm not talking about whitespace at the end of a line, I'm saying
>> LLVM's style (and what clang-format does) is this:
>>
>> Foo::Foo()
>>: member_1()
>>, member_2()
>>, member_3()
>>
>> and what LLDB wants is this:
>>
>> Foo::Foo() :
>> member1(),
>> member2(),
>> member3()
>>
>> Neither one have whitespace at the end of a line.
>>
>> On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala  wrote:
>>
>>> Okay.  Ending a line with arbitrary whitespace seems wrong as just about
>>> any colorizing editor or diff will flag, but I'll survive :-)
>>>
>>> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
>>> wrote:
>>>
 Yes, but as I mentioned, two things are still unsupported due to
 limitations in clang-format.  They are return-type-on-new-line (only in
 declarations.  clang-format supports it for definitions) and the
 constructor initializer list comma at the end (clang-format puts it at the
 beginning).

 That said, the comma at the end of initializer list isn't documented on
 that page, and where we don't have a clearly documented rule, prefer the
 LLVM guidelines, so


 On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala 
 wrote:

> Okay, but does the format match the LLDB-modified format with some
> kind of configuration file?  We still need to match our guidelines here:
>
> http://lldb.llvm.org/lldb-coding-conventions.html
>
> We can achieve that with a config file for it, right?  (Maybe already
> existing, maybe in the lldb source tree already?)
>
> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
> wrote:
>
>> With git you can already run "git clang-format".  You just need
>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>> sure how to hook it into SVN
>>
>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
>> eugene.zele...@gmail.com> wrote:
>>
>>> At least clang-format should be applied to all newly added files
>>> before commit.
>>>
>>> Eugene.
>>>
>>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
>>> wrote:
>>> > Back on the topic of clang-format, what would it take to make
>>> clang-format a
>>> > regular part of peoples' workflows?
>>> >
>>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
>>> wrote:
>>> >>
>>> >> Yep - sorry.  I had been talking to Greg about this and
>>> misunderstood his
>>> >> comment on it. My mistake entirely.  Kate and I just talked and
>>> she pointed
>>> >> me to your document, Jim.
>>> >>
>>> >> The description was:
>>> >> where we had a clearly adhered to standard, keep it.
>>> >> whee we didn't, we adopted LLVM.
>>> >>
>>> >> Sorry for rehashing!
>>> >>
>>> >> -Todd
>>> >>
>>> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
>>> wrote:
>>> >>>
>>> >>>
>>> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
>>> >>>  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
>>> ztur...@google.com>
>>> >>> wrote:
>>> 
>>>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>>>   wrote:
>>> >
>>> > Hey Eugene and Greg,
>>> >
>>> > I thought we were doing spaces before the open parens in
>>> places like
>>> > this:
>>> >
>>> > -BreakpointResolverSP resolver_sp(new
>>> BreakpointResolverFileLine
>>> > (NULL,
>>> > ...
>>> > +BreakpointResolverSP resolver_sp(new
>>> > BreakpointResolverFileLine(nullptr,
>>> >
>>> > (see the removal of the space after BreakpointResolverFileLine
>>> from the
>>> > clang-tidy settings I presume).
>>> >
>>> > Did I misunderstand that?
>>> 
>>> 
>>>  This was officially removed from the coding standard some
>>> months ago,
>>> >>>
>>> >>>
>>> >>> Okay.  Are we 100% in sync with LLVM coding standard
>>> guidelines?  If so I
>>> >>> can just look there to see what we're supposed to be 

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

Well clang-tidy doesn't help with the coding standard anyway.  It's more
semantic style rather than syntax style.  nullptr instead of NULL, Foo() =
delete instead of making a constructor private.  That type of thing.

I'm happy letting clang-tidy be postprocessing steps that peopel
occasionally run over the code, as I think clang-format has a lot more
value, at least in the short term.

On Fri, Dec 11, 2015 at 2:53 PM Todd Fiala  wrote:

> What if we embedded a version?  Made whatever modifications we needed, and
> just merged occasionally from the source?  That would lower the barrier, at
> the cost of raising the need to refresh occasionally.  But then you could
> count on it being there.
>
> Seems like a lot of work, though.  A simple alternative is to learn the
> coding standard.
>
> On Fri, Dec 11, 2015 at 2:49 PM, Zachary Turner 
> wrote:
>
>> clang-tidy is a little more problematic, because the source for
>> clang-tidy isn't even in the same repository.  You literally have to clone
>> an entirely separate repo to get it, so it's not built by default.  This
>> kind of raises the barrier to entry for using clang-tidy IMO, which is
>> unfortunate since it's a pretty nice tool.
>>
>> On Fri, Dec 11, 2015 at 2:46 PM Zachary Turner 
>> wrote:
>>
>>> No I'm not talking about whitespace at the end of a line, I'm saying
>>> LLVM's style (and what clang-format does) is this:
>>>
>>> Foo::Foo()
>>>: member_1()
>>>, member_2()
>>>, member_3()
>>>
>>> and what LLDB wants is this:
>>>
>>> Foo::Foo() :
>>> member1(),
>>> member2(),
>>> member3()
>>>
>>> Neither one have whitespace at the end of a line.
>>>
>>> On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala  wrote:
>>>
 Okay.  Ending a line with arbitrary whitespace seems wrong as just
 about any colorizing editor or diff will flag, but I'll survive :-)

 On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
 wrote:

> Yes, but as I mentioned, two things are still unsupported due to
> limitations in clang-format.  They are return-type-on-new-line (only in
> declarations.  clang-format supports it for definitions) and the
> constructor initializer list comma at the end (clang-format puts it at the
> beginning).
>
> That said, the comma at the end of initializer list isn't documented
> on that page, and where we don't have a clearly documented rule, prefer 
> the
> LLVM guidelines, so
>
>
> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala 
> wrote:
>
>> Okay, but does the format match the LLDB-modified format with some
>> kind of configuration file?  We still need to match our guidelines here:
>>
>> http://lldb.llvm.org/lldb-coding-conventions.html
>>
>> We can achieve that with a config file for it, right?  (Maybe already
>> existing, maybe in the lldb source tree already?)
>>
>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>> wrote:
>>
>>> With git you can already run "git clang-format".  You just need
>>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  
>>> Not
>>> sure how to hook it into SVN
>>>
>>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
>>> eugene.zele...@gmail.com> wrote:
>>>
 At least clang-format should be applied to all newly added files
 before commit.

 Eugene.

 On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
 wrote:
 > Back on the topic of clang-format, what would it take to make
 clang-format a
 > regular part of peoples' workflows?
 >
 > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
 wrote:
 >>
 >> Yep - sorry.  I had been talking to Greg about this and
 misunderstood his
 >> comment on it. My mistake entirely.  Kate and I just talked and
 she pointed
 >> me to your document, Jim.
 >>
 >> The description was:
 >> where we had a clearly adhered to standard, keep it.
 >> whee we didn't, we adopted LLVM.
 >>
 >> Sorry for rehashing!
 >>
 >> -Todd
 >>
 >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
 wrote:
 >>>
 >>>
 >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
 >>>  wrote:
 >>>
 >>>
 >>>
 >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
 ztur...@google.com>
 >>> wrote:
 
  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
   wrote:
 >
 > Hey Eugene and Greg,
 >
 > I thought we were doing spaces before the open parens in
 places like
 > this:
 >
 > -BreakpointResolverSP resolver_sp(new
 BreakpointResolverFileLine
 > (NULL,
 > ...
 > 

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Todd Fiala via lldb-commits]

Er, I was twisting them together.  I've been meaning clang-format.

On Fri, Dec 11, 2015 at 2:56 PM, Zachary Turner  wrote:

> Well clang-tidy doesn't help with the coding standard anyway.  It's more
> semantic style rather than syntax style.  nullptr instead of NULL, Foo() =
> delete instead of making a constructor private.  That type of thing.
>
> I'm happy letting clang-tidy be postprocessing steps that peopel
> occasionally run over the code, as I think clang-format has a lot more
> value, at least in the short term.
>
> On Fri, Dec 11, 2015 at 2:53 PM Todd Fiala  wrote:
>
>> What if we embedded a version?  Made whatever modifications we needed,
>> and just merged occasionally from the source?  That would lower the
>> barrier, at the cost of raising the need to refresh occasionally.  But then
>> you could count on it being there.
>>
>> Seems like a lot of work, though.  A simple alternative is to learn the
>> coding standard.
>>
>> On Fri, Dec 11, 2015 at 2:49 PM, Zachary Turner 
>> wrote:
>>
>>> clang-tidy is a little more problematic, because the source for
>>> clang-tidy isn't even in the same repository.  You literally have to clone
>>> an entirely separate repo to get it, so it's not built by default.  This
>>> kind of raises the barrier to entry for using clang-tidy IMO, which is
>>> unfortunate since it's a pretty nice tool.
>>>
>>> On Fri, Dec 11, 2015 at 2:46 PM Zachary Turner 
>>> wrote:
>>>
 No I'm not talking about whitespace at the end of a line, I'm saying
 LLVM's style (and what clang-format does) is this:

 Foo::Foo()
: member_1()
, member_2()
, member_3()

 and what LLDB wants is this:

 Foo::Foo() :
 member1(),
 member2(),
 member3()

 Neither one have whitespace at the end of a line.

 On Fri, Dec 11, 2015 at 2:44 PM Todd Fiala 
 wrote:

> Okay.  Ending a line with arbitrary whitespace seems wrong as just
> about any colorizing editor or diff will flag, but I'll survive :-)
>
> On Fri, Dec 11, 2015 at 2:42 PM, Zachary Turner 
> wrote:
>
>> Yes, but as I mentioned, two things are still unsupported due to
>> limitations in clang-format.  They are return-type-on-new-line (only in
>> declarations.  clang-format supports it for definitions) and the
>> constructor initializer list comma at the end (clang-format puts it at 
>> the
>> beginning).
>>
>> That said, the comma at the end of initializer list isn't documented
>> on that page, and where we don't have a clearly documented rule, prefer 
>> the
>> LLVM guidelines, so
>>
>>
>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala 
>> wrote:
>>
>>> Okay, but does the format match the LLDB-modified format with some
>>> kind of configuration file?  We still need to match our guidelines here:
>>>
>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>
>>> We can achieve that with a config file for it, right?  (Maybe
>>> already existing, maybe in the lldb source tree already?)
>>>
>>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>>> wrote:
>>>
 With git you can already run "git clang-format".  You just need
 `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  
 Not
 sure how to hook it into SVN

 On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
 eugene.zele...@gmail.com> wrote:

> At least clang-format should be applied to all newly added files
> before commit.
>
> Eugene.
>
> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner <
> ztur...@google.com> wrote:
> > Back on the topic of clang-format, what would it take to make
> clang-format a
> > regular part of peoples' workflows?
> >
> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
> wrote:
> >>
> >> Yep - sorry.  I had been talking to Greg about this and
> misunderstood his
> >> comment on it. My mistake entirely.  Kate and I just talked and
> she pointed
> >> me to your document, Jim.
> >>
> >> The description was:
> >> where we had a clearly adhered to standard, keep it.
> >> whee we didn't, we adopted LLVM.
> >>
> >> Sorry for rehashing!
> >>
> >> -Todd
> >>
> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
> wrote:
> >>>
> >>>
> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
> >>>  wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner <
> ztur...@google.com>
> >>> wrote:
> 
>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>   wrote:
> >
> > Hey Eugene and

Re: [Lldb-commits] [PATCH] D15407: When stepping in/over source lines, combine the addr ranges of all line table entries w/ same line num

[Jason Molenda via lldb-commits]

jasonmolenda added a comment.

Thanks Jim, I'll fix those issues.

With line 0's, I think there are three scenarios of interest (none of this 
contradicts what you wrote, I'm just spelling it out for myself):

1 We are stepping over a source line and we find a line 0.  We want to include 
that line 0.  If that same source line # appears after line 0, continue to 
extend our stepping range.

2 We are somehow starting on a line 0 (which lldb will try to avoid - but an 
asynchronous interrupt may have put us here).  I think the debugger will show 
the first non-zero line number as the "currently executing" source line in this 
case.  So a 'next' should consume the line 0 that we're on, plus the next 
source line that we encounter.

3 We're stepping a source line "n", we branch over a different source line and 
find ourselves in a line 0.  In this case we want to consume the 0, and if we 
find the next non-zero line number is "n", continue to expand the range.  If 
it's non-"n", then we need to stop expanding the range.

#2 and #3 are trickily similar; I implemented #2 (if we start with a line 0, 
adopt the first non-zero line num we encounter) in this patch.  #3 won't 
actually happen because ThreadPlanStepRange::InRange() (which handles the case 
where we've finished stepping through a range of addresses and we look at the 
new pc to see if it is still a part of the same line -- so realistically, when 
we've branched over another source line now that we extend line ranges) treats 
"the new pc is the same line number as the original line number" and "the new 
pc is line number 0" separately - and if the new pc is line 0, it replaces the 
line number with the original line number.  (this isn't a change by me - that 
was the existing code behavior)

It's a subtle behavior and that's probably not good to rely on it happening to 
be written correctly - I almost tried to combine the "line 0" and "non-line 0" 
sections of ThreadPlanStepRange::InRange when  I was writing the patch and it 
took me a minute to think through the implications of doing that.


Repository:
  rL LLVM

http://reviews.llvm.org/D15407



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Greg Clayton via lldb-commits]

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

Can we change DebugMacroEntry to contain a std::unique_ptr instead 
of a shared pointer? This would save us one full pointer in each 
DebugMacroEntry.

That is the only change I would like to see.

The expand on the benefit of having two structs like DebugMacroEntryStorage 
would be you can store it very efficiently with bitfields and store the macros 
inside DebugMacro as a vector of DebugMacroEntryStorage structs. But the API 
from DebugMacro could that gets an entry at index could return the bigger 
fatter version of this. The two structs below would be an example:

We store macro entries inside DebugMacro as:

  class DebugMacroEntryStorage
  {
  EntryType m_type:3;
  uint32_t m_line:29;
  uint32_t m_file;
  ConstString m_str;
  DebugMacrosSP m_debug_macros_sp;
  };

But the function:

  DebugMacroEntry
  GetMacroEntryAtIndex(const size_t index) const

would return something like:

  class DebugMacroEntryStorage
  {
  CompileUnit *m_comp_unit;
  EntryType m_type;
  uint32_t m_line;
  FileSpec m_file;
  ConstString m_str;
  DebugMacrosSP m_debug_macros_sp;
  };

We would resolve the "m_file" into a FileSpec for public consumption by getting 
the correct file from the compile unit's support files FileSpecList and not 
compress the storage and also fill in the m_comp_unit if needed.

This doesn't need to be done, but this is what I was thinking. I did this in 
LineTable.h where I store line entries as a lldb_private::LineTable::Entry 
objects, but I hand them out to clients as lldb_private::LineEntry objects.


http://reviews.llvm.org/D15437



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Greg Clayton via lldb-commits]

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

In http://reviews.llvm.org/D15437#308839, @clayborg wrote:

> Can we change DebugMacroEntry to contain a std::unique_ptr 
> instead of a shared pointer? This would save us one full pointer in each 
> DebugMacroEntry.
>
> That is the only change I would like to see.


Actually never mind. I believe the whole reason this shared pointer is here it 
to share the object between multiple other objects...


http://reviews.llvm.org/D15437



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Greg Clayton via lldb-commits]

clayborg added a comment.

One area of concern is if you are not tracking file, how can you get the right 
defines for a given source file line? If you have:

main.c:

  #include 
  #define FOO printf
  
  int main ()
  {
  return 0; // Stop here and run: FOO("hello world\n")
  }
  
  #undef FOO

But in foo.h you have:
#define FOO puts

// nothing
// nothing
// nothing
// nothing

#undef FOO

  Do you currently correctly have the following in your macros if stopped at 
the return statement in main?

#define FOO puts<<< from foo.h
#undef FOO <<< from foo.h
#define FOO print <<< from main.c

  Both foo definitions will be on line 1, and we will be stopped on line 5 of 
main.c, but if we don't know that the entries from foo.h come from foo.h we 
might accidentally include these statements?


http://reviews.llvm.org/D15437



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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Siva Chandra via lldb-commits]

sivachandra added a comment.

The spec says that, for a given compile unit, the macro entries in the debug 
info will be in the order in which the compiler processes them. Hence, at line 
5 in your example, all these are relevant:

  #define FOO puts <<< from foo.h
  #undef FOO <<< from foo.h
  #define FOO print <<< from main.c

I have actually verified that it works as expected; FOO resolves to printf and 
not puts at line 5.

You have tickled one aspect that I have ignored though. What if one is stopped 
in an inlined function/method defined in an included file? I think taking care 
of this is a fairly straightforward change over what I now have. I will need to 
bring back the line index in DebugMacroEntry and use it. Will send an update 
soon.


http://reviews.llvm.org/D15437



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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Jim Ingham via lldb-commits]

> On Dec 11, 2015, at 2:42 PM, Zachary Turner  wrote:
> 
> Yes, but as I mentioned, two things are still unsupported due to limitations 
> in clang-format.  They are return-type-on-new-line (only in declarations.  
> clang-format supports it for definitions) and the constructor initializer 
> list comma at the end (clang-format puts it at the beginning).  
> 
> That said, the comma at the end of initializer list isn't documented on that 
> page, and where we don't have a clearly documented rule, prefer the LLVM 
> guidelines, so….

That clang-format behavior seems weird to me, a quick scan through clang 
sources have the commas always at the end:

  LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
LabelStmt *S, SourceLocation StartL)
: NamedDecl(Label, DC, IdentL, II),
  TheStmt(S),
  MSAsmNameResolved(false),
  LocStart(StartL) {}

etc.  I can’t remember seeing code in clang that does:

  LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
LabelStmt *S, SourceLocation StartL)
: NamedDecl(Label, DC, IdentL, II)
, TheStmt(S)
, MSAsmNameResolved(false)
, LocStart(StartL) {}

That looks really weird, since you have to look past the noise of those commas 
to see what you really care about.  

We do differ in that we tend to write this:

  LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
LabelStmt *S, SourceLocation StartL) :
  NamedDecl(Label, DC, IdentL, II),
  TheStmt(S),
  MSAsmNameResolved(false),
  LocStart(StartL) {}

with the colon at the end of the argument list.  I don’t think any of this 
behavior is prescribed one way or the other in the actual coding conventions…  
Maybe there’s a bug in clang-format that if you put the : in the unexpected 
place the commas get moved to the wrong place as well?  But the llvm coding 
conventions make no prescription about this at all. I don’t think our code 
layout should be based on clang format bugs and all. We certainly shouldn’t do 
wholesale reformats that just make history harder to read for that reason.

Jim


> 
> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  > wrote:
> Okay, but does the format match the LLDB-modified format with some kind of 
> configuration file?  We still need to match our guidelines here:
> 
> http://lldb.llvm.org/lldb-coding-conventions.html 
> 
> 
> We can achieve that with a config file for it, right?  (Maybe already 
> existing, maybe in the lldb source tree already?)
> 
> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner  > wrote:
> With git you can already run "git clang-format".  You just need 
> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not 
> sure how to hook it into SVN
> 
> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko  > wrote:
> At least clang-format should be applied to all newly added files before 
> commit.
> 
> Eugene.
> 
> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner  > wrote:
> > Back on the topic of clang-format, what would it take to make clang-format a
> > regular part of peoples' workflows?
> >
> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala  > > wrote:
> >>
> >> Yep - sorry.  I had been talking to Greg about this and misunderstood his
> >> comment on it. My mistake entirely.  Kate and I just talked and she pointed
> >> me to your document, Jim.
> >>
> >> The description was:
> >> where we had a clearly adhered to standard, keep it.
> >> whee we didn't, we adopted LLVM.
> >>
> >> Sorry for rehashing!
> >>
> >> -Todd
> >>
> >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham  >> > wrote:
> >>>
> >>>
> >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
> >>> mailto:lldb-commits@lists.llvm.org>> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner  >>> >
> >>> wrote:
> 
>  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
>  mailto:lldb-commits@lists.llvm.org>> wrote:
> >
> > Hey Eugene and Greg,
> >
> > I thought we were doing spaces before the open parens in places like
> > this:
> >
> > -BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine
> > (NULL,
> > ...
> > +BreakpointResolverSP resolver_sp(new
> > BreakpointResolverFileLine(nullptr,
> >
> > (see the removal of the space after BreakpointResolverFileLine from the
> > clang-tidy settings I presume).
> >
> > Did I misunderstand that?
> 
> 
>  This was officially removed from the coding standard some months ago,
> >>>
> >>>
> >>> Okay.  Are we 100% in sync with LLVM coding standard guidelines?  If so I
> >>> can just look there to see what we're supposed to be doing.
> >>>
> >>>
> >>> No, the differences 

[Lldb-commits] [lldb] r255400 - Decouple test execution and test finder logic in parallel test runner.

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Fri Dec 11 18:34:57 2015
New Revision: 255400

URL: http://llvm.org/viewvc/llvm-project?rev=255400&view=rev
Log:
Decouple test execution and test finder logic in parallel test runner.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/dosep.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/dosep.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/dosep.py?rev=255400&r1=255399&r2=255400&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/dosep.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/dosep.py Fri Dec 11 18:34:57 2015
@@ -1067,16 +1067,16 @@ def inprocess_exec_test_runner(test_work
 
 return test_results
 
-def walk_and_invoke(test_directory, test_subdir, dotest_argv,
-num_workers, test_runner_func):
-"""Look for matched files and invoke test driver on each one.
-In single-threaded mode, each test driver is invoked directly.
-In multi-threaded mode, submit each test driver to a worker
-queue, and then wait for all to complete.
-
-test_directory - lldb/test/ directory
-test_subdir - lldb/test/ or a subfolder with the tests we're interested in
-  running
+def walk_and_invoke(test_files, dotest_argv, num_workers, test_runner_func):
+"""Invokes the test runner on each test file specified by test_files.
+
+@param test_files a list of (test_subdir, list_of_test_files_in_dir)
+@param num_workers the number of worker queues working on these test files
+@param test_runner_func the test runner configured to run the tests
+
+@return a tuple of results from the running of the specified tests,
+of the form (timed_out, passed, failed, unexpected_successes, pass_count,
+fail_count)
 """
 # The async_map is important to keep all thread-related asyncore
 # channels distinct when we call asyncore.loop() later on.
@@ -1095,11 +1095,10 @@ def walk_and_invoke(test_directory, test
 dotest_argv.append("--results-port")
 dotest_argv.append(str(RESULTS_LISTENER_CHANNEL.address[1]))
 
-# Collect the test files that we'll run.
+# Build the test work items out of the (dir, file_list) entries passed in.
 test_work_items = []
-find_test_files_in_dir_tree(
-test_subdir, lambda testdir, test_files: test_work_items.append([
-test_subdir, test_files, dotest_argv, None]))
+for entry in test_files:
+test_work_items.append((entry[0], entry[1], dotest_argv, None))
 
 # Convert test work items into test results using whatever
 # was provided as the test run function.
@@ -1497,9 +1496,16 @@ def main(num_threads, test_subdir, test_
 list(runner_strategies_by_name.keys(
 test_runner_func = runner_strategies_by_name[test_runner_name]
 
+test_files = []
+find_test_files_in_dir_tree(
+test_subdir, lambda tdir, tfiles: test_files.append(
+(test_subdir, tfiles)))
+
 summary_results = walk_and_invoke(
-test_directory, test_subdir, dotest_argv,
-num_threads, test_runner_func)
+test_files,
+dotest_argv,
+num_threads,
+test_runner_func)
 
 (timed_out, passed, failed, unexpected_successes, pass_count,
  fail_count) = summary_results


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

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

Hrmm, that's interesting.  I guess I was mistaken in LLVM's rules then.
Are we willing to accept this format in LLDB?

LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
LabelStmt *S, SourceLocation StartL)
: NamedDecl(Label, DC, IdentL, II),
  TheStmt(S),
  MSAsmNameResolved(false),
  LocStart(StartL) {}

If so that's less work I have to do on clang-format to get it up to spec.

On Fri, Dec 11, 2015 at 4:34 PM Jim Ingham  wrote:

> On Dec 11, 2015, at 2:42 PM, Zachary Turner  wrote:
>
> Yes, but as I mentioned, two things are still unsupported due to
> limitations in clang-format.  They are return-type-on-new-line (only in
> declarations.  clang-format supports it for definitions) and the
> constructor initializer list comma at the end (clang-format puts it at the
> beginning).
>
> That said, the comma at the end of initializer list isn't documented on
> that page, and where we don't have a clearly documented rule, prefer the
> LLVM guidelines, so….
>
>
> That clang-format behavior seems weird to me, a quick scan through clang
> sources have the commas always at the end:
>
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
>
> etc.  I can’t remember seeing code in clang that does:
>
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II)
> , TheStmt(S)
> , MSAsmNameResolved(false)
> , LocStart(StartL) {}
>
> That looks really weird, since you have to look past the noise of those
> commas to see what you really care about.
>
> We do differ in that we tend to write this:
>
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL) :
>   NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
>
> with the colon at the end of the argument list.  I don’t think any of this
> behavior is prescribed one way or the other in the actual coding
> conventions…  Maybe there’s a bug in clang-format that if you put the : in
> the unexpected place the commas get moved to the wrong place as well?  But
> the llvm coding conventions make no prescription about this at all. I don’t
> think our code layout should be based on clang format bugs and all. We
> certainly shouldn’t do wholesale reformats that just make history harder to
> read for that reason.
>
> Jim
>
>
>
> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>
>> Okay, but does the format match the LLDB-modified format with some kind
>> of configuration file?  We still need to match our guidelines here:
>>
>> http://lldb.llvm.org/lldb-coding-conventions.html
>>
>> We can achieve that with a config file for it, right?  (Maybe already
>> existing, maybe in the lldb source tree already?)
>>
>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>> wrote:
>>
>>> With git you can already run "git clang-format".  You just need
>>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
>>> sure how to hook it into SVN
>>>
>>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko 
>>> wrote:
>>>
 At least clang-format should be applied to all newly added files before
 commit.

 Eugene.

 On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
 wrote:
 > Back on the topic of clang-format, what would it take to make
 clang-format a
 > regular part of peoples' workflows?
 >
 > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala 
 wrote:
 >>
 >> Yep - sorry.  I had been talking to Greg about this and
 misunderstood his
 >> comment on it. My mistake entirely.  Kate and I just talked and she
 pointed
 >> me to your document, Jim.
 >>
 >> The description was:
 >> where we had a clearly adhered to standard, keep it.
 >> whee we didn't, we adopted LLVM.
 >>
 >> Sorry for rehashing!
 >>
 >> -Todd
 >>
 >> On Fri, Dec 11, 2015 at 2:12 PM, Jim Ingham 
 wrote:
 >>>
 >>>
 >>> On Dec 11, 2015, at 2:01 PM, Todd Fiala via lldb-commits
 >>>  wrote:
 >>>
 >>>
 >>>
 >>> On Fri, Dec 11, 2015 at 1:59 PM, Zachary Turner >>> >
 >>> wrote:
 
  On Fri, Dec 11, 2015 at 1:55 PM Todd Fiala via lldb-commits
   wrote:
 >
 > Hey Eugene and Greg,
 >
 > I thought we were doing spaces before the open parens in places
 like
 > this:
 >
 > -BreakpointResolverSP resolver_sp(new
 BreakpointResolverFileLine
 > (NULL,
 > ...
 > +BreakpointResolverSP resolver_sp(new
 > BreakpointResolverFileLine(nullptr,
 >
 > (see the removal of the space a

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Jim Ingham via lldb-commits]

Note, it is pure speculation that this is a bug in clang-format based on where 
the : is placed.

I prefer the way we write it, because it places all the initializers on the 
same level, though I don’t feel so strongly about this one.

I would really rather not go through making wholesale changes like this unless 
there’s some compelling reason as it makes the history harder to trace by 
inserting random inessential checkins that you have to peer through.  And this 
seems like make-work to me.

Jim


> On Dec 11, 2015, at 4:40 PM, Zachary Turner  wrote:
> 
> Hrmm, that's interesting.  I guess I was mistaken in LLVM's rules then.  Are 
> we willing to accept this format in LLDB?
> 
> LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
> 
> If so that's less work I have to do on clang-format to get it up to spec.
> 
> On Fri, Dec 11, 2015 at 4:34 PM Jim Ingham  > wrote:
>> On Dec 11, 2015, at 2:42 PM, Zachary Turner > > wrote:
>> 
>> Yes, but as I mentioned, two things are still unsupported due to limitations 
>> in clang-format.  They are return-type-on-new-line (only in declarations.  
>> clang-format supports it for definitions) and the constructor initializer 
>> list comma at the end (clang-format puts it at the beginning).  
>> 
> 
>> That said, the comma at the end of initializer list isn't documented on that 
>> page, and where we don't have a clearly documented rule, prefer the LLVM 
>> guidelines, so….
> 
> That clang-format behavior seems weird to me, a quick scan through clang 
> sources have the commas always at the end:
> 
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
> 
> etc.  I can’t remember seeing code in clang that does:
> 
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II)
> , TheStmt(S)
> , MSAsmNameResolved(false)
> , LocStart(StartL) {}
> 
> That looks really weird, since you have to look past the noise of those 
> commas to see what you really care about.  
> 
> We do differ in that we tend to write this:
> 
>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL) :
>   NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
> 
> with the colon at the end of the argument list.  I don’t think any of this 
> behavior is prescribed one way or the other in the actual coding conventions… 
>  Maybe there’s a bug in clang-format that if you put the : in the unexpected 
> place the commas get moved to the wrong place as well?  But the llvm coding 
> conventions make no prescription about this at all. I don’t think our code 
> layout should be based on clang format bugs and all. We certainly shouldn’t 
> do wholesale reformats that just make history harder to read for that reason.
> 
> Jim
> 
> 
>> 
>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala > > wrote:
>> Okay, but does the format match the LLDB-modified format with some kind of 
>> configuration file?  We still need to match our guidelines here:
>> 
>> http://lldb.llvm.org/lldb-coding-conventions.html 
>> 
>> 
>> We can achieve that with a config file for it, right?  (Maybe already 
>> existing, maybe in the lldb source tree already?)
>> 
>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner > > wrote:
>> With git you can already run "git clang-format".  You just need 
>> `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not 
>> sure how to hook it into SVN
>> 
>> On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko > > wrote:
>> At least clang-format should be applied to all newly added files before 
>> commit.
>> 
>> Eugene.
>> 
>> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner > > wrote:
>> > Back on the topic of clang-format, what would it take to make clang-format 
>> > a
>> > regular part of peoples' workflows?
>> >
>> > On Fri, Dec 11, 2015 at 2:27 PM Todd Fiala > > > wrote:
>> >>
>> >> Yep - sorry.  I had been talking to Greg about this and misunderstood his
>> >> comment on it. My mistake entirely.  Kate and I just talked and she 
>> >> pointed
>> >> me to your document, Jim.
>> >>
>> >> The description was:
>> >> where we had a clearly adhered to standard, keep it.
>> >> whee we didn't, we adopted LLVM.
>> >>
>> >> Sorry for rehas

Re: [Lldb-commits] [lldb] r255364 - Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in source/Target/Target.cpp.

[Zachary Turner via lldb-commits]

Agree, no change in coding standard should or would ever be accompanied by
a wholesale change.  It's more just agreeing on what clang-format can
automatically do for us, and then everyone using clang-format.  Note that
if you use the git clang-format extension (or an equivalent svn one if one
exists) it only formats the lines in your diff, not the full content of
each file you touch.  So this is o nly ever happening to lines that were
dirty anyway as a result of your CL

On Fri, Dec 11, 2015 at 4:50 PM Jim Ingham  wrote:

> Note, it is pure speculation that this is a bug in clang-format based on
> where the : is placed.
>
> I prefer the way we write it, because it places all the initializers on
> the same level, though I don’t feel so strongly about this one.
>
> I would really rather not go through making wholesale changes like this
> unless there’s some compelling reason as it makes the history harder to
> trace by inserting random inessential checkins that you have to peer
> through.  And this seems like make-work to me.
>
> Jim
>
>
>
> On Dec 11, 2015, at 4:40 PM, Zachary Turner  wrote:
>
> Hrmm, that's interesting.  I guess I was mistaken in LLVM's rules then.
> Are we willing to accept this format in LLDB?
>
> LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
> LabelStmt *S, SourceLocation StartL)
> : NamedDecl(Label, DC, IdentL, II),
>   TheStmt(S),
>   MSAsmNameResolved(false),
>   LocStart(StartL) {}
>
> If so that's less work I have to do on clang-format to get it up to spec.
>
> On Fri, Dec 11, 2015 at 4:34 PM Jim Ingham  wrote:
>
>> On Dec 11, 2015, at 2:42 PM, Zachary Turner  wrote:
>>
>> Yes, but as I mentioned, two things are still unsupported due to
>> limitations in clang-format.  They are return-type-on-new-line (only in
>> declarations.  clang-format supports it for definitions) and the
>> constructor initializer list comma at the end (clang-format puts it at the
>> beginning).
>>
>> That said, the comma at the end of initializer list isn't documented on
>> that page, and where we don't have a clearly documented rule, prefer the
>> LLVM guidelines, so….
>>
>>
>> That clang-format behavior seems weird to me, a quick scan through clang
>> sources have the commas always at the end:
>>
>>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
>> LabelStmt *S, SourceLocation StartL)
>> : NamedDecl(Label, DC, IdentL, II),
>>   TheStmt(S),
>>   MSAsmNameResolved(false),
>>   LocStart(StartL) {}
>>
>> etc.  I can’t remember seeing code in clang that does:
>>
>>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
>> LabelStmt *S, SourceLocation StartL)
>> : NamedDecl(Label, DC, IdentL, II)
>> , TheStmt(S)
>> , MSAsmNameResolved(false)
>> , LocStart(StartL) {}
>>
>> That looks really weird, since you have to look past the noise of those
>> commas to see what you really care about.
>>
>> We do differ in that we tend to write this:
>>
>>   LabelDecl(DeclContext *DC, SourceLocation IdentL, IdentifierInfo *II,
>> LabelStmt *S, SourceLocation StartL) :
>>   NamedDecl(Label, DC, IdentL, II),
>>   TheStmt(S),
>>   MSAsmNameResolved(false),
>>   LocStart(StartL) {}
>>
>> with the colon at the end of the argument list.  I don’t think any of
>> this behavior is prescribed one way or the other in the actual coding
>> conventions…  Maybe there’s a bug in clang-format that if you put the : in
>> the unexpected place the commas get moved to the wrong place as well?  But
>> the llvm coding conventions make no prescription about this at all. I don’t
>> think our code layout should be based on clang format bugs and all. We
>> certainly shouldn’t do wholesale reformats that just make history harder to
>> read for that reason.
>>
>> Jim
>>
>>
>>
>> On Fri, Dec 11, 2015 at 2:37 PM Todd Fiala  wrote:
>>
>>> Okay, but does the format match the LLDB-modified format with some kind
>>> of configuration file?  We still need to match our guidelines here:
>>>
>>> http://lldb.llvm.org/lldb-coding-conventions.html
>>>
>>> We can achieve that with a config file for it, right?  (Maybe already
>>> existing, maybe in the lldb source tree already?)
>>>
>>> On Fri, Dec 11, 2015 at 2:35 PM, Zachary Turner 
>>> wrote:
>>>
 With git you can already run "git clang-format".  You just need
 `git-clang-format` to be in your PATH (it's under llvm/tools/clang).  Not
 sure how to hook it into SVN

 On Fri, Dec 11, 2015 at 2:32 PM Eugene Zelenko <
 eugene.zele...@gmail.com> wrote:

> At least clang-format should be applied to all newly added files
> before commit.
>
> Eugene.
>
> On Fri, Dec 11, 2015 at 2:30 PM, Zachary Turner 
> wrote:
> > Back on the topic of clang-format, what would it take to make
> clang-format a
> > regular part of peoples' workflows?
> >
> > On Fri, Dec 11, 2015 at 2:27 PM Todd F

[Lldb-commits] [lldb] r255417 - When supplying memory to expedite the unwinds in the T packet,

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Fri Dec 11 19:32:09 2015
New Revision: 255417

URL: http://llvm.org/viewvc/llvm-project?rev=255417&view=rev
Log:
When supplying memory to expedite the unwinds in the T packet,
include two stack frames worth of unwind information instead of
just one -- the unwinder is trying to fetch two stack frames in
more instances now and we're sending extra memory reads resulting
in a performance degredation while stepping.


Modified:
lldb/trunk/tools/debugserver/source/RNBRemote.cpp

Modified: lldb/trunk/tools/debugserver/source/RNBRemote.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/RNBRemote.cpp?rev=255417&r1=255416&r2=255417&view=diff
==
--- lldb/trunk/tools/debugserver/source/RNBRemote.cpp (original)
+++ lldb/trunk/tools/debugserver/source/RNBRemote.cpp Fri Dec 11 19:32:09 2015
@@ -2812,7 +2812,7 @@ RNBRemote::SendStopReplyPacketForThread
 // Add expedited stack memory so stack backtracing doesn't need to 
read anything from the
 // frame pointer chain.
 StackMemoryMap stack_mmap;
-ReadStackMemory (pid, tid, stack_mmap, 1);
+ReadStackMemory (pid, tid, stack_mmap, 2);
 if (!stack_mmap.empty())
 {
 for (const auto &stack_memory : stack_mmap)


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

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Siva Chandra via lldb-commits]

sivachandra updated this revision to Diff 42614.
sivachandra added a comment.

Use file names.


http://reviews.llvm.org/D15437

Files:
  include/lldb/Symbol/CompileUnit.h
  include/lldb/Symbol/DebugMacros.h
  include/lldb/Symbol/SymbolFile.h
  include/lldb/Symbol/SymbolVendor.h
  include/lldb/lldb-enumerations.h
  packages/Python/lldbsuite/test/expression_command/macros/Makefile
  packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py
  packages/Python/lldbsuite/test/expression_command/macros/macro1.h
  packages/Python/lldbsuite/test/expression_command/macros/macro2.h
  packages/Python/lldbsuite/test/expression_command/macros/main.cpp
  packages/Python/lldbsuite/test/make/Makefile.rules
  source/Expression/ExpressionSourceCode.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  source/Plugins/SymbolFile/DWARF/CMakeLists.txt
  source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.cpp
  source/Plugins/SymbolFile/DWARF/DWARFDebugMacro.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.cpp
  source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.h
  source/Symbol/CMakeLists.txt
  source/Symbol/CompileUnit.cpp
  source/Symbol/DebugMacros.cpp
  source/Symbol/ObjectFile.cpp
  source/Symbol/SymbolVendor.cpp
  source/Utility/ConvertEnum.cpp

Index: source/Utility/ConvertEnum.cpp
===
--- source/Utility/ConvertEnum.cpp
+++ source/Utility/ConvertEnum.cpp
@@ -77,6 +77,8 @@
 return "dwarf-loc";
 case eSectionTypeDWARFDebugMacInfo:
 return "dwarf-macinfo";
+case eSectionTypeDWARFDebugMacro:
+return "dwarf-macro";
 case eSectionTypeDWARFDebugPubNames:
 return "dwarf-pubnames";
 case eSectionTypeDWARFDebugPubTypes:
Index: source/Symbol/SymbolVendor.cpp
===
--- source/Symbol/SymbolVendor.cpp
+++ source/Symbol/SymbolVendor.cpp
@@ -186,6 +186,18 @@
 }
 
 bool
+SymbolVendor::ParseCompileUnitDebugMacros (const SymbolContext &sc)
+{
+ModuleSP module_sp(GetModule());
+if (module_sp)
+{
+lldb_private::Mutex::Locker locker(module_sp->GetMutex());
+if (m_sym_file_ap.get())
+return m_sym_file_ap->ParseCompileUnitDebugMacros(sc);
+}
+return false;
+}
+bool
 SymbolVendor::ParseCompileUnitSupportFiles (const SymbolContext& sc, FileSpecList& support_files)
 {
 ModuleSP module_sp(GetModule());
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -362,6 +362,7 @@
 case eSectionTypeDWARFDebugLine:
 case eSectionTypeDWARFDebugLoc:
 case eSectionTypeDWARFDebugMacInfo:
+case eSectionTypeDWARFDebugMacro:
 case eSectionTypeDWARFDebugPubNames:
 case eSectionTypeDWARFDebugPubTypes:
 case eSectionTypeDWARFDebugRanges:
Index: source/Symbol/DebugMacros.cpp
===
--- /dev/null
+++ source/Symbol/DebugMacros.cpp
@@ -0,0 +1,65 @@
+//===-- DebugMacros.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb/Symbol/DebugMacros.h"
+
+#include "lldb/Symbol/CompileUnit.h"
+
+using namespace lldb_private;
+
+DebugMacroEntry::DebugMacroEntry(EntryType type,
+ uint32_t line,
+ uint32_t debug_line_file_idx,
+ const char *str)
+: m_type(type),
+  m_line(line),
+  m_debug_line_file_idx(debug_line_file_idx),
+  m_str(str)
+{ }
+
+DebugMacroEntry::DebugMacroEntry(EntryType type,
+ const DebugMacrosSP &debug_macros_sp)
+: m_type(type), m_line(0), m_debug_line_file_idx(0), m_debug_macros_sp(debug_macros_sp)
+{ }
+
+const FileSpec&
+DebugMacroEntry::GetFileSpec(CompileUnit *comp_unit) const
+{
+return comp_unit->GetSupportFiles().GetFileSpecAtIndex(m_debug_line_file_idx);
+}
+
+DebugMacroEntry
+DebugMacroEntry::CreateDefineEntry(uint32_t line, const char *str)
+{
+return DebugMacroEntry(DebugMacroEntry::DEFINE, line, 0, str);
+}
+
+DebugMacroEntry
+DebugMacroEntry::CreateUndefEntry(uint32_t line, const char *str)
+{
+return DebugMacroEntry(DebugMacroEntry::UNDEF, line,

Re: [Lldb-commits] [PATCH] D15437: Read macro info from .debug_macro section and use it for expression evaluation.

[Siva Chandra via lldb-commits]

sivachandra added a comment.

PTAL. I have now covered the case I missed. Added test for that as well.


http://reviews.llvm.org/D15437



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

[Lldb-commits] [lldb] r255419 - Remove unused mips typedefs.

[Oleksiy Vyalov via lldb-commits]

Author: ovyalov
Date: Fri Dec 11 20:13:17 2015
New Revision: 255419

URL: http://llvm.org/viewvc/llvm-project?rev=255419&view=rev
Log:
Remove unused mips typedefs.


Modified:
lldb/trunk/source/Plugins/Process/Linux/Procfs.h

Modified: lldb/trunk/source/Plugins/Process/Linux/Procfs.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/Procfs.h?rev=255419&r1=255418&r2=255419&view=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/Procfs.h (original)
+++ lldb/trunk/source/Plugins/Process/Linux/Procfs.h Fri Dec 11 20:13:17 2015
@@ -21,9 +21,6 @@ typedef struct user_fpsimd_state elf_fpr
 #define NT_FPREGSET NT_PRFPREG
 #endif // NT_FPREGSET
 #elif defined (__mips__)
-typedef unsigned long elf_greg_t;
-typedef elf_greg_t elf_gregset_t[(sizeof (struct user_regs_struct) / 
sizeof(elf_greg_t))];
-typedef struct user_fpsimd_state elf_fpregset_t;
 #ifndef NT_FPREGSET
 #define NT_FPREGSET NT_PRFPREG
 #endif // NT_FPREGSET
@@ -31,3 +28,4 @@ typedef struct user_fpsimd_state elf_fpr
 #else  // __ANDROID__
 #include 
 #endif // __ANDROID__
+


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

[Lldb-commits] [lldb] r255421 - Fix the L1 cache search in MemoryCache::Read to use the

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Fri Dec 11 21:06:10 2015
New Revision: 255421

URL: http://llvm.org/viewvc/llvm-project?rev=255421&view=rev
Log:
Fix the L1 cache search in MemoryCache::Read to use the 
stl upper_bound method instead of lower_bound - we were
failing to find some cached data in the L1 cache resulting
in extra memory read packets while stepping.

The bug with the existing code looked like this:
If the L1 cache has 8 bytes at address 0x1000 and 8 bytes
at address 0x2000 and we are searching for 4 bytes at 0x2004,
the use of lower_bound would return the end() of the container
and so we would incorrectly treat the memory as uncached.

(the L1 cache is memory seeded from debugserver in the T aka
questionmark packet, where debugserver will send up the stack
memory that likely contains the caller's stack pointer and 
frame pointer values.)

 

Modified:
lldb/trunk/source/Target/Memory.cpp

Modified: lldb/trunk/source/Target/Memory.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Memory.cpp?rev=255421&r1=255420&r2=255421&view=diff
==
--- lldb/trunk/source/Target/Memory.cpp (original)
+++ lldb/trunk/source/Target/Memory.cpp Fri Dec 11 21:06:10 2015
@@ -164,24 +164,16 @@ MemoryCache::Read (addr_t addr,
 if (!m_L1_cache.empty())
 {
 AddrRange read_range(addr, dst_len);
-BlockMap::iterator pos = m_L1_cache.lower_bound(addr);
-if (pos != m_L1_cache.end())
+BlockMap::iterator pos = m_L1_cache.upper_bound(addr);
+if (pos != m_L1_cache.begin ())
 {
-AddrRange chunk_range(pos->first, pos->second->GetByteSize());
-bool match = chunk_range.Contains(read_range);
-if (!match && pos != m_L1_cache.begin())
-{
---pos;
-chunk_range.SetRangeBase(pos->first);
-chunk_range.SetByteSize(pos->second->GetByteSize());
-match = chunk_range.Contains(read_range);
-}
-
-if (match)
-{
-memcpy(dst, pos->second->GetBytes() + addr - 
chunk_range.GetRangeBase(), dst_len);
-return dst_len;
-}
+--pos;
+}
+AddrRange chunk_range(pos->first, pos->second->GetByteSize());
+if (chunk_range.Contains(read_range))
+{
+memcpy(dst, pos->second->GetBytes() + addr - 
chunk_range.GetRangeBase(), dst_len);
+return dst_len;
 }
 }
 


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

Re: [Lldb-commits] [PATCH] D15407: When stepping in/over source lines, combine the addr ranges of all line table entries w/ same line num

[Jason Molenda via lldb-commits]

jasonmolenda removed rL LLVM as the repository for this revision.
jasonmolenda updated this revision to Diff 42630.
jasonmolenda added a comment.

Updated patch attached which addresses Jim's feedback.

1. Updated LineEntry.h description of new GetSameLineContiguousAddressRange 
method to describe exactly how line table entries with line num 0 are handled.

2. Changed LineEntry::GetSameLineContiguousAddressRange impl so that if it 
starts with a line entry line number of 0, it will expand the range to include 
any contiguous line #0 entries, but will not expand it any further than that.

3. Fixed the two overly-long lines in Thread.cpp.


http://reviews.llvm.org/D15407

Files:
  include/lldb/Symbol/LineEntry.h
  include/lldb/Target/Thread.h
  source/API/SBThread.cpp
  source/Commands/CommandObjectThread.cpp
  source/Symbol/LineEntry.cpp
  source/Target/Thread.cpp
  source/Target/ThreadPlanStepRange.cpp

Index: source/Target/ThreadPlanStepRange.cpp
===
--- source/Target/ThreadPlanStepRange.cpp
+++ source/Target/ThreadPlanStepRange.cpp
@@ -162,7 +162,7 @@
 if (m_addr_context.line_entry.line == new_context.line_entry.line)
 {
 m_addr_context = new_context;
-AddRange(m_addr_context.line_entry.range);
+AddRange(m_addr_context.line_entry.GetSameLineContiguousAddressRange());
 ret_value = true;
 if (log)
 {
@@ -181,7 +181,7 @@
 {
 new_context.line_entry.line = m_addr_context.line_entry.line;
 m_addr_context = new_context;
-AddRange(m_addr_context.line_entry.range);
+AddRange(m_addr_context.line_entry.GetSameLineContiguousAddressRange());
 ret_value = true;
 if (log)
 {
Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -1535,7 +1535,22 @@
 return thread_plan_sp;
 }
 
+// Call the QueueThreadPlanForStepOverRange method which takes an address range.
 ThreadPlanSP
+Thread::QueueThreadPlanForStepOverRange(bool abort_other_plans,
+const LineEntry &line_entry,
+const SymbolContext &addr_context,
+lldb::RunMode stop_other_threads,
+LazyBool step_out_avoids_code_withoug_debug_info)
+{
+return QueueThreadPlanForStepOverRange (abort_other_plans, 
+line_entry.GetSameLineContiguousAddressRange(), 
+addr_context, 
+stop_other_threads, 
+step_out_avoids_code_withoug_debug_info);
+}
+
+ThreadPlanSP
 Thread::QueueThreadPlanForStepInRange(bool abort_other_plans,
   const AddressRange &range,
   const SymbolContext &addr_context,
@@ -1559,7 +1574,27 @@
 return thread_plan_sp;
 }
 
+// Call the QueueThreadPlanForStepInRange method which takes an address range.
 ThreadPlanSP
+Thread::QueueThreadPlanForStepInRange(bool abort_other_plans,
+  const LineEntry &line_entry,
+  const SymbolContext &addr_context,
+  const char *step_in_target,
+  lldb::RunMode stop_other_threads,
+  LazyBool step_in_avoids_code_without_debug_info,
+  LazyBool step_out_avoids_code_without_debug_info)
+{
+return QueueThreadPlanForStepInRange (abort_other_plans, 
+  line_entry.GetSameLineContiguousAddressRange(), 
+  addr_context, 
+  step_in_target, 
+  stop_other_threads, 
+  step_in_avoids_code_without_debug_info, 
+  step_out_avoids_code_without_debug_info);
+}
+
+
+ThreadPlanSP
 Thread::QueueThreadPlanForStepOut(bool abort_other_plans,
   SymbolContext *addr_context,
   bool first_insn,
@@ -2374,7 +2409,7 @@
 {
 SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
 new_plan_sp = QueueThreadPlanForStepInRange (abort_other_plans,
- sc.line_entry.range,
+ sc.line_entry,