[lldb-dev] [Bug 30982] New: check-lldb always fails on an Ubuntu 14.04 machine

2016-11-10 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=30982

Bug ID: 30982
   Summary: check-lldb always fails on an Ubuntu 14.04 machine
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: pe...@pcc.me.uk
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Testing: 557 test suites, 40 threads
 83 out of 557 test suites processed - TestDataFormatterScript.py   

Session logs for test failures/errors/unexpected successes will go into
directory '[...]/ra/lldb-test-traces'
Command invoked: [...]/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable [...]/ra/bin/lldb-4.0.0 -s [...]/ra/lldb-test-traces -S nm -u
CXXFLAGS -u CFLAGS -C /usr/bin/clang --results-port 48706 -S nm --inferior -p
TestLibCxxAtomic.py [...]/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=12:int
FAIL: LLDB (/usr/lib/llvm-3.6/bin/clang-x86_64) :: test_dwarf
(TestLibCxxAtomic.LibCxxAtomicTestCase)
FAIL: LLDB (/usr/lib/llvm-3.6/bin/clang-x86_64) :: test_dwo
(TestLibCxxAtomic.LibCxxAtomicTestCase)
==
ERROR: test_dwarf (TestLibCxxAtomic.LibCxxAtomicTestCase)
   Test that std::atomic as defined by libc++ is correctly printed by LLDB
--
Error when building test subject.

Build Command:
make MAKE_DSYM=NO ARCH=x86_64 CC="/usr/bin/clang" 

Build Command Output:
main.o: In function `std::atomic::store(S, std::memory_order)':
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/atomic:199:
undefined reference to `__atomic_store_8'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [a.out] Error 1

Test Directory:
[...]/lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic
==
ERROR: test_dwo (TestLibCxxAtomic.LibCxxAtomicTestCase)
   Test that std::atomic as defined by libc++ is correctly printed by LLDB
--
Error when building test subject.

Build Command:
make MAKE_DSYM=NO MAKE_DWO=YES ARCH=x86_64 CC="/usr/bin/clang" 

Build Command Output:
clang: warning: argument unused during compilation: '-gsplit-dwarf'
main.o: In function `std::atomic::store(S, std::memory_order)':
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/atomic:199:
undefined reference to `__atomic_store_8'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [a.out] Error 1

Test Directory:
[...]/lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/atomic
--
Ran 2 tests in 0.959s

RESULT: FAILED (0 passes, 0 failures, 2 errors, 0 skipped, 0 expected failures,
0 unexpected successes)

[TestLibCxxAtomic.py FAILED]
Command invoked: /usr/bin/python2.7 [...]/llvm/tools/lldb/test/dotest.py -q
--arch=x86_64 --executable [...]/ra/bin/lldb-4.0.0 -s [...]/ra/lldb-test-traces
-S nm -u CXXFLAGS -u CFLAGS -C /usr/bin/clang --results-port 48706 -S nm
--inferior -p TestLibCxxAtomic.py [...]/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=12:int
557 out of 557 test suites processed - TestTsanThreadNumbers.py 
=
Issue Details
=
ERROR: test_dwarf
(functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py)
ERROR: test_dwo
(functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py)
UNEXPECTED SUCCESS: test_continue_in_watchpoint_command_dwarf
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py)
UNEXPECTED SUCCESS: test_continue_in_watchpoint_command_dwo
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py)
UNEXPECTED SUCCESS: test_dwarf (functionalities/asan/TestMemoryHistory.py)
UNEXPECTED SUCCESS: test_dwarf
(functionalities/thread/exit_during_break/TestExitDuringBreak.py)
UNEXPECTED SUCCESS: test_dwarf (functionalities/asan/TestReportData.py)
UNEXPECTED SUCCESS: test_dwo
(functionalities/thread/exit_during_break/TestExitDuringBreak.py)
UNEXPECTED SUCCESS: test_dwo (functionalities/asan/TestMemoryHistory.py)
UNEXPECTED SUCCESS: test_dwo (functionalities/asan/TestReportData.py)
UNEXPECTED SUCCESS: test_process_interrupt_dwarf
(functionalities/thread/state/TestThreadStates.py)
UNEXPECTED SUCCESS: test_sb_api_listener_resume_dwarf
(api/multithreaded/TestMultithreaded.py)
UNEXPECTED SUCCESS: test_sb_api_listener_resume_dwo
(api/multithreaded/TestMultithreaded.py)
UNEXPECTED SUCCESS: test_with_dwarf

Re: [lldb-dev] Final Result - GitHub Survey

