Re: [Lldb-commits] [PATCH] D14631: [dwarf] Handle DWARF forms for address other than DW_FORM_GNU_addr_index and DW_FORM_addr.

[Tamas Berghammer via lldb-commits]

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

LGTM

(Next time please upload the diff with full context because it is easier to 
review that way)


Repository:
  rL LLVM

http://reviews.llvm.org/D14631



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

[Lldb-commits] [lldb] r253026 - Fix to solve Bug 23139 & Bug 23560

[Abhishek Aggarwal via lldb-commits]

Author: abhishek
Date: Fri Nov 13 04:47:49 2015
New Revision: 253026

URL: http://llvm.org/viewvc/llvm-project?rev=253026=rev
Log:
Fix to solve Bug 23139 & Bug 23560

Summary:
 - Reason of both bugs:

   1. For the very first frame, Unwinder doesn't check the validity
  of Full UnwindPlan before creating StackFrame from it:

When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.

   2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
  fails and FallBack UnwindPlan succeeds in providing valid CFA values
  for frames:

Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.

If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.

 - This patch fixes both these issues.

 - Remove XFAIL in test files corresponding to these 2 Bugs

Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal 

Reviewers: jingham, lldb-commits, jasonmolenda

Subscribers: lldb-commits, ovyalov, tberghammer

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py

lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py

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

lldb/trunk/packages/Python/lldbsuite/test/functionalities/embedded_interpreter/TestConvenienceVariables.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/read/TestMemoryRead.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py?rev=253026=253025=253026=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 Fri Nov 13 04:47:49 2015
@@ -17,7 +17,6 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfRemote
 @skipIfNoSBHeaders
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
-@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_breakpoint_callback(self):
 """Test the that SBBreakpoint callback is invoked when a breakpoint is 
hit. """
 self.build_and_test('driver.cpp test_breakpoint_callback.cpp',
@@ -27,7 +26,6 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfNoSBHeaders
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
 @expectedFlakeyFreeBSD
-@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_sb_api_listener_event_description(self):
 """ Test the description of an SBListener breakpoint event is valid."""
 self.build_and_test('driver.cpp listener_test.cpp 
test_listener_event_description.cpp',
@@ -39,7 +37,6 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
 @expectedFlakeyFreeBSD
 @expectedFlakeyLinux # Driver occasionally returns '1' as exit status
-@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_sb_api_listener_event_process_state(self):
 """ Test that a registered SBListener receives events when a process
 changes state.

Modified: 

Re: [Lldb-commits] [PATCH] D14611: Remove a broken hack from Scalar::ULongLong and fix a test

[Tamas Berghammer via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL253027: Remove a broken hack from Scalar::ULongLong and fix 
a test (authored by tberghammer).

Changed prior to commit:
  http://reviews.llvm.org/D14611?vs=40031=40128#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14611

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
  lldb/trunk/source/Core/Scalar.cpp

Index: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
@@ -50,5 +50,5 @@
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() 
!= 0x, "GetValueAsSigned() does not say 0x")
 
 
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != -1, 
"GetValueAsUnsigned() does not say -1")
-
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 
0x, "GetValueAsUnsigned() says 0x")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() 
!= 0x, "GetValueAsUnsigned() does not say 0x")
+
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 
0x, "GetValueAsUnsigned() says 0x")
+
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != 
0x, "GetValueAsUnsigned() does not says 0x")
Index: lldb/trunk/source/Core/Scalar.cpp
===
--- lldb/trunk/source/Core/Scalar.cpp
+++ lldb/trunk/source/Core/Scalar.cpp
@@ -1574,8 +1574,6 @@
 case e_ulonglong:
 case e_sint128:
 case e_uint128:
-if(m_integer.isAllOnesValue())
-return *(const ulonglong_t 
*)(llvm::APInt::getAllOnesValue(128)).getRawData();
 return *(const ulonglong_t *)m_integer.getRawData();
 case e_float:
 return (ulonglong_t)m_float.convertToFloat();


Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
@@ -50,5 +50,5 @@
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() != 0x, "GetValueAsSigned() does not say 0x")
 
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != -1, "GetValueAsUnsigned() does not say -1")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 0x, "GetValueAsUnsigned() says 0x")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() != 0x, "GetValueAsUnsigned() does not say 0x")
+self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 0x, "GetValueAsUnsigned() says 0x")
+self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != 0x, "GetValueAsUnsigned() does not says 0x")
Index: lldb/trunk/source/Core/Scalar.cpp
===
--- lldb/trunk/source/Core/Scalar.cpp
+++ lldb/trunk/source/Core/Scalar.cpp
@@ -1574,8 +1574,6 @@
 case e_ulonglong:
 case e_sint128:
 case e_uint128:
-if(m_integer.isAllOnesValue())
-return *(const ulonglong_t *)(llvm::APInt::getAllOnesValue(128)).getRawData();
 return *(const ulonglong_t *)m_integer.getRawData();
 case e_float:
 return (ulonglong_t)m_float.convertToFloat();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r253028 - Fix multiple symbol lookup in the same namespace

[Eugene Leviant via lldb-commits]

Author: evgeny777
Date: Fri Nov 13 05:00:10 2015
New Revision: 253028

URL: http://llvm.org/viewvc/llvm-project?rev=253028=rev
Log:
Fix multiple symbol lookup in the same namespace

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py?rev=253028=253027=253028=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/TestNamespace.py 
Fri Nov 13 05:00:10 2015
@@ -26,6 +26,16 @@ class NamespaceTestCase(TestBase):
 # And the line number to break at.
 self.line_break = line_number('main.cpp',
 '// Set break point at this line.')
+# Break inside do {} while and evaluate value
+self.line_break_ns1 = line_number('main.cpp', '// Evaluate ns1::value')
+self.line_break_ns2 = line_number('main.cpp', '// Evaluate ns2::value')
+
+def runToBkpt(self, command):
+self.runCmd(command, RUN_SUCCEEDED)
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs = ['stopped',
+   'stop reason = breakpoint'])
 
 # rdar://problem/8668674
 @expectedFailureWindows("llvm.org/pr24764")
@@ -34,15 +44,19 @@ class NamespaceTestCase(TestBase):
 self.build()
 self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
 
+lldbutil.run_break_set_by_file_and_line (self, "main.cpp", 
self.line_break_ns1, num_expected_locations=1, loc_exact=True)
+lldbutil.run_break_set_by_file_and_line (self, "main.cpp", 
self.line_break_ns2, num_expected_locations=1, loc_exact=True)
 lldbutil.run_break_set_by_file_and_line (self, "main.cpp", 
self.line_break, num_expected_locations=1, loc_exact=True)
 
-self.runCmd("run", RUN_SUCCEEDED)
-
-# The stop reason of the thread should be breakpoint.
-self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
-substrs = ['stopped',
-   'stop reason = breakpoint'])
-
+self.runToBkpt("run")
+# Evaluate ns1::value
+self.expect("expression -- value", startstr = "(int) $0 = 100")
+
+self.runToBkpt("continue")
+# Evaluate ns2::value
+self.expect("expression -- value", startstr = "(int) $1 = 200")
+
+self.runToBkpt("continue")
 # On Mac OS X, gcc 4.2 emits the wrong debug info with respect to 
types.
 slist = ['(int) a = 12', 'anon_uint', 'a_uint', 'b_uint', 'y_uint']
 if self.platformIsDarwin() and self.getCompiler() in ['clang', 
'llvm-gcc']:
@@ -83,8 +97,8 @@ class NamespaceTestCase(TestBase):
 # test/namespace: 'expression -- i+j' not working
 # This has been fixed.
 self.expect("expression -- i + j",
-startstr = "(int) $0 = 7")
-# (int) $0 = 7
+startstr = "(int) $2 = 7")
+# (int) $2 = 7
 
 self.runCmd("expression -- i")
 self.runCmd("expression -- j")

Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp?rev=253028=253027=253028=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp Fri 
Nov 13 05:00:10 2015
@@ -72,9 +72,31 @@ namespace A {
 }
 }
 
+namespace ns1 {
+int value = 100;
+}
+
+namespace ns2 {
+int value = 200;
+}
+
 #include 
+void test_namespace_scopes() {
+do {
+using namespace ns1;
+printf("ns1::value = %d\n", value); // Evaluate ns1::value
+} while(0);
+
+do {
+using namespace ns2;
+printf("ns2::value = %d\n", value); // Evaluate ns2::value
+} while(0);
+}
+
 int Foo::myfunc(int a)
 {
+test_namespace_scopes();
+
 ::my_uint_t anon_uint = 0;
 A::uint_t a_uint = 1;
 B::uint_t b_uint = 2;

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=253028=253027=253028=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Fri Nov 13 05:00:10 2015
@@ -9186,7 +9186,8 @@ 

[Lldb-commits] [lldb] r253034 - Re-add XFAILs to two tests

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Nov 13 05:56:09 2015
New Revision: 253034

URL: http://llvm.org/viewvc/llvm-project?rev=253034=rev
Log:
Re-add XFAILs to two tests

these decorators were two of many removed in r253026. Unlike others, these 
tests still seem to be
failing...

Modified:

lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py

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

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py?rev=253034=253033=253034=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 Fri Nov 13 05:56:09 2015
@@ -17,6 +17,7 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfRemote
 @skipIfNoSBHeaders
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
+@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_breakpoint_callback(self):
 """Test the that SBBreakpoint callback is invoked when a breakpoint is 
hit. """
 self.build_and_test('driver.cpp test_breakpoint_callback.cpp',

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py?rev=253034=253033=253034=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
 Fri Nov 13 05:56:09 2015
@@ -21,6 +21,7 @@ class SynthDataFormatterTestCase(TestBas
 # Find the line number to break at.
 self.line = line_number('main.cpp', '// Set break point at this line.')
 
+@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64","i386"])
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()


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

[Lldb-commits] [lldb] r253054 - Make PythonDataObjects.h work when LLDB_DISABLE_PYTHON=1

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 11:27:20 2015
New Revision: 253054

URL: http://llvm.org/viewvc/llvm-project?rev=253054=rev
Log:
Make PythonDataObjects.h work when LLDB_DISABLE_PYTHON=1

Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h

Modified: lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h?rev=253054=253053=253054=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h Fri 
Nov 13 11:27:20 2015
@@ -10,6 +10,8 @@
 #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H
 #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H
 
+#ifndef LLDB_DISABLE_PYTHON
+
 // C Includes
 // C++ Includes
 // Other libraries and framework includes
@@ -488,4 +490,6 @@ class PythonFile : public PythonObject
 
 } // namespace lldb_private
 
+#endif
+
 #endif // LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h?rev=253054=253053=253054=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h 
Fri Nov 13 11:27:20 2015
@@ -10,6 +10,8 @@
 #ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONEXCEPTIONSTATE_H
 #define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONEXCEPTIONSTATE_H
 
+#ifndef LLDB_DISABLE_PYTHON
+
 #include "PythonDataObjects.h"
 
 namespace lldb_private
@@ -64,3 +66,5 @@ class PythonExceptionState
 }
 
 #endif
+
+#endif


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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

Ahh, good to know.  Thanks!

On Fri, Nov 13, 2015 at 2:47 AM Tamas Berghammer 
wrote:

> We already have a test for it in TestConsecutiveBreakpoints.py what is
> xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As
> far as I see from the build bots the test is also failing on OSX, but it
> might fail from a different reason then on Linux/Windows.
>
> On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Thanks!  Do you think you could add a test that does specifically that?
>> Set two breakpoints back to back, even in the same function, ane ensure
>> that the second one gets hit.  If your theory is right this test will fail
>> on Windows and Linux (and then we'll have to xfail it) but at least we'll
>> have a test that's isolated to the root of the problem.
>>
>> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham  wrote:
>>
>>> Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on
>>> Linux for me, but I don't have a windows machine handy to test.
>>>
>>> What was happening is that originally lldb had a bug where if you were
>>> stopped on a breakpoint and then the next instruction also had a
>>> breakpoint, the plan that was stepping over the breakpoint would see a stop
>>> reason of "trace" so it would think it knew why it stopped and would
>>> auto-continue, since that's what you do when you are doing "step over a
>>> breakpoint and keep going."
>>>
>>> I fixed this by having the lower layers of the process plugin correct
>>> the stop reason from trace to breakpoint when a trace ended up on another
>>> breakpoint, but apparently Linux and Windows don't have this fix.  That was
>>> done a while ago, so maybe they weren't around then, I have to think about
>>> that...
>>>
>>> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we
>>> only needed to go one instruction, it wouldn't do it with a breakpoint, but
>>> just stepi.  I didn't preserve that in the change I made, so we got into
>>> trouble.  So for now I just put that short-cut back.
>>>
>>> I wondered how this managed to cause so many Linux failures, but the OS
>>> X testsuite was clean...
>>>
>>> Jim
>>>
>>>
>>>
>>> > On Nov 12, 2015, at 4:57 PM, Zachary Turner 
>>> wrote:
>>> >
>>> > Ahh, seems it wasn't just Windows that was affected by this.  Makes me
>>> feel a little better :)
>>> >
>>> > Posting the link to the buildbot failures here so that Jim can get
>>> full logs if it helps.
>>> >
>>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
>>> >
>>> > On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
>>> > I reverted this patch for now.
>>> > Please resubmit if you have a fix.
>>> >
>>> > Thanks,
>>> > Ying
>>> >
>>> > On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>> > If you can debug a failing case, and do whatever step operation got
>>> you to the wrong place, then run up to that step, and do:
>>> >
>>> > (lldb) log enable -f  lldb step
>>> >
>>> > and then do the step, then send me that log plus the disassembly for
>>> the function you were stepping in and the output of:
>>> >
>>> > (lldb) image dump line-table 
>>> >
>>> > for the source file you were stepping in.
>>> >
>>> > I should be able to see from there why we were stepping to the wrong
>>> place.
>>> >
>>> > Jim
>>> >
>>> > > On Nov 12, 2015, at 4:03 PM, Zachary Turner 
>>> wrote:
>>> > >
>>> > > The error messages are always different because the error message is
>>> printed by the test.  I'm going to try to load up the executable for
>>> TestStepNoDebug in the debugger and get a disassembly and do the step
>>> > >
>>> > > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham 
>>> wrote:
>>> > > Is the line they stepped to - instead of the expected line - always
>>> line 0?
>>> > >
>>> > > Jim
>>> > >
>>> > > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
>>> wrote:
>>> > > >
>>> > > > Hi Jim,
>>> > > >
>>> > > > This breaks about 12 tests on Windows.  The patch looks simple,
>>> but this isn't really my area, is there anything I can give you to help
>>> diagnose what might be wrong?  The following tests fail:
>>> > > >
>>> > > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81
>>> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>>> > > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
>>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>>> GenuineIntel)
>>> > > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
>>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>>> GenuineIntel)
>>> > > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
>>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>>> GenuineIntel)
>>> > > > FAIL: 

Re: [Lldb-commits] [PATCH] D14634: [LLDB][MIPS] Fix TestDisassembleBreakpoint.py for MIPS

[Oleksiy Vyalov via lldb-commits]

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

lgtm


Repository:
  rL LLVM

http://reviews.llvm.org/D14634



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

[Lldb-commits] [lldb] r253057 - Add `PythonExceptionStateTests.cpp` to lldb-gtest target.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 12:10:11 2015
New Revision: 253057

URL: http://llvm.org/viewvc/llvm-project?rev=253057=rev
Log:
Add `PythonExceptionStateTests.cpp` to lldb-gtest target.

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

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=253057=253056=253057=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Fri Nov 13 12:10:11 2015
@@ -653,6 +653,7 @@
3F8169311ABB7A6D001DA9DF /* SystemInitializer.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 3F81692E1ABB7A6D001DA9DF /* 
SystemInitializer.cpp */; };
3F8169321ABB7A6D001DA9DF /* SystemInitializerCommon.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 3F81692F1ABB7A6D001DA9DF /* 
SystemInitializerCommon.cpp */; };
3F8169331ABB7A6D001DA9DF /* SystemLifetimeManager.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 3F8169301ABB7A6D001DA9DF /* 
SystemLifetimeManager.cpp */; };
+   3FA093151BF65D3A0037DD08 /* PythonExceptionStateTests.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 3FA093141BF65D3A0037DD08 /* 
PythonExceptionStateTests.cpp */; };
3FBA69DF1B6067020008F44A /* ScriptInterpreterNone.cpp in 
CopyFiles */ = {isa = PBXBuildFile; fileRef = 3FBA69DD1B6067020008F44A /* 
ScriptInterpreterNone.cpp */; };
3FBA69E01B6067020008F44A /* ScriptInterpreterNone.h in 
CopyFiles */ = {isa = PBXBuildFile; fileRef = 3FBA69DE1B6067020008F44A /* 
ScriptInterpreterNone.h */; };
3FBA69E11B6067120008F44A /* ScriptInterpreterNone.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 3FBA69DD1B6067020008F44A /* 
ScriptInterpreterNone.cpp */; };
@@ -2225,6 +2226,7 @@
3F8169341ABB7A80001DA9DF /* SystemInitializer.h */ = {isa = 
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = 
SystemInitializer.h; path = include/lldb/Initialization/SystemInitializer.h; 
sourceTree = ""; };
3F8169351ABB7A80001DA9DF /* SystemInitializerCommon.h */ = {isa 
= PBXFileReference; lastKnownFileType = sourcecode.c.h; name = 
SystemInitializerCommon.h; path = 
include/lldb/Initialization/SystemInitializerCommon.h; sourceTree = ""; 
};
3F8169361ABB7A80001DA9DF /* SystemLifetimeManager.h */ = {isa = 
PBXFileReference; lastKnownFileType = sourcecode.c.h; name = 
SystemLifetimeManager.h; path = 
include/lldb/Initialization/SystemLifetimeManager.h; sourceTree = ""; };
+   3FA093141BF65D3A0037DD08 /* PythonExceptionStateTests.cpp */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; path = PythonExceptionStateTests.cpp; sourceTree = 
""; };
3FBA69DD1B6067020008F44A /* ScriptInterpreterNone.cpp */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = ScriptInterpreterNone.cpp; path = 
ScriptInterpreter/None/ScriptInterpreterNone.cpp; sourceTree = ""; };
3FBA69DE1B6067020008F44A /* ScriptInterpreterNone.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
ScriptInterpreterNone.h; path = ScriptInterpreter/None/ScriptInterpreterNone.h; 
sourceTree = ""; };
3FBA69E21B60672A0008F44A /* lldb-python.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
"lldb-python.h"; path = "ScriptInterpreter/Python/lldb-python.h"; sourceTree = 
""; };
@@ -3098,6 +3100,7 @@
children = (
2321F94C1BDD360F00BA9A93 /* CMakeLists.txt */,
2321F94D1BDD360F00BA9A93 /* 
PythonDataObjectsTests.cpp */,
+   3FA093141BF65D3A0037DD08 /* 
PythonExceptionStateTests.cpp */,
AF45E1FC1BF57C8D000563EB /* PythonTestSuite.cpp 
*/,
AF45E1FD1BF57C8D000563EB /* PythonTestSuite.h 
*/,
);
@@ -6311,6 +6314,7 @@
AEC6FFA01BE970A2007882C1 /* GoParserTest.cpp in 
Sources */,
239504E51BDD454B00963CEA /* UriParserTest.cpp 
in Sources */,
AF45E1FE1BF57C8D000563EB /* PythonTestSuite.cpp 
in Sources */,
+   3FA093151BF65D3A0037DD08 /* 
PythonExceptionStateTests.cpp in Sources */,
239504DF1BDD453200963CEA /* SocketTest.cpp in 
Sources */,
239504E11BDD453E00963CEA /* TestArgs.cpp in 
Sources */,
239504E21BDD454500963CEA /* 
PythonDataObjectsTests.cpp in Sources */,


___
lldb-commits mailing list
lldb-commits@lists.llvm.org

Re: [Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.

I agree with tberghammer.


Repository:
  rL LLVM

http://reviews.llvm.org/D14633



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

Re: [Lldb-commits] [PATCH] D14631: [dwarf] Handle DWARF forms for address other than DW_FORM_GNU_addr_index and DW_FORM_addr.

[Greg Clayton via lldb-commits]

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

This is not the right fix. Compilers that emit addresses with DW_FORM_data* 
forms are saying that this address is an offset from the DW_AT_low_pc so this 
function will not return a valid address, but it will now return an offset. If 
you have a compiler that is actually emitting addresses incorrectly using 
DW_FORM_data* when the values are not offsets, the compiler should be fixed.

There are two solutions to this:
1 - modify DWARFFormValue::Address() to return LLDB_INVALID_ADDRESS if the form 
is not DW_FORM_addr or DW_FORM_GNU_addr_index.
2 - modify DWARFFormValue::Address() to take an lldb::addr_t that is the base 
address that the DW_FORM_data* would be relative to. This argument could be 
defaulted:

  dw_addr_t
  DWARFFormValue::Address(lldb::addr_t base_addr = LLDB_INVALID_ADDRESS) const

Then in the code we would do:

  dw_addr_t
  DWARFFormValue::Address(lldb::addr_t base_addr) const
  {
  switch (m_form)
  {
  case DW_FORM_addr:
  return Unsigned();
  case DW_FORM_GNU_addr_index:
  if (m_cu)
  {
  SymbolFileDWARF* symbol_file = m_cu->GetSymbolFileDWARF();
  if (symbol_file)
  {
  uint32_t index_size = m_cu->GetAddressByteSize();
  dw_offset_t addr_base = m_cu->GetAddrBase();
  lldb::offset_t offset = addr_base + m_value.value.uval * 
index_size;
  return symbol_file->get_debug_addr_data().GetMaxU64(, 
index_size);
  }
  }
  break;
   case DW_FORM_data1:
   case DW_FORM_data2:
   case DW_FORM_data4:
   case DW_FORM_data8:
   case DW_FORM_sdata:
   case DW_FORM_udata:
   if (base_addr != LLDB_INVALID_ADDRESS)
  return base_addr + Unsigned();
  default:
  break;
  }
  return LLDB_INVALID_ADDRESS;
  }




Repository:
  rL LLVM

http://reviews.llvm.org/D14631



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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

Huh, I'll go check out that test.  The basic functionality works on OS X:

(lldb) b s -n main
Breakpoint 1: 21 locations.
(lldb) run
Process 58218 launched: 'Sketch' (x86_64)
Process 58218 stopped
* thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 1.1
frame #0: 0x000100018dc7 Sketch`main at SKTMain.m:17
   14   }
   15   
   16   int main(int argc, const char *argv[]) {
-> 17   NSLog (@"Added for testing rebuilds.");
   18   bool got_a_bool = NO;
   19   NSString *text_to_use = @"٢٠ شباط";
   20   
(lldb) dis -p
Sketch`main:
->  0x100018dc7 <+55>: movq   %rax, %rdi
0x100018dca <+58>: movb   $0x0, %al
0x100018dcc <+60>: callq  0x10001d21a   ; symbol stub for: NSLog
0x100018dd1 <+65>: leaq   0xa530(%rip), %rcx; 
@Sketch.__TEXT.__ustring + 0
(lldb) b s -a 0x100018dca
Breakpoint 2: where = Sketch`main + 58 at SKTMain.m:17, address = 
0x000100018dca
(lldb) c
Process 58218 resuming
Process 58218 stopped
* thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 2.1
frame #0: 0x000100018dca Sketch`main at SKTMain.m:17
   14   }
   15   
   16   int main(int argc, const char *argv[]) {
-> 17   NSLog (@"Added for testing rebuilds.");
   18   bool got_a_bool = NO;
   19   NSString *text_to_use = @"٢٠ شباط";
   20   

Jim

> On Nov 13, 2015, at 2:47 AM, Tamas Berghammer  wrote:
> 
> We already have a test for it in TestConsecutiveBreakpoints.py what is 
> xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As 
> far as I see from the build bots the test is also failing on OSX, but it 
> might fail from a different reason then on Linux/Windows.
> 
> On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits 
>  wrote:
> Thanks!  Do you think you could add a test that does specifically that?  Set 
> two breakpoints back to back, even in the same function, ane ensure that the 
> second one gets hit.  If your theory is right this test will fail on Windows 
> and Linux (and then we'll have to xfail it) but at least we'll have a test 
> that's isolated to the root of the problem.
> 
> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham  wrote:
> Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on 
> Linux for me, but I don't have a windows machine handy to test.
> 
> What was happening is that originally lldb had a bug where if you were 
> stopped on a breakpoint and then the next instruction also had a breakpoint, 
> the plan that was stepping over the breakpoint would see a stop reason of 
> "trace" so it would think it knew why it stopped and would auto-continue, 
> since that's what you do when you are doing "step over a breakpoint and keep 
> going."
> 
> I fixed this by having the lower layers of the process plugin correct the 
> stop reason from trace to breakpoint when a trace ended up on another 
> breakpoint, but apparently Linux and Windows don't have this fix.  That was 
> done a while ago, so maybe they weren't around then, I have to think about 
> that...
> 
> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we only 
> needed to go one instruction, it wouldn't do it with a breakpoint, but just 
> stepi.  I didn't preserve that in the change I made, so we got into trouble.  
> So for now I just put that short-cut back.
> 
> I wondered how this managed to cause so many Linux failures, but the OS X 
> testsuite was clean...
> 
> Jim
> 
> 
> 
> > On Nov 12, 2015, at 4:57 PM, Zachary Turner  wrote:
> >
> > Ahh, seems it wasn't just Windows that was affected by this.  Makes me feel 
> > a little better :)
> >
> > Posting the link to the buildbot failures here so that Jim can get full 
> > logs if it helps.
> > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
> >
> > On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
> > I reverted this patch for now.
> > Please resubmit if you have a fix.
> >
> > Thanks,
> > Ying
> >
> > On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits 
> >  wrote:
> > If you can debug a failing case, and do whatever step operation got you to 
> > the wrong place, then run up to that step, and do:
> >
> > (lldb) log enable -f  lldb step
> >
> > and then do the step, then send me that log plus the disassembly for the 
> > function you were stepping in and the output of:
> >
> > (lldb) image dump line-table 
> >
> > for the source file you were stepping in.
> >
> > I should be able to see from there why we were stepping to the wrong place.
> >
> > Jim
> >
> > > On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
> > >
> > > The error messages are always different because the error message is 
> > > printed by the test.  I'm going to try to load up the executable for 
> > > TestStepNoDebug in the debugger and get a disassembly and do 

[Lldb-commits] [lldb] r253092 - Change the null check to an assert.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 15:53:03 2015
New Revision: 253092

URL: http://llvm.org/viewvc/llvm-project?rev=253092=rev
Log:
Change the null check to an assert.

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

Modified: lldb/trunk/source/Target/ThreadList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadList.cpp?rev=253092=253091=253092=diff
==
--- lldb/trunk/source/Target/ThreadList.cpp (original)
+++ lldb/trunk/source/Target/ThreadList.cpp Fri Nov 13 15:53:03 2015
@@ -18,6 +18,7 @@
 #include "lldb/Target/ThreadPlan.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Utility/ConvertEnum.h"
+#include "lldb/Utility/LLDBAssert.h"
 
 using namespace lldb;
 using namespace lldb_private;
@@ -538,7 +539,8 @@ ThreadList::WillResume ()
 
 for (pos = m_threads.begin(); pos != end; ++pos)
 {
-if ((*pos)->GetResumeState() != eStateSuspended && 
(*pos)->GetCurrentPlan() &&
+lldbassert((*pos)->GetCurrentPlan() && "thread should not have null 
thread plan");
+if ((*pos)->GetResumeState() != eStateSuspended &&
  (*pos)->GetCurrentPlan()->StopOthers())
 {
 if ((*pos)->IsOperatingSystemPluginThread() && 
!(*pos)->GetBackingThread())


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

[Lldb-commits] [lldb] r253094 - Change the test to use the instruction list to get the consecutive addresses to break on. Rerunning

[Jim Ingham via lldb-commits]

Author: jingham
Date: Fri Nov 13 16:19:08 2015
New Revision: 253094

URL: http://llvm.org/viewvc/llvm-project?rev=253094=rev
Log:
Change the test to use the instruction list to get the consecutive addresses to 
break on.  Rerunning
was being foiled by ASLR.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py?rev=253094=253093=253094=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
 Fri Nov 13 16:19:08 2015
@@ -19,7 +19,7 @@ class ConsecutiveBreakpoitsTestCase(Test
 def test (self):
 self.build ()
 self.consecutive_breakpoints_tests()
-
+
 def consecutive_breakpoints_tests(self):
 exe = os.path.join (os.getcwd(), "a.out")
 
@@ -40,24 +40,15 @@ class ConsecutiveBreakpoitsTestCase(Test
 thread = process.GetThreadAtIndex(0)
 self.assertEqual(thread.GetStopReason(), lldb.eStopReasonBreakpoint)
 
-# Step to the next instruction
-thread.StepInstruction(False)
-self.assertEqual(thread.GetStopReason(), lldb.eStopReasonPlanComplete)
-address = thread.GetFrameAtIndex(0).GetPC()
-
-# Run the process until termination
-process.Continue()
-
-# Now launch the process again, and do not stop at entry point.
-process = target.LaunchSimple (None, None, 
self.get_process_working_directory())
-self.assertTrue(process, PROCESS_IS_VALID)
-
-# We should be stopped at the first breakpoint
-thread = process.GetThreadAtIndex(0)
-self.assertEqual(thread.GetStopReason(), lldb.eStopReasonBreakpoint)
-
 # Set breakpoint to the next instruction
-target.BreakpointCreateByAddress(address)
+frame = thread.GetFrameAtIndex(0)
+
+address = frame.GetPCAddress()
+instructions = target.ReadInstructions(address, 2)
+self.assertTrue(len(instructions) == 2)
+address = instructions[1].GetAddress()
+
+target.BreakpointCreateByAddress(address.GetLoadAddress(target))
 process.Continue()
 
 # We should be stopped at the second breakpoint


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

[Lldb-commits] [lldb] r253073 - Another fix for LLDB_DISABLE_PYTHON=1

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 14:28:31 2015
New Revision: 253073

URL: http://llvm.org/viewvc/llvm-project?rev=253073=rev
Log:
Another fix for LLDB_DISABLE_PYTHON=1

Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp?rev=253073=253072=253073=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
Fri Nov 13 14:28:31 2015
@@ -7,6 +7,8 @@
 //
 
//===--===//
 
+#ifndef LLDB_DISABLE_PYTHON
+
 #include "lldb-python.h"
 #include "PythonExceptionState.h"
 
@@ -202,4 +204,6 @@ PythonExceptionState::ReadBacktrace() co
 retval.assign(string_data.data(), string_data.size());
 
 return retval;
-}
\ No newline at end of file
+}
+
+#endif


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

[Lldb-commits] [lldb] r253086 - Add a null check against the ThreadPlan

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 15:28:53 2015
New Revision: 253086

URL: http://llvm.org/viewvc/llvm-project?rev=253086=rev
Log:
Add a null check against the ThreadPlan

I'm seeing some cases where the ThreadPlan is null.  It could
be a sign of a valid race condition, but at least we shouldn't
crash.

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

Modified: lldb/trunk/source/Target/ThreadList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadList.cpp?rev=253086=253085=253086=diff
==
--- lldb/trunk/source/Target/ThreadList.cpp (original)
+++ lldb/trunk/source/Target/ThreadList.cpp Fri Nov 13 15:28:53 2015
@@ -538,7 +538,7 @@ ThreadList::WillResume ()
 
 for (pos = m_threads.begin(); pos != end; ++pos)
 {
-if ((*pos)->GetResumeState() != eStateSuspended &&
+if ((*pos)->GetResumeState() != eStateSuspended && 
(*pos)->GetCurrentPlan() &&
  (*pos)->GetCurrentPlan()->StopOthers())
 {
 if ((*pos)->IsOperatingSystemPluginThread() && 
!(*pos)->GetBackingThread())


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

[Lldb-commits] [lldb] r253085 - Modernize FormatBacktrace() and make portable for Python 3.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 15:28:45 2015
New Revision: 253085

URL: http://llvm.org/viewvc/llvm-project?rev=253085=rev
Log:
Modernize FormatBacktrace() and make portable for Python 3.

Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp?rev=253085=253084=253085=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
Fri Nov 13 15:28:45 2015
@@ -825,6 +825,14 @@ PythonModule::AddModule(llvm::StringRef
 return PythonModule(PyRefType::Borrowed, PyImport_AddModule(str.c_str()));
 }
 
+
+PythonModule
+PythonModule::ImportModule(llvm::StringRef module)
+{
+std::string str = module.str();
+return PythonModule(PyRefType::Owned, PyImport_ImportModule(str.c_str()));
+}
+
 bool
 PythonModule::Check(PyObject *py_obj)
 {

Modified: lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h?rev=253085=253084=253085=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h Fri 
Nov 13 15:28:45 2015
@@ -415,6 +415,9 @@ class PythonModule : public PythonObject
 static PythonModule
 AddModule(llvm::StringRef module);
 
+static PythonModule
+ImportModule(llvm::StringRef module);
+
 // Bring in the no-argument base class version
 using PythonObject::Reset;
 

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp?rev=253085=253084=253085=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
Fri Nov 13 15:28:45 2015
@@ -146,6 +146,7 @@ PythonExceptionState::Format() const
 }
 else
 {
+__debugbreak();
 // Otherwise, append some information about why we were unable to
 // obtain the backtrace.
 PythonString bt_error = bt_error_state.GetValue().Str();
@@ -157,50 +158,43 @@ PythonExceptionState::Format() const
 std::string
 PythonExceptionState::ReadBacktrace() const
 {
-PythonObject traceback_module;
-PythonObject stringIO_module;
-PythonObject stringIO_builder;
-PythonObject stringIO_buffer;
-PythonObject printTB;
-PythonObject printTB_args;
-PythonObject printTB_result;
-PythonObject stringIO_getvalue;
-PythonObject printTB_string;
-
+__debugbreak();
 std::string retval("backtrace unavailable");
 
+auto traceback_module = PythonModule::ImportModule("traceback");
+#if PY_MAJOR_VERSION >= 3
+auto stringIO_module = PythonModule::ImportModule("io");
+#else
+auto stringIO_module = PythonModule::ImportModule("StringIO");
+#endif
 if (!m_traceback.IsAllocated())
 return retval;
 
-traceback_module.Reset(PyRefType::Owned, 
PyImport_ImportModule("traceback"));
-stringIO_module.Reset(PyRefType::Owned, PyImport_ImportModule("StringIO"));
 if (!traceback_module.IsAllocated() || !stringIO_module.IsAllocated())
 return retval;
 
-stringIO_builder.Reset(PyRefType::Owned, 
PyObject_GetAttrString(stringIO_module.get(), "StringIO"));
+auto stringIO_builder = 
stringIO_module.ResolveName("StringIO");
 if (!stringIO_builder.IsAllocated())
 return retval;
 
-stringIO_buffer.Reset(PyRefType::Owned, 
PyObject_CallObject(stringIO_builder.get(), nullptr));
+auto stringIO_buffer = stringIO_builder();
 if (!stringIO_buffer.IsAllocated())
 return retval;
 
-printTB.Reset(PyRefType::Owned, 
PyObject_GetAttrString(traceback_module.get(), "print_tb"));
+auto printTB = traceback_module.ResolveName("print_tb");
 if (!printTB.IsAllocated())
 return retval;
 
-printTB_args.Reset(PyRefType::Owned, Py_BuildValue("OOO", 
m_traceback.get(), Py_None, stringIO_buffer.get()));
-printTB_result.Reset(PyRefType::Owned, PyObject_CallObject(printTB.get(), 
printTB_args.get()));
-stringIO_getvalue.Reset(PyRefType::Owned, 
PyObject_GetAttrString(stringIO_buffer.get(), "getvalue"));
+auto printTB_result 

[Lldb-commits] [lldb] r253088 - Remove debugging code left in by accident.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Fri Nov 13 15:35:07 2015
New Revision: 253088

URL: http://llvm.org/viewvc/llvm-project?rev=253088=rev
Log:
Remove debugging code left in by accident.

Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp?rev=253088=253087=253088=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
Fri Nov 13 15:35:07 2015
@@ -146,7 +146,6 @@ PythonExceptionState::Format() const
 }
 else
 {
-__debugbreak();
 // Otherwise, append some information about why we were unable to
 // obtain the backtrace.
 PythonString bt_error = bt_error_state.GetValue().Str();
@@ -158,7 +157,6 @@ PythonExceptionState::Format() const
 std::string
 PythonExceptionState::ReadBacktrace() const
 {
-__debugbreak();
 std::string retval("backtrace unavailable");
 
 auto traceback_module = PythonModule::ImportModule("traceback");


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

[Lldb-commits] [lldb] r253093 - Upstream some data formatter related cleanups

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 15:55:41 2015
New Revision: 253093

URL: http://llvm.org/viewvc/llvm-project?rev=253093=rev
Log:
Upstream some data formatter related cleanups

Modified:
lldb/trunk/source/DataFormatters/FormattersHelpers.cpp

Modified: lldb/trunk/source/DataFormatters/FormattersHelpers.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/FormattersHelpers.cpp?rev=253093=253092=253093=diff
==
--- lldb/trunk/source/DataFormatters/FormattersHelpers.cpp (original)
+++ lldb/trunk/source/DataFormatters/FormattersHelpers.cpp Fri Nov 13 15:55:41 
2015
@@ -173,7 +173,10 @@ lldb_private::formatters::ExtractValueFr
 options.SetCoerceToId(false);
 options.SetUnwindOnError(true);
 options.SetKeepInMemory(true);
-
+options.SetLanguage(lldb::eLanguageTypeObjC_plus_plus);
+options.SetResultIsInternal(true);
+options.SetUseDynamic(lldb::eDynamicCanRunTarget);
+
 target->EvaluateExpression(expr.GetData(),
stack_frame,
result_sp,
@@ -233,10 +236,12 @@ lldb_private::formatters::CallSelectorOn
 return valobj_sp;
 if (!selector || !*selector)
 return valobj_sp;
-StreamString expr_path_stream;
-valobj.GetExpressionPath(expr_path_stream, false);
 StreamString expr;
-expr.Printf("(%s)[%s %s:%" PRId64 
"]",return_type,expr_path_stream.GetData(),selector,index);
+const char *colon = "";
+llvm::StringRef selector_sr(selector);
+if (selector_sr.back() != ':')
+colon = ":";
+expr.Printf("(%s)[(id)0x%" PRIx64 " %s%s%" PRId64 
"]",return_type,valobj.GetPointerValue(),selector,colon,index);
 ExecutionContext exe_ctx (valobj.GetExecutionContextRef());
 lldb::ValueObjectSP result_sp;
 Target* target = exe_ctx.GetTargetPtr();
@@ -248,6 +253,8 @@ lldb_private::formatters::CallSelectorOn
 options.SetCoerceToId(false);
 options.SetUnwindOnError(true);
 options.SetKeepInMemory(true);
+options.SetLanguage(lldb::eLanguageTypeObjC_plus_plus);
+options.SetResultIsInternal(true);
 options.SetUseDynamic(lldb::eDynamicCanRunTarget);
 
 target->EvaluateExpression(expr.GetData(),
@@ -270,10 +277,12 @@ lldb_private::formatters::CallSelectorOn
 return valobj_sp;
 if (!key || !*key)
 return valobj_sp;
-StreamString expr_path_stream;
-valobj.GetExpressionPath(expr_path_stream, false);
 StreamString expr;
-expr.Printf("(%s)[%s 
%s:%s]",return_type,expr_path_stream.GetData(),selector,key);
+const char *colon = "";
+llvm::StringRef selector_sr(selector);
+if (selector_sr.back() != ':')
+colon = ":";
+expr.Printf("(%s)[(id)0x%" PRIx64 " 
%s%s%s]",return_type,valobj.GetPointerValue(),selector,colon,key);
 ExecutionContext exe_ctx (valobj.GetExecutionContextRef());
 lldb::ValueObjectSP result_sp;
 Target* target = exe_ctx.GetTargetPtr();
@@ -285,6 +294,8 @@ lldb_private::formatters::CallSelectorOn
 options.SetCoerceToId(false);
 options.SetUnwindOnError(true);
 options.SetKeepInMemory(true);
+options.SetLanguage(lldb::eLanguageTypeObjC_plus_plus);
+options.SetResultIsInternal(true);
 options.SetUseDynamic(lldb::eDynamicCanRunTarget);
 
 target->EvaluateExpression(expr.GetData(),


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

[Lldb-commits] [lldb] r253089 - Fix indentation

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 15:37:47 2015
New Revision: 253089

URL: http://llvm.org/viewvc/llvm-project?rev=253089=rev
Log:
Fix indentation

Modified:
lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp

Modified: lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp?rev=253089=253088=253089=diff
==
--- lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp (original)
+++ lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp Fri Nov 13 
15:37:47 2015
@@ -19,30 +19,30 @@ using namespace lldb;
 using namespace lldb_private;
 
 DumpValueObjectOptions::DumpValueObjectOptions() :
-m_summary_sp(),
-m_root_valobj_name(),
-m_max_ptr_depth(PointerDepth{PointerDepth::Mode::Default,0}),
-m_decl_printing_helper(),
-m_use_synthetic(true),
-m_scope_already_checked(false),
-m_flat_output(false),
-m_ignore_cap(false),
-m_show_types(false),
-m_show_location(false),
-m_use_objc(false),
-m_hide_root_type(false),
-m_hide_name(false),
-m_hide_value(false),
-m_run_validator(false),
-m_use_type_display_name(true),
-m_allow_oneliner_mode(true),
-m_hide_pointer_value(false),
-m_reveal_empty_aggregates(true)
+m_summary_sp(),
+m_root_valobj_name(),
+m_max_ptr_depth(PointerDepth{PointerDepth::Mode::Default,0}),
+m_decl_printing_helper(),
+m_use_synthetic(true),
+m_scope_already_checked(false),
+m_flat_output(false),
+m_ignore_cap(false),
+m_show_types(false),
+m_show_location(false),
+m_use_objc(false),
+m_hide_root_type(false),
+m_hide_name(false),
+m_hide_value(false),
+m_run_validator(false),
+m_use_type_display_name(true),
+m_allow_oneliner_mode(true),
+m_hide_pointer_value(false),
+m_reveal_empty_aggregates(true)
 {}
 
 
 DumpValueObjectOptions::DumpValueObjectOptions (ValueObject& valobj) :
-DumpValueObjectOptions()
+DumpValueObjectOptions()
 {
 m_use_dynamic = valobj.GetDynamicValueType();
 m_use_synthetic = valobj.IsSynthetic();
@@ -242,4 +242,4 @@ DumpValueObjectOptions::SetRevealEmptyAg
 m_reveal_empty_aggregates = reveal;
 return *this;
 }
-
+


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

[Lldb-commits] [lldb] r253087 - Fix indentation

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 15:34:39 2015
New Revision: 253087

URL: http://llvm.org/viewvc/llvm-project?rev=253087=rev
Log:
Fix indentation

Modified:
lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h

Modified: lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h?rev=253087=253086=253087=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h Fri Nov 13 
15:34:39 2015
@@ -24,162 +24,162 @@
 
 namespace lldb_private {
 
-class DumpValueObjectOptions
+class DumpValueObjectOptions
+{
+public:
+struct PointerDepth
 {
-public:
-struct PointerDepth
+enum class Mode
 {
-enum class Mode
-{
-Always,
-Formatters,
-Default,
-Never
-} m_mode;
-uint32_t m_count;
-
-PointerDepth
-operator --() const
-{
-if (m_count > 0)
-return PointerDepth {m_mode,m_count-1};
-return PointerDepth {m_mode,m_count};
-}
-
-bool
-CanAllowExpansion () const;
-
-bool
-CanAllowExpansion (bool is_root,
-   TypeSummaryImpl* entry,
-   ValueObject *valobj,
-   const std::string& summary);
-};
+Always,
+Formatters,
+Default,
+Never
+} m_mode;
+uint32_t m_count;
 
-typedef std::function DeclPrintingHelper;
-
-static const DumpValueObjectOptions
-DefaultOptions()
+PointerDepth
+operator --() const
 {
-static DumpValueObjectOptions g_default_options;
-
-return g_default_options;
+if (m_count > 0)
+return PointerDepth {m_mode,m_count-1};
+return PointerDepth {m_mode,m_count};
 }
 
-DumpValueObjectOptions();
-
-DumpValueObjectOptions (const DumpValueObjectOptions& rhs) = default;
-
-DumpValueObjectOptions (ValueObject& valobj);
-
-DumpValueObjectOptions&
-SetMaximumPointerDepth(PointerDepth depth = 
{PointerDepth::Mode::Never,0});
-
-DumpValueObjectOptions&
-SetMaximumDepth(uint32_t depth = 0);
-
-DumpValueObjectOptions&
-SetDeclPrintingHelper(DeclPrintingHelper helper);
-
-DumpValueObjectOptions&
-SetShowTypes(bool show = false);
-
-DumpValueObjectOptions&
-SetShowLocation(bool show = false);
-
-DumpValueObjectOptions&
-SetUseObjectiveC(bool use = false);
-
-DumpValueObjectOptions&
-SetShowSummary(bool show = true);
-
-DumpValueObjectOptions&
-SetUseDynamicType(lldb::DynamicValueType dyn = lldb::eNoDynamicValues);
-
-DumpValueObjectOptions&
-SetUseSyntheticValue(bool use_synthetic = true);
-
-DumpValueObjectOptions&
-SetScopeChecked(bool check = true);
-
-DumpValueObjectOptions&
-SetFlatOutput(bool flat = false);
-
-DumpValueObjectOptions&
-SetOmitSummaryDepth(uint32_t depth = 0);
-
-DumpValueObjectOptions&
-SetIgnoreCap(bool ignore = false);
+bool
+CanAllowExpansion () const;
 
-DumpValueObjectOptions&
-SetRawDisplay();
-
-DumpValueObjectOptions&
-SetFormat (lldb::Format format = lldb::eFormatDefault);
-
-DumpValueObjectOptions&
-SetSummary (lldb::TypeSummaryImplSP summary = 
lldb::TypeSummaryImplSP());
-
-DumpValueObjectOptions&
-SetRootValueObjectName(const char* name = nullptr);
-
-DumpValueObjectOptions&
-SetHideRootType (bool hide_root_type = false);
-
-DumpValueObjectOptions&
-SetHideName (bool hide_name = false);
-
-DumpValueObjectOptions&
-SetHideValue (bool hide_value = false);
-
-DumpValueObjectOptions&
-SetHidePointerValue (bool hide = false);
-
-DumpValueObjectOptions&
-SetVariableFormatDisplayLanguage (lldb::LanguageType lang = 
lldb::eLanguageTypeUnknown);
-
-DumpValueObjectOptions&
-SetRunValidator (bool run = 

Re: [Lldb-commits] [lldb] r253086 - Add a null check against the ThreadPlan

[Jim Ingham via lldb-commits]

Thanks.  When I first did the thread plan stuff I wasn't sure whether I would 
have a use for an empty plan stack, so I didn't rigorously go through and 
assert everywhere that might happen.  I had some idea for using an empty plan 
stack which was apparently so kooky that not only did I never implement it but 
I can't even reconstruct what it was now.  Anyway, one of those cleanup 
activities that you never seem to get to has been to go back and assert in all 
the places that might end up making the plan stack NULL (except for the bit 
where we empty out the plan stack & then prime it with the ThreadPlanNull which 
we use as an overt signal that the thread is defunct.

Jim

> On Nov 13, 2015, at 1:52 PM, Zachary Turner  wrote:
> 
> I'll change it to an assert and next time it happens I'll dig a little more.  
> I've only seen this on about 1 or 2 out of 100 runs of the test suite so I 
> don't know how it happens.
> 
> On Fri, Nov 13, 2015 at 1:44 PM Jim Ingham  wrote:
> GetCurrentPlan should never return NULL.  The Thread constructor pushes the 
> Base thread plan onto the stack, and pop won't remove the Base plan.  When we 
> destroy the thread (in ThreadDestroy) we clear the plan stack and then push a 
> ThreadPlanNull onto the plan stack.  So if you are seeing a GetCurrentPlan 
> returning NULL that means somebody is using it while it is in the process of 
> being created or destroyed.  The former shouldn't be possible, so you must be 
> accessing it while it is in mid-destroy.
> 
> I'd rather not put more code in various places that checks for things that 
> should never be true, or if you are doing this check you should assert so we 
> can figure out how this is happening.
> 
> Note, ThreadDestroy doesn't lock itself against uses of the thread.  That 
> hasn't been necessary but if you are seeing crashes here, it might be worth 
> doing that.
> 
> Jim
> 
> 
> > On Nov 13, 2015, at 1:28 PM, Zachary Turner via lldb-commits 
> >  wrote:
> >
> > Author: zturner
> > Date: Fri Nov 13 15:28:53 2015
> > New Revision: 253086
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=253086=rev
> > Log:
> > Add a null check against the ThreadPlan
> >
> > I'm seeing some cases where the ThreadPlan is null.  It could
> > be a sign of a valid race condition, but at least we shouldn't
> > crash.
> >
> > Modified:
> >lldb/trunk/source/Target/ThreadList.cpp
> >
> > Modified: lldb/trunk/source/Target/ThreadList.cpp
> > URL: 
> > http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadList.cpp?rev=253086=253085=253086=diff
> > ==
> > --- lldb/trunk/source/Target/ThreadList.cpp (original)
> > +++ lldb/trunk/source/Target/ThreadList.cpp Fri Nov 13 15:28:53 2015
> > @@ -538,7 +538,7 @@ ThreadList::WillResume ()
> >
> > for (pos = m_threads.begin(); pos != end; ++pos)
> > {
> > -if ((*pos)->GetResumeState() != eStateSuspended &&
> > +if ((*pos)->GetResumeState() != eStateSuspended && 
> > (*pos)->GetCurrentPlan() &&
> >  (*pos)->GetCurrentPlan()->StopOthers())
> > {
> > if ((*pos)->IsOperatingSystemPluginThread() && 
> > !(*pos)->GetBackingThread())
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 

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

Re: [Lldb-commits] [PATCH] D14631: [dwarf] Handle DWARF forms for address other than DW_FORM_GNU_addr_index and DW_FORM_addr.

[Dawn Perchik via lldb-commits]

dawn abandoned this revision.
dawn added a comment.

> If you have a compiler that is actually emitting addresses incorrectly using 
> DW_FORM_data* when the values are not offsets, the compiler should be fixed.


Thanks Greg!  In this case it indeed appears to be a compiler bug (we are 
getting relocations emitted for them).  But I like your suggestion of how to 
rewrite the Address function.  If any valid cases arise, I will use your idea, 
but instead create an overload which takes a parameter (that way only the DWARF 
contexts in which addresses are represented using data4/data8 will have to pay 
the cost of the added code).


Repository:
  rL LLVM

http://reviews.llvm.org/D14631



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

Re: [Lldb-commits] [lldb] r253086 - Add a null check against the ThreadPlan

[Zachary Turner via lldb-commits]

I'll change it to an assert and next time it happens I'll dig a little
more.  I've only seen this on about 1 or 2 out of 100 runs of the test
suite so I don't know how it happens.

On Fri, Nov 13, 2015 at 1:44 PM Jim Ingham  wrote:

> GetCurrentPlan should never return NULL.  The Thread constructor pushes
> the Base thread plan onto the stack, and pop won't remove the Base plan.
> When we destroy the thread (in ThreadDestroy) we clear the plan stack and
> then push a ThreadPlanNull onto the plan stack.  So if you are seeing a
> GetCurrentPlan returning NULL that means somebody is using it while it is
> in the process of being created or destroyed.  The former shouldn't be
> possible, so you must be accessing it while it is in mid-destroy.
>
> I'd rather not put more code in various places that checks for things that
> should never be true, or if you are doing this check you should assert so
> we can figure out how this is happening.
>
> Note, ThreadDestroy doesn't lock itself against uses of the thread.  That
> hasn't been necessary but if you are seeing crashes here, it might be worth
> doing that.
>
> Jim
>
>
> > On Nov 13, 2015, at 1:28 PM, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> >
> > Author: zturner
> > Date: Fri Nov 13 15:28:53 2015
> > New Revision: 253086
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=253086=rev
> > Log:
> > Add a null check against the ThreadPlan
> >
> > I'm seeing some cases where the ThreadPlan is null.  It could
> > be a sign of a valid race condition, but at least we shouldn't
> > crash.
> >
> > Modified:
> >lldb/trunk/source/Target/ThreadList.cpp
> >
> > Modified: lldb/trunk/source/Target/ThreadList.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadList.cpp?rev=253086=253085=253086=diff
> >
> ==
> > --- lldb/trunk/source/Target/ThreadList.cpp (original)
> > +++ lldb/trunk/source/Target/ThreadList.cpp Fri Nov 13 15:28:53 2015
> > @@ -538,7 +538,7 @@ ThreadList::WillResume ()
> >
> > for (pos = m_threads.begin(); pos != end; ++pos)
> > {
> > -if ((*pos)->GetResumeState() != eStateSuspended &&
> > +if ((*pos)->GetResumeState() != eStateSuspended &&
> (*pos)->GetCurrentPlan() &&
> >  (*pos)->GetCurrentPlan()->StopOthers())
> > {
> > if ((*pos)->IsOperatingSystemPluginThread() &&
> !(*pos)->GetBackingThread())
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r253101 - Fixed a testcase problem where disassembly would fail for nameless functions.

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Nov 13 17:00:33 2015
New Revision: 253101

URL: http://llvm.org/viewvc/llvm-project?rev=253101=rev
Log:
Fixed a testcase problem where disassembly would fail for nameless functions.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py?rev=253101=253100=253101=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py 
Fri Nov 13 17:00:33 2015
@@ -56,7 +56,8 @@ class StdCXXDisassembleTestCase(TestBase
 for i in range(depth - 1):
 frame = thread.GetFrameAtIndex(i)
 function = frame.GetFunction()
-self.runCmd("disassemble -n '%s'" % function.GetName())
+if function.GetName():
+self.runCmd("disassemble -n '%s'" % function.GetName())
 
 lib_stdcxx = "FAILHORRIBLYHERE"
 # Iterate through the available modules, looking for stdc++ library...


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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

Ha, ha, that was cute.  The test was cleverly(?) getting the consecutive 
addresses to break at by setting the first breakpoint, running to it once, 
step-i-ing, then using that pc value to set the breakpoint on the consecutive 
instruction, then running again.  Unfortunately, OS X by default uses some 
address shuffling, so the by address breakpoint was no longer next to the 
symbolic address of the original breakpoint.

I fixed this by changing the test to get the instruction list and set a 
breakpoint on the next instruction, which avoids all this todo. Note, that fix 
relies on the place where we break not being a branch, but the code is simple 
addition, so it should not branch around anything. 

Jim


> On Nov 13, 2015, at 10:39 AM, Jim Ingham  wrote:
> 
> Huh, I'll go check out that test.  The basic functionality works on OS X:
> 
> (lldb) b s -n main
> Breakpoint 1: 21 locations.
> (lldb) run
> Process 58218 launched: 'Sketch' (x86_64)
> Process 58218 stopped
> * thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 1.1
>frame #0: 0x000100018dc7 Sketch`main at SKTMain.m:17
>   14  }
>   15  
>   16  int main(int argc, const char *argv[]) {
> -> 17 NSLog (@"Added for testing rebuilds.");
>   18  bool got_a_bool = NO;
>   19  NSString *text_to_use = @"٢٠ شباط";
>   20  
> (lldb) dis -p
> Sketch`main:
> ->  0x100018dc7 <+55>: movq   %rax, %rdi
>0x100018dca <+58>: movb   $0x0, %al
>0x100018dcc <+60>: callq  0x10001d21a   ; symbol stub for: 
> NSLog
>0x100018dd1 <+65>: leaq   0xa530(%rip), %rcx; 
> @Sketch.__TEXT.__ustring + 0
> (lldb) b s -a 0x100018dca
> Breakpoint 2: where = Sketch`main + 58 at SKTMain.m:17, address = 
> 0x000100018dca
> (lldb) c
> Process 58218 resuming
> Process 58218 stopped
> * thread #1: tid = 0xba0159, function: main , stop reason = breakpoint 2.1
>frame #0: 0x000100018dca Sketch`main at SKTMain.m:17
>   14  }
>   15  
>   16  int main(int argc, const char *argv[]) {
> -> 17 NSLog (@"Added for testing rebuilds.");
>   18  bool got_a_bool = NO;
>   19  NSString *text_to_use = @"٢٠ شباط";
>   20  
> 
> Jim
> 
>> On Nov 13, 2015, at 2:47 AM, Tamas Berghammer  wrote:
>> 
>> We already have a test for it in TestConsecutiveBreakpoints.py what is 
>> xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As 
>> far as I see from the build bots the test is also failing on OSX, but it 
>> might fail from a different reason then on Linux/Windows.
>> 
>> On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits 
>>  wrote:
>> Thanks!  Do you think you could add a test that does specifically that?  Set 
>> two breakpoints back to back, even in the same function, ane ensure that the 
>> second one gets hit.  If your theory is right this test will fail on Windows 
>> and Linux (and then we'll have to xfail it) but at least we'll have a test 
>> that's isolated to the root of the problem.
>> 
>> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham  wrote:
>> Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on 
>> Linux for me, but I don't have a windows machine handy to test.
>> 
>> What was happening is that originally lldb had a bug where if you were 
>> stopped on a breakpoint and then the next instruction also had a breakpoint, 
>> the plan that was stepping over the breakpoint would see a stop reason of 
>> "trace" so it would think it knew why it stopped and would auto-continue, 
>> since that's what you do when you are doing "step over a breakpoint and keep 
>> going."
>> 
>> I fixed this by having the lower layers of the process plugin correct the 
>> stop reason from trace to breakpoint when a trace ended up on another 
>> breakpoint, but apparently Linux and Windows don't have this fix.  That was 
>> done a while ago, so maybe they weren't around then, I have to think about 
>> that...
>> 
>> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we only 
>> needed to go one instruction, it wouldn't do it with a breakpoint, but just 
>> stepi.  I didn't preserve that in the change I made, so we got into trouble. 
>>  So for now I just put that short-cut back.
>> 
>> I wondered how this managed to cause so many Linux failures, but the OS X 
>> testsuite was clean...
>> 
>> Jim
>> 
>> 
>> 
>>> On Nov 12, 2015, at 4:57 PM, Zachary Turner  wrote:
>>> 
>>> Ahh, seems it wasn't just Windows that was affected by this.  Makes me feel 
>>> a little better :)
>>> 
>>> Posting the link to the buildbot failures here so that Jim can get full 
>>> logs if it helps.
>>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
>>> 
>>> On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
>>> I 

Re: [Lldb-commits] [lldb] r253086 - Add a null check against the ThreadPlan

[Jim Ingham via lldb-commits]

GetCurrentPlan should never return NULL.  The Thread constructor pushes the 
Base thread plan onto the stack, and pop won't remove the Base plan.  When we 
destroy the thread (in ThreadDestroy) we clear the plan stack and then push a 
ThreadPlanNull onto the plan stack.  So if you are seeing a GetCurrentPlan 
returning NULL that means somebody is using it while it is in the process of 
being created or destroyed.  The former shouldn't be possible, so you must be 
accessing it while it is in mid-destroy.

I'd rather not put more code in various places that checks for things that 
should never be true, or if you are doing this check you should assert so we 
can figure out how this is happening.

Note, ThreadDestroy doesn't lock itself against uses of the thread.  That 
hasn't been necessary but if you are seeing crashes here, it might be worth 
doing that.

Jim


> On Nov 13, 2015, at 1:28 PM, Zachary Turner via lldb-commits 
>  wrote:
> 
> Author: zturner
> Date: Fri Nov 13 15:28:53 2015
> New Revision: 253086
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=253086=rev
> Log:
> Add a null check against the ThreadPlan
> 
> I'm seeing some cases where the ThreadPlan is null.  It could
> be a sign of a valid race condition, but at least we shouldn't
> crash.
> 
> Modified:
>lldb/trunk/source/Target/ThreadList.cpp
> 
> Modified: lldb/trunk/source/Target/ThreadList.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadList.cpp?rev=253086=253085=253086=diff
> ==
> --- lldb/trunk/source/Target/ThreadList.cpp (original)
> +++ lldb/trunk/source/Target/ThreadList.cpp Fri Nov 13 15:28:53 2015
> @@ -538,7 +538,7 @@ ThreadList::WillResume ()
> 
> for (pos = m_threads.begin(); pos != end; ++pos)
> {
> -if ((*pos)->GetResumeState() != eStateSuspended &&
> +if ((*pos)->GetResumeState() != eStateSuspended && 
> (*pos)->GetCurrentPlan() &&
>  (*pos)->GetCurrentPlan()->StopOthers())
> {
> if ((*pos)->IsOperatingSystemPluginThread() && 
> !(*pos)->GetBackingThread())
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [PATCH] D14673: Fix buildbot breakage after r253106

[Ying Chen via lldb-commits]

chying created this revision.
chying added a reviewer: jingham.
chying added a subscriber: lldb-commits.

- expectedFailureAll takes single compiler name rather than compiler list 
because it also takes version which only apply to single compiler
- Don't try to access self.debug_info if debug_info is None
- Link to broken build, 
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8441

http://reviews.llvm.org/D14673

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

Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -636,8 +636,8 @@
 def expectedFailureAll(bugnumber=None, oslist=None, compiler=None, 
compiler_version=None, archs=None, triple=None, debug_info=None):
 def fn(self):
 os_list_passes = check_list_or_lambda(oslist, self.getPlatform())
-compiler_passes = check_list_or_lambda(compiler, self.getCompiler()) 
and self.expectedCompilerVersion(compiler_version)
-debug_info_passes = check_list_or_lambda(debug_info, self.debug_info)
+compiler_passes = compiler is None or 
(check_list_or_lambda(self.getCompiler(), compiler) and 
self.expectedCompilerVersion(compiler_version))
+debug_info_passes = debug_info is None or 
check_list_or_lambda(debug_info, self.debug_info)
 
 return (os_list_passes  and
 compiler_passes and


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -636,8 +636,8 @@
 def expectedFailureAll(bugnumber=None, oslist=None, compiler=None, compiler_version=None, archs=None, triple=None, debug_info=None):
 def fn(self):
 os_list_passes = check_list_or_lambda(oslist, self.getPlatform())
-compiler_passes = check_list_or_lambda(compiler, self.getCompiler()) and self.expectedCompilerVersion(compiler_version)
-debug_info_passes = check_list_or_lambda(debug_info, self.debug_info)
+compiler_passes = compiler is None or (check_list_or_lambda(self.getCompiler(), compiler) and self.expectedCompilerVersion(compiler_version))
+debug_info_passes = debug_info is None or check_list_or_lambda(debug_info, self.debug_info)
 
 return (os_list_passes  and
 compiler_passes and
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r253106 - Add a "not_in()" function you can apply to the list type arguments to expectedFailureAll to reverse

[Jim Ingham via lldb-commits]

Author: jingham
Date: Fri Nov 13 18:20:33 2015
New Revision: 253106

URL: http://llvm.org/viewvc/llvm-project?rev=253106=rev
Log:
Add a "not_in()" function you can apply to the list type arguments to 
expectedFailureAll to reverse
the sense of the test.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py?rev=253106=253105=253106=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
 Fri Nov 13 18:20:33 2015
@@ -15,7 +15,7 @@ class ConsecutiveBreakpoitsTestCase(Test
 
 mydir = TestBase.compute_mydir(__file__)
 
-@unittest2.expectedFailure("llvm.org/pr23478")
+@expectedFailureAll("llvm.org/pr23478", oslist = not_in(["macosx"]))
 def test (self):
 self.build ()
 self.consecutive_breakpoints_tests()

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=253106=253105=253106=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Fri Nov 13 18:20:33 
2015
@@ -620,13 +620,30 @@ def expectedFailure(expected_fn, bugnumb
 # @expectedFailureAll, xfail for all platform/compiler/arch,
 # @expectedFailureAll(compiler='gcc'), xfail for gcc on all 
platform/architecture
 # @expectedFailureAll(bugnumber, ["linux"], "gcc", ['>=', '4.9'], ['i386']), 
xfail for gcc>=4.9 on linux with i386
+
+# You can also pass not_in(list) to reverse the sense of the test for the 
arguments that
+# are simple lists, namely oslist, compiler and debug_info.
+ 
+def not_in (iterable):
+return lambda x : x not in iterable
+
+def check_list_or_lambda (list_or_lambda, value):
+if six.callable(list_or_lambda):
+return list_or_lambda(value)
+else:
+return list_or_lambda is None or value in list_or_lambda
+
 def expectedFailureAll(bugnumber=None, oslist=None, compiler=None, 
compiler_version=None, archs=None, triple=None, debug_info=None):
 def fn(self):
-return ((oslist is None or self.getPlatform() in oslist) and
-(compiler is None or (compiler in self.getCompiler() and 
self.expectedCompilerVersion(compiler_version))) and
+os_list_passes = check_list_or_lambda(oslist, self.getPlatform())
+compiler_passes = check_list_or_lambda(compiler, self.getCompiler()) 
and self.expectedCompilerVersion(compiler_version)
+debug_info_passes = check_list_or_lambda(debug_info, self.debug_info)
+
+return (os_list_passes  and
+compiler_passes and
 self.expectedArch(archs) and
 (triple is None or re.match(triple, 
lldb.DBG.GetSelectedPlatform().GetTriple())) and
-(debug_info is None or self.debug_info in debug_info))
+debug_info_passes)
 return expectedFailure(fn, bugnumber)
 
 def expectedFailureDwarf(bugnumber=None):


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

[Lldb-commits] [lldb] r253111 - Add a few useful accessors on the data formatters containers

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 18:58:37 2015
New Revision: 253111

URL: http://llvm.org/viewvc/llvm-project?rev=253111=rev
Log:
Add a few useful accessors on the data formatters containers

Modified:
lldb/trunk/include/lldb/DataFormatters/TypeCategory.h

Modified: lldb/trunk/include/lldb/DataFormatters/TypeCategory.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/TypeCategory.h?rev=253111=253110=253111=diff
==
--- lldb/trunk/include/lldb/DataFormatters/TypeCategory.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/TypeCategory.h Fri Nov 13 18:58:37 
2015
@@ -64,6 +64,20 @@ namespace lldb_private {
 return m_regex_sp;
 }
 
+void
+LoopThrough (typename ExactMatchContainer::CallbackType exact_callback,
+ typename RegexMatchContainer::CallbackType regex_callback)
+{
+GetExactMatch()->LoopThrough(exact_callback);
+GetRegexMatch()->LoopThrough(regex_callback);
+}
+
+uint32_t
+GetCount ()
+{
+return GetExactMatch()->GetCount() + GetRegexMatch()->GetCount();
+}
+
 private:
 ExactMatchContainerSP m_exact_sp;
 RegexMatchContainerSP m_regex_sp;
@@ -117,6 +131,12 @@ namespace lldb_private {
 return m_format_cont.GetRegexMatch();
 }
 
+FormatContainer&
+GetFormatContainer ()
+{
+return m_format_cont;
+}
+
 SummaryContainerSP
 GetTypeSummariesContainer ()
 {
@@ -129,6 +149,12 @@ namespace lldb_private {
 return m_summary_cont.GetRegexMatch();
 }
 
+SummaryContainer&
+GetSummaryContainer ()
+{
+return m_summary_cont;
+}
+
 FilterContainerSP
 GetTypeFiltersContainer ()
 {
@@ -140,6 +166,12 @@ namespace lldb_private {
 {
 return m_filter_cont.GetRegexMatch();
 }
+
+FilterContainer&
+GetFilterContainer ()
+{
+return m_filter_cont;
+}
 
 FormatContainer::MapValueType
 GetFormatForType (lldb::TypeNameSpecifierImplSP type_sp);
@@ -189,6 +221,12 @@ namespace lldb_private {
 return m_synth_cont.GetRegexMatch();
 }
 
+SynthContainer&
+GetSyntheticsContainer ()
+{
+return m_synth_cont;
+}
+
 SynthContainer::MapValueType
 GetSyntheticAtIndex (size_t index);
 


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

[Lldb-commits] [lldb] r253110 - Minor cleanup to the type format list command

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 18:58:21 2015
New Revision: 253110

URL: http://llvm.org/viewvc/llvm-project?rev=253110=rev
Log:
Minor cleanup to the type format list command

Modified:
lldb/trunk/source/Commands/CommandObjectType.cpp

Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=253110=253109=253110=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Fri Nov 13 18:58:21 2015
@@ -1372,9 +1372,9 @@ private:
 
 
cate->GetTypeFormatsContainer()->LoopThrough(CommandObjectTypeFormatList_LoopCallback,
 param_vp);
 
-if (cate->GetRegexTypeSummariesContainer()->GetCount() > 0)
+if (cate->GetRegexTypeFormatsContainer()->GetCount() > 0)
 {
-result->GetOutputStream().Printf("Regex-based summaries 
(slower):\n");
+result->GetOutputStream().Printf("Regex-based formats 
(slower):\n");
 
cate->GetRegexTypeFormatsContainer()->LoopThrough(CommandObjectTypeRXFormatList_LoopCallback,
 param_vp);
 }
 return true;


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

[Lldb-commits] [lldb] r253112 - Always initialize expression variables' flags field.

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Fri Nov 13 19:05:33 2015
New Revision: 253112

URL: http://llvm.org/viewvc/llvm-project?rev=253112=rev
Log:
Always initialize expression variables' flags field.

Modified:
lldb/trunk/include/lldb/Expression/ExpressionVariable.h

Modified: lldb/trunk/include/lldb/Expression/ExpressionVariable.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionVariable.h?rev=253112=253111=253112=diff
==
--- lldb/trunk/include/lldb/Expression/ExpressionVariable.h (original)
+++ lldb/trunk/include/lldb/Expression/ExpressionVariable.h Fri Nov 13 19:05:33 
2015
@@ -43,6 +43,7 @@ public:
 LLVMCastKind getKind() const { return m_kind; }
 
 ExpressionVariable(LLVMCastKind kind) :
+m_flags(0),
 m_kind(kind)
 {
 }


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

Re: [Lldb-commits] [PATCH] D14673: Fix buildbot breakage after r253106

[Zachary Turner via lldb-commits]

zturner added a subscriber: zturner.
zturner added a comment.

I think the `is None` check should go back inside the `check_list_or_lambda` 
function.  Bringing it outside the function looks identical to me.  If `None` 
is passed to the function, the `callable()` check will fail, and then the 
`else` branch will return true.

Also the compiler check is wrong currently because of the grouping of 
parentheses.  For example, if someone passes `compiler=None` and 
`compiler_version=3.7`, then check would succeed no matter what the compiler 
version was.


http://reviews.llvm.org/D14673



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

Re: [Lldb-commits] [lldb] r253106 - Add a "not_in()" function you can apply to the list type arguments to expectedFailureAll to reverse

[Ying Chen via lldb-commits]

Hello Jim,

It seems this patch breaks the tests that are decorated by
expectedFailureAll.
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8441

I had a patch to fix it, could you help to review?
http://reviews.llvm.org/D14673

Thanks,
Ying

On Fri, Nov 13, 2015 at 4:20 PM, Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jingham
> Date: Fri Nov 13 18:20:33 2015
> New Revision: 253106
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253106=rev
> Log:
> Add a "not_in()" function you can apply to the list type arguments to
> expectedFailureAll to reverse
> the sense of the test.
>
> Modified:
>
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
> lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py?rev=253106=253105=253106=diff
>
> ==
> ---
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
> (original)
> +++
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
> Fri Nov 13 18:20:33 2015
> @@ -15,7 +15,7 @@ class ConsecutiveBreakpoitsTestCase(Test
>
>  mydir = TestBase.compute_mydir(__file__)
>
> -@unittest2.expectedFailure("llvm.org/pr23478")
> +@expectedFailureAll("llvm.org/pr23478", oslist = not_in(["macosx"]))
>  def test (self):
>  self.build ()
>  self.consecutive_breakpoints_tests()
>
> 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=253106=253105=253106=diff
>
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Fri Nov 13
> 18:20:33 2015
> @@ -620,13 +620,30 @@ def expectedFailure(expected_fn, bugnumb
>  # @expectedFailureAll, xfail for all platform/compiler/arch,
>  # @expectedFailureAll(compiler='gcc'), xfail for gcc on all
> platform/architecture
>  # @expectedFailureAll(bugnumber, ["linux"], "gcc", ['>=', '4.9'],
> ['i386']), xfail for gcc>=4.9 on linux with i386
> +
> +# You can also pass not_in(list) to reverse the sense of the test for the
> arguments that
> +# are simple lists, namely oslist, compiler and debug_info.
> +
> +def not_in (iterable):
> +return lambda x : x not in iterable
> +
> +def check_list_or_lambda (list_or_lambda, value):
> +if six.callable(list_or_lambda):
> +return list_or_lambda(value)
> +else:
> +return list_or_lambda is None or value in list_or_lambda
> +
>  def expectedFailureAll(bugnumber=None, oslist=None, compiler=None,
> compiler_version=None, archs=None, triple=None, debug_info=None):
>  def fn(self):
> -return ((oslist is None or self.getPlatform() in oslist) and
> -(compiler is None or (compiler in self.getCompiler() and
> self.expectedCompilerVersion(compiler_version))) and
> +os_list_passes = check_list_or_lambda(oslist, self.getPlatform())
> +compiler_passes = check_list_or_lambda(compiler,
> self.getCompiler()) and self.expectedCompilerVersion(compiler_version)
> +debug_info_passes = check_list_or_lambda(debug_info,
> self.debug_info)
> +
> +return (os_list_passes  and
> +compiler_passes and
>  self.expectedArch(archs) and
>  (triple is None or re.match(triple,
> lldb.DBG.GetSelectedPlatform().GetTriple())) and
> -(debug_info is None or self.debug_info in debug_info))
> +debug_info_passes)
>  return expectedFailure(fn, bugnumber)
>
>  def expectedFailureDwarf(bugnumber=None):
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r253125 - The existing logic to loop over formatters is very pre-C++11, using void* batons, and function pointers, and raw memory allocations instead of safer more modern constru

[Enrico Granata via lldb-commits]

Author: enrico
Date: Fri Nov 13 23:44:23 2015
New Revision: 253125

URL: http://llvm.org/viewvc/llvm-project?rev=253125=rev
Log:
The existing logic to loop over formatters is very pre-C++11, using void* 
batons, and function pointers, and raw memory allocations instead of safer more 
modern constructs

This is a first pass at a cleanup of that code, modernizing the "type X clear" 
commands, and providing the basic infrastructure I plan to use all over
More cleanup will come over the next few days


Modified:
lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
lldb/trunk/include/lldb/DataFormatters/FormatManager.h
lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
lldb/trunk/include/lldb/DataFormatters/TypeCategory.h
lldb/trunk/include/lldb/DataFormatters/TypeCategoryMap.h
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/DataFormatters/DataVisualization.cpp
lldb/trunk/source/DataFormatters/FormatManager.cpp
lldb/trunk/source/DataFormatters/TypeCategoryMap.cpp

Modified: lldb/trunk/include/lldb/DataFormatters/DataVisualization.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DataVisualization.h?rev=253125=253124=253125=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DataVisualization.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DataVisualization.h Fri Nov 13 
23:44:23 2015
@@ -160,6 +160,9 @@ public:
 static void
 LoopThrough (FormatManager::CategoryCallback callback, void* 
callback_baton);
 
+static void
+ForEach (TypeCategoryMap::ForEachCallback callback);
+
 static uint32_t
 GetCount ();
 

Modified: lldb/trunk/include/lldb/DataFormatters/FormatManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormatManager.h?rev=253125=253124=253125=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormatManager.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormatManager.h Fri Nov 13 23:44:23 
2015
@@ -142,6 +142,9 @@ public:
 void
 LoopThroughCategories (CategoryCallback callback, void* param);
 
+void
+ForEachCategory (TypeCategoryMap::ForEachCallback callback);
+
 lldb::TypeCategoryImplSP
 GetCategory(const char* category_name = nullptr,
 bool can_create = true)

Modified: lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h?rev=253125=253124=253125=diff
==
--- lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/FormattersContainer.h Fri Nov 13 
23:44:23 2015
@@ -82,6 +82,8 @@ public:
 typedef typename MapType::iterator MapIterator;
 typedef std::function CallbackType;
 
+typedef std::function ForEachCallback;
+
 FormatMap(IFormatChangeListener* lst) :
 m_map(),
 m_map_mutex(Mutex::eMutexTypeRecursive),
@@ -154,6 +156,22 @@ public:
 }
 }
 
+void
+ForEach (ForEachCallback callback)
+{
+if (callback)
+{
+Mutex::Locker locker(m_map_mutex);
+MapIterator pos, end = m_map.end();
+for (pos = m_map.begin(); pos != end; pos++)
+{
+KeyType type = pos->first;
+if (!callback(type, pos->second))
+break;
+}
+}
+}
+
 uint32_t
 GetCount ()
 {
@@ -225,6 +243,7 @@ public:
 typedef typename MapType::key_type MapKeyType;
 typedef typename MapType::mapped_type MapValueType;
 typedef typename BackEndType::CallbackType CallbackType;
+typedef typename BackEndType::ForEachCallback ForEachCallback;
 typedef typename std::shared_ptr > 
SharedPointer;
 
 friend class TypeCategoryImpl;
@@ -302,6 +321,12 @@ public:
 m_format_map.LoopThrough(callback,param);
 }
 
+void
+ForEach (ForEachCallback callback)
+{
+m_format_map.ForEach(callback);
+}
+
 uint32_t
 GetCount ()
 {

Modified: lldb/trunk/include/lldb/DataFormatters/TypeCategory.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/TypeCategory.h?rev=253125=253124=253125=diff
==
--- lldb/trunk/include/lldb/DataFormatters/TypeCategory.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/TypeCategory.h Fri Nov 13 23:44:23 
2015
@@ -42,6 +42,9 @@ namespace lldb_private {
 typedef typename 

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Tamas Berghammer via lldb-commits]

We already have a test for it in TestConsecutiveBreakpoints.py what is
xfail-ed on all platform because of this bug (http://llvm.org/pr23478). As
far as I see from the build bots the test is also failing on OSX, but it
might fail from a different reason then on Linux/Windows.

On Fri, Nov 13, 2015 at 4:10 AM Zachary Turner via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Thanks!  Do you think you could add a test that does specifically that?
> Set two breakpoints back to back, even in the same function, ane ensure
> that the second one gets hit.  If your theory is right this test will fail
> on Windows and Linux (and then we'll have to xfail it) but at least we'll
> have a test that's isolated to the root of the problem.
>
> On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham  wrote:
>
>> Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on
>> Linux for me, but I don't have a windows machine handy to test.
>>
>> What was happening is that originally lldb had a bug where if you were
>> stopped on a breakpoint and then the next instruction also had a
>> breakpoint, the plan that was stepping over the breakpoint would see a stop
>> reason of "trace" so it would think it knew why it stopped and would
>> auto-continue, since that's what you do when you are doing "step over a
>> breakpoint and keep going."
>>
>> I fixed this by having the lower layers of the process plugin correct the
>> stop reason from trace to breakpoint when a trace ended up on another
>> breakpoint, but apparently Linux and Windows don't have this fix.  That was
>> done a while ago, so maybe they weren't around then, I have to think about
>> that...
>>
>> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we
>> only needed to go one instruction, it wouldn't do it with a breakpoint, but
>> just stepi.  I didn't preserve that in the change I made, so we got into
>> trouble.  So for now I just put that short-cut back.
>>
>> I wondered how this managed to cause so many Linux failures, but the OS X
>> testsuite was clean...
>>
>> Jim
>>
>>
>>
>> > On Nov 12, 2015, at 4:57 PM, Zachary Turner  wrote:
>> >
>> > Ahh, seems it wasn't just Windows that was affected by this.  Makes me
>> feel a little better :)
>> >
>> > Posting the link to the buildbot failures here so that Jim can get full
>> logs if it helps.
>> >
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
>> >
>> > On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
>> > I reverted this patch for now.
>> > Please resubmit if you have a fix.
>> >
>> > Thanks,
>> > Ying
>> >
>> > On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>> > If you can debug a failing case, and do whatever step operation got you
>> to the wrong place, then run up to that step, and do:
>> >
>> > (lldb) log enable -f  lldb step
>> >
>> > and then do the step, then send me that log plus the disassembly for
>> the function you were stepping in and the output of:
>> >
>> > (lldb) image dump line-table 
>> >
>> > for the source file you were stepping in.
>> >
>> > I should be able to see from there why we were stepping to the wrong
>> place.
>> >
>> > Jim
>> >
>> > > On Nov 12, 2015, at 4:03 PM, Zachary Turner 
>> wrote:
>> > >
>> > > The error messages are always different because the error message is
>> printed by the test.  I'm going to try to load up the executable for
>> TestStepNoDebug in the debugger and get a disassembly and do the step
>> > >
>> > > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
>> > > Is the line they stepped to - instead of the expected line - always
>> line 0?
>> > >
>> > > Jim
>> > >
>> > > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
>> wrote:
>> > > >
>> > > > Hi Jim,
>> > > >
>> > > > This breaks about 12 tests on Windows.  The patch looks simple, but
>> this isn't really my area, is there anything I can give you to help
>> diagnose what might be wrong?  The following tests fail:
>> > > >
>> > > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 

Re: [Lldb-commits] [PATCH] D14226: Fix to solve Bug 23139 & Bug 23560

[Abhishek via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL253026: Fix to solve Bug 23139 & Bug 23560 (authored by 
Abhishek).

Changed prior to commit:
  http://reviews.llvm.org/D14226?vs=40014=40127#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14226

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
  lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/embedded_interpreter/TestConvenienceVariables.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/read/TestMemoryRead.py
  lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
  lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
  lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
  lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h

Index: lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
===
--- lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
+++ lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
@@ -136,6 +136,15 @@
  
 std::vector m_user_supplied_trap_handler_functions;
 
+//-
+// Check if Full UnwindPlan of First frame is valid or not.
+// If not then try Fallback UnwindPlan of the frame. If Fallback
+// UnwindPlan succeeds then update the Full UnwindPlan with the
+// Fallback UnwindPlan.
+//-
+void
+UpdateUnwindPlanForFirstFrameIfInvalid (ABI* abi);
+
 CursorSP
 GetOneMoreFrame (ABI* abi);
 
Index: lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
===
--- lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
+++ lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
@@ -86,6 +86,9 @@
 if (m_frames.size() > 0)
 return true;
 
+ProcessSP process_sp (m_thread.GetProcess());
+ABI *abi = process_sp ? process_sp->GetABI().get() : NULL;
+
 // First, set up the 0th (initial) frame
 CursorSP first_cursor_sp(new Cursor ());
 RegisterContextLLDBSP reg_ctx_sp (new RegisterContextLLDB (m_thread, 
@@ -108,6 +111,10 @@
 // cursor own it in its shared pointer
 first_cursor_sp->reg_ctx_lldb_sp = reg_ctx_sp;
 m_frames.push_back (first_cursor_sp);
+
+// Update the Full Unwind Plan for this frame if not valid
+UpdateUnwindPlanForFirstFrameIfInvalid(abi);
+
 return true;
 
 unwind_done:
@@ -161,7 +168,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf ("%*sFrame %d did not get a RegisterContext, stopping.",
@@ -175,7 +189,14 @@
 // See if the regctx below this on the stack has a fallback unwind plan it can use.
 // Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf("%*sFrame %d invalid RegisterContext for this frame, stopping stack walk", 
@@ -187,7 +208,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to 

[Lldb-commits] [lldb] r253042 - Re-XFAIL two more tests I missed

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Nov 13 07:37:53 2015
New Revision: 253042

URL: http://llvm.org/viewvc/llvm-project?rev=253042=rev
Log:
Re-XFAIL two more tests I missed

Modified:

lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py?rev=253042=253041=253042=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
 Fri Nov 13 07:37:53 2015
@@ -27,6 +27,7 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfNoSBHeaders
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
 @expectedFlakeyFreeBSD
+@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_sb_api_listener_event_description(self):
 """ Test the description of an SBListener breakpoint event is valid."""
 self.build_and_test('driver.cpp listener_test.cpp 
test_listener_event_description.cpp',
@@ -38,6 +39,7 @@ class SBBreakpointCallbackCase(TestBase)
 @skipIfWindows # clang-cl does not support throw or catch 
(llvm.org/pr24538)
 @expectedFlakeyFreeBSD
 @expectedFlakeyLinux # Driver occasionally returns '1' as exit status
+@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["x86_64"])
 def test_sb_api_listener_event_process_state(self):
 """ Test that a registered SBListener receives events when a process
 changes state.


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

Re: [Lldb-commits] [lldb] r253026 - Fix to solve Bug 23139 & Bug 23560

[Aggarwal, Abhishek A via lldb-commits]

Hi Pavel

Thanks for pointing out. Both of these tests are passing at my end. I am using 
Ubuntu Desktop (14.04 x86_64) machine and the same compiler version as used by 
build-bot. However, I will have to take a deeper look into the logs you 
attached to figure out the reason of this discrepancy.

Thanks & Regards
Abhishek Aggarwal

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Friday, November 13, 2015 1:06 PM
To: Aggarwal, Abhishek A 
Cc: lldb-commits@lists.llvm.org
Subject: Re: [Lldb-commits] [lldb] r253026 - Fix to solve Bug 23139 & Bug 23560

Hi,

two of the tests you have enabled here are still failing on the linux build bot 
.
I have disabled them for now. I am also attaching full logs from the buildbot. 
I hope that will help you diagnose this. If you need any more info, let me know.

btw, good job on these bugs. I was looking into these a while back, but I 
couldn't figure them out.

pl


On 13 November 2015 at 10:47, Abhishek Aggarwal via lldb-commits 
 wrote:
> Author: abhishek
> Date: Fri Nov 13 04:47:49 2015
> New Revision: 253026
>
> URL: http://llvm.org/viewvc/llvm-project?rev=253026=rev
> Log:
> Fix to solve Bug 23139 & Bug 23560
>
> Summary:
>  - Reason of both bugs:
>
>1. For the very first frame, Unwinder doesn't check the validity
>   of Full UnwindPlan before creating StackFrame from it:
>
> When 'process launch' command is run after setting a breakpoint
> in inferior, the Unwinder runs and saves only Frame 0 (the frame
> in which breakpoint was set) in thread's StackFrameList i.e.
> m_curr_frames_sp. However, it doesn't check the validity of the
> Full UnwindPlan for this frame by unwinding 2 more frames further.
>
>2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
>   fails and FallBack UnwindPlan succeeds in providing valid CFA values
>   for frames:
>
> Sometimes during unwinding of stack frames, the Full UnwindPlan
> inside the RegisterContextLLDB object may fail to provide valid
> CFA values for these frames. Then the Fallback UnwindPlan is used
> to unwind the frames.
>
> If the Fallback UnwindPlan succeeds, then it provides a valid new
> CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
> is updated during the Fallback UnwindPlan execution. However,
> UnwindLLDB misses the implementation to update the 'cfa' field
> of this Cursor with this valid new CFA value.
>
>  - This patch fixes both these issues.
>
>  - Remove XFAIL in test files corresponding to these 2 Bugs
>
> Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
> Signed-off-by: Abhishek Aggarwal 
>
> Reviewers: jingham, lldb-commits, jasonmolenda
>
> Subscribers: lldb-commits, ovyalov, tberghammer
>
> Differential Revision: http://reviews.llvm.org/D14226
>
> Modified:
> 
> lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/embedded_interpreter/TestConvenienceVariables.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/memory/read/TestMemoryRead.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
> lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.cpp
> lldb/trunk/source/Plugins/Process/Utility/UnwindLLDB.h
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultit
> hreaded.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsui
> te/test/api/multithreaded/TestMultithreaded.py?rev=253026=253025
> =253026=diff 
> ==
> 
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMultit
> hreaded.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/api/multithreaded/TestMu
> +++ ltithreaded.py Fri Nov 13 04:47:49 2015
> @@ -17,7 +17,6 @@ class SBBreakpointCallbackCase(TestBase)
>  @skipIfRemote
>  @skipIfNoSBHeaders
>  @skipIfWindows # clang-cl does not support throw or catch 
> (llvm.org/pr24538)
> -@expectedFailureAll("llvm.org/pr23139", oslist=["linux"], 
> compiler="gcc", compiler_version=[">=","4.9"],