[lldb-dev] [Bug 24772] New: A few remaining bugs in Value / formatter API on Windows

2015-09-10 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24772

Bug ID: 24772
   Summary: A few remaining bugs in Value / formatter API on
Windows
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ztur...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Grouping all these related issues here, even though the underlying causes might
be slightly different.  This covers the following test failures:

TestChangeValueAPI.py
TestSBValuePersist.py
TestStringPrinter.py
TestValueAPI.py

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24777] New: TestStepAndBreakpoints and Thread specific breakpoints broken on Windows

2015-09-10 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24777

Bug ID: 24777
   Summary: TestStepAndBreakpoints and Thread specific breakpoints
broken on Windows
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ztur...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Step and Breakpoints:

Traceback (most recent call last):
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 483, in wrapper
return func(self, *args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 551, in wrapper
return func(self, *args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lang\c\stepping\TestStepAndBreakpoints.py",
line 31, in test_with_dwarf_and_python_api
self.step_over_stepping()
  File "D:\src\llvm\tools\lldb\test\lang\c\stepping\TestStepAndBreakpoints.py",
line 131, in step_over_stepping
self.assertTrue (stop_id_after_including_expressions >
stop_id_before_including_expressions, "Stop ID including expressions increments
over expression call.")
AssertionError: False is not True : Stop ID including expressions increments
over expression call.


Thread specific breakpoints:
Traceback (most recent call last):
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 615, in wrapper
func(*args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 483, in wrapper
return func(self, *args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 551, in wrapper
return func(self, *args, **kwargs)
  File "D:\src\llvm\tools\lldb\test\lldbtest.py", line 736, in wrapper
func(*args, **kwargs)
  File
"D:\src\llvm\tools\lldb\test\functionalities\thread\thread_specific_break\TestThreadSpecificBreakpoint.py",
line 30, in test_with_dwarf_python
self.do_thread_specific_break()
  File
"D:\src\llvm\tools\lldb\test\functionalities\thread\thread_specific_break\TestThreadSpecificBreakpoint.py",
line 72, in do_thread_specific_break
self.assertTrue (next_stop_state == lldb.eStateExited, "We should have not
hit the breakpoint again.")
AssertionError: False is not True : We should have not hit the breakpoint
again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24778] New: XFAIL miscellaneous test failures on Windows

2015-09-10 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24778

Bug ID: 24778
   Summary: XFAIL miscellaneous test failures on Windows
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ztur...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

These are issues that are small enough, yet numerous enough to not warrant a
separate tracking bug for each issue.  

Test11588.Issue11581TestCase.test_11581_commands
TestAttachResume.AttachResumeTestCase.test_attach_continue_interrupt_detach
TestConditionalBreak.ConditionalBreakTestCase.test_with_dwarf_python
TestCrashDuringStep.CreateDuringStepTestCase.test_step_inst_with_dwarf
TestDeadStrip.DeadStripTestCase.test_with_dwarf
TestEvents.EventAPITestCase.test_add_listener_to_broadcaster_with_dwarf
TestFrames.FrameAPITestCase.test_get_arg_vals_for_call_stack_with_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_expr_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_expr_step_and_expr_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_python
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_register_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_step_after_break_dwarf
TestInferiorCrashing.CrashingInferiorTestCase.test_inferior_crashing_step_dwarf
TestInlineStepping.TestInlineStepping.test_with_dwarf_and_python_api
TestLaunchWithShellExpand.LaunchWithShellExpandTestCase.test_with_dwarf
TestLongjmp.LongjmpTestCase.test_step_back_out
TestLongjmp.LongjmpTestCase.test_step_out
TestLongjmp.LongjmpTestCase.test_step_over
TestPluginCommands.PluginCommandTestCase.test_load_plugin
TestPrintStackTraces.ThreadsStackTracesTestCase.test_stack_traces
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_dwarf
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_expr_dwarf
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_expr_step_and_expr_dwarf
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_python
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_register_dwarf
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_step_after_break_dwarf
TestRecursiveInferior.CrashingRecursiveInferiorTestCase.test_recursive_inferior_crashing_step_dwarf
TestReturnValue.ReturnValueTestCase.test_with_dwarf_python
TestSymbolAPI.SymbolAPITestCase.test_with_dwarf
TestSymbolContext.SymbolContextAPITestCase.test_with_dwarf
TestTargetAPI.TargetAPITestCase.test_find_functions_with_dwarf
TestThreadStepOut.ThreadStepOutTestCase.test_step_all_threads_with_dwarf

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

2015-09-10 Thread Bruce Mitchener via lldb-dev 
The error that Ted was seeing is now fixed on SVN HEAD.

 - Bruce


On Thu, Sep 10, 2015 at 12:51 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The community's current plan of record is still to kill the autoconf build
> but there is no definitive timeline on when it will be complete.  But to
> answer your question, yes it is across all projects.
>
> From the LLDB side, I don't know if anyone depends on having a working
> autoconf build for production reasons.  The last time I heard, it was only
> still around because some people were still running autoconf-based
> buildbots.  It's possible I'm forgetting about something or someone, but
> that was my understanding.
>
> On Wed, Sep 9, 2015 at 10:39 AM Rick Foos via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Can you change it to CMake instead of configure?  I know that's not what
>> you want to hear, but the configure build is on its way out, so you're
>> going to have to do this at some point anyway.
>>
>> Zachary, is the decision to drop autoconf across all projects or just
>> LLDB? The last time I proposed a cmake change, I was asked to add the
>> equivalent for autoconf.
>> (if autoconf is deprecated, I have some other builders starting that I
>> need to switch to cmake)
>>
>> Ted, I was going to remove the builder before I left but didn't have
>> time. The tests were not going to be fixed for autoconf builds. BTW
>> hexagon-build-03 is up to date Ubuntu 15.04 if you care about the newer gcc
>> version.
>>
>>
>> - Rick
>>
>>
>> On 09/09/2015 11:56 AM, Ted Woodward via lldb-dev wrote:
>>
>> I took a look at the buildbots; it looks like another buildbot is failing
>> with the same issue – the debian bot,
>> 
>> http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang . It fails
>> the compile at the same place as the Hexagon Ubuntu bot, and it also uses
>> configure.
>>
>>
>>
>> Google has 2 Ubuntu 14.04 bots up that are building lldb using cmake, so
>> ours will be redundant when we switch it to cmake. If there’s no objection,
>> we’ll just take it down.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org
>> ] *On Behalf Of *Ted Woodward via
>> lldb-dev
>> *Sent:* Thursday, September 03, 2015 1:34 PM
>> *To:* 'Zachary Turner'; 'Todd Fiala'
>> *Cc:* 'LLDB'
>> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure
>> on Linux?
>>
>>
>>
>> We forced a clean build because it wasn’t picking up an enum change that
>> affected the swig python bindings, and the objective c problem popped up.
>>
>>
>>
>> I’ve built with cmake on that machine, and it worked. I think the right
>> answer is switch to cmake.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> *From:* Zachary Turner [mailto:ztur...@google.com ]
>> *Sent:* Thursday, September 03, 2015 12:42 PM
>> *To:* Todd Fiala; Ted Woodward
>> *Cc:* LLDB
>> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure
>> on Linux?
>>
>>
>>
>> Can you change it to CMake instead of configure?  I know that's not what
>> you want to hear, but the configure build is on its way out, so you're
>> going to have to do this at some point anyway.
>>
>>
>>
>> On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I haven't seen that one myself.  Are you still seeing it?
>>
>>
>>
>> Is it possible the buildbot's commands are possibly using older/stale
>> object files?  Is distcc/ccache involved?  Does the build force a clean
>> build?  If not, does the issue go away on a clean build?  Is it
>> configure-based or cmake based?
>>
>>
>>
>> Just some thoughts.  Good luck resolving!
>>
>>
>>
>> -Todd
>>
>>
>>
>> On Fri, Aug 28, 2015 at 10:56 AM, Ted Woodward via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Our Ubuntu 14.10 buildbot at
>> 
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing,
>> and I’ve been tasked to fix it because I’m the LLDB guy.
>>
>>
>>
>> It fails with things like:
>>
>> /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/Release+Asserts/lib/libclangCodeGen.a(BackendUtil.o):
>> In function `addObjCARCOptPass(llvm::PassManagerBuilder const&,
>> llvm::legacy::PassManagerBase&)':
>>
>> BackendUtil.cpp:(.text._ZL17addObjCARCOptPassRKN4llvm18PassManagerBuilderERNS_6legacy15PassManagerBaseE+0x21):
>> undefined reference to `llvm::createObjCARCOptPass()'
>>
>>
>>
>> I get the same error when I manually build using the same steps as the
>> bot, but when I use cmake it works.
>>
>>
>>
>> Has anyone seen this behavior using confi