2016-11-10 Thread Chris Lattner via lldb-dev 
On Nov 9, 2016, at 2:53 AM, Renato Golin via lldb-dev  
wrote:
> Folks,
> It's been one week after the initial results were shared and three
> days after the last answer, so I think it's time to close down and
> publish the final results.
> 
> The ODF, XLS and CSV files are at:
> 
> http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip
> 
> The overall result is the same, and it's still in sync with what was
> discussed on the BoF session and I reported back last week:
> 
> GitHub, not only Git, still has a massive support and the split
> between mono/multi repo still exists and need to be sorted out.

Thanks Renato!

Per the extensive discussion on the list and at the Developer Meeting, it seems 
clear that GitHub is the path forward for LLVM.  We still need to resolve 
exactly what that means (mono vs multirepo, etc), but we should take it for 
granted that we’re moving to github.  This will simplify the design space, and 
help focus the discussion.

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

Re: [lldb-dev] LLDB hang loading Linux core files from live processes (Bug 26322)

2016-11-10 Thread Jim Ingham via lldb-dev 
I think that approach is kind of a bandaid.  

Core files can't resume, so it would be better to figure out why telling a core 
file which can't resume to resume caused us to go into a tail spin.  That 
should just fall out of WillResume returning false or some other better general 
signal.  Special-casing core files seems a bit of a hack.

That being said, if nobody has time to make a better solution, a bandaid is 
better than bleeding...

Jim


> On Nov 10, 2016, at 5:53 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I've been hitting a hang when lldb loads some core dumps created on Linux, 
> generally those created via gcore. 
> 
> I found an open bug for this here: 
> https://llvm.org/bugs/show_bug.cgi?id=26322 
> and the fix that was suggested there still works. (The patch needs some 
> tidying up due to the code formatting changes.) 
> 
> I'd quite like to take that change and submit an updated patch via 
> phabricator. Since no-one else has done that so far I was wondering if there 
> was a problem with the approach it took or just a question of time. The patch 
> just adds a flag to say that the process was loaded from a core file and uses 
> that as a simple check to see if lldb should wait for the process to resume 
> or not. Doing that works around changing the logic for working out the thread 
> states. I'm not sure if that's bad as it avoids fixing the thread state logic 
> or good as it allows the core to load without needing to change the thread 
> states from the state they were in when the core file was created. 
> 
> If no-one objects I'll grab the bug and submit a patch, otherwise please let 
> me know and I'll look at fixing it another way. 
> 
> Thanks, 
> 
> Howard Hellyer 
> IBM Runtime Technologies, IBM Systems
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] download page for LLDB at llvm.org

2016-11-10 Thread Mehdi Amini via lldb-dev 

> On Nov 10, 2016, at 9:14 AM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Hi all,
> 
> I just took a look at our page here:
> 
> http://lldb.llvm.org/download.html 
> 
> The LLDB Releases section seems pretty out of date.  It seems like we could 
> correct that via a few different ways:
> 
> * Remove the LLDB Releases section - this would eliminate the appearance of 
> us keeping it up to date (i.e. match what looks to be reality).
> 
> * Start keeping it up to date, at least for the groups that are in fact 
> making occasional builds available.
> 
> * Coordinate with the LLVM folks that do the LLVM binaries, figure out what 
> we need to do to make that happen, and maybe have this page link to the LLVM 
> downloads page.

My 2 cents: I’d like to see lldb getting more of a first class citizen 
(alongside with Clang) in the LLVM project. So having it as part of the LLVM 
release makes sense to me, at least on the medium term.

Best,

— 
Mehdi




> 
> * For those buildbots that do produce usable packages, we could link from 
> here to the build jobs, possibly with a little text on how to make use of it.
> 
> * Something else?
> 
> Any opinions here?  Clearly some of those options above imply work by some, 
> so getting generating usable images generated still may be on a maintainer 
> opt-in basis.  I'm just looking to see us clean up the communication on this 
> page:
> 
> http://lldb.llvm.org/download.html 
> 
> just as a matter of settings expectations for those who land there.
> 
> Thanks for any thoughts on this!
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] [Bug 30969] Merge r283728 into 3.9 branch.

2016-11-10 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=30969

Tom Stellard  changed:

   What|Removed |Added

URL||https://reviews.llvm.org/rL
   ||283728
   Assignee|lldb-dev@lists.llvm.org |clayb...@gmail.com

--- Comment #1 from Tom Stellard  ---
Hi Greg,

I'm not sure who the right code owner is for this, so I'm assigning to you. 
Can you either re-assign to the correct code owner or give your
approval/disapproval for merging this into the 3.9 branch.

-- 
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