[lldb-dev] [5.0.0 Release] Release Candidate 1 source and binaries available

2017-07-31 Thread Hans Wennborg via lldb-dev 
Hello all,

Source, binaries and docs for LLVM-5.0.0-rc1 are now available at
http://prereleases.llvm.org/5.0.0/#rc1

Please try it out, run tests, builds your favourite projects and file
bugs about anything that needs to be fixed (including docs!), marking
them blockers of http://llvm.org/pr33849.

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

[lldb-dev] August LLVM bay-area social is this Thursday!

2017-07-31 Thread George Burgess IV via lldb-dev 
We'll be at Tied House as usual, starting on Thursday the 3rd at 7pm!

If you can, help us plan and RSVP here: http://meetu.ps/3bRM2c

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

Re: [lldb-dev] LLDB tests

2017-07-31 Thread Adrian Prantl via lldb-dev 

> On Jul 24, 2017, at 10:48 AM, Sean Callanan via lldb-dev 
>  wrote:
> 
> Steve,
> 
> since you asked about failures, here are some public bots you can look at to 
> get a general sense of how we are doing:
> 
> http://lab.llvm.org:8011/builders  
> [various platforms]
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/ 
>  [OS X]
FYI, we also have a slightly nicer URL for green dragon that doesn't involve 
nonstandard ports:
http://green.lab.llvm.org/green/view/LLDB/job/lldb_build_test/ 


-- adrian
> 
> https://ci.swift.org/view/All/job/oss-lldb-incremental-osx/ 
>  [OS X]
> https://ci.swift.org/view/All/job/oss-lldb-incremental-linux-ubuntu-16_10/ 
>  
> [Linux]
> There are many more bots, as you'll discover browsing around, but these 
> should give you a good idea of the health of our testsuite at any given time.
> 
> Sean
> 

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

[lldb-dev] [Bug 32362] LLDB master fails to compile with linker error

2017-07-31 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=32362

Vedran Miletic  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from Vedran Miletic  ---
$ make VERBOSE=1 lldb
(...)
[ 56%] Built target lldbTarget 
   
  make -f
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build.make
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/depend 
   make[3]: Entering directory
'/home/vedranm/workspace/llvm/build-master'
cd /home/vedranm/workspace/llvm/build-master && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /home/vedranm/workspace/llvm
/home/vedranm/workspace/llvm/tools/lldb/tools/lldb-server /home/
vedranm/workspace/llvm/build-master
/home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server
/home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server/CMakeFiles/l
ldb-server.dir/DependInfo.cmake --color=
make[3]: Leaving directory '/home/vedranm/workspace/llvm/build-master'  
make -f tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build.make
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build   
make[3]: Entering directory '/home/vedranm/workspace/llvm/build-master' 
[ 56%] Linking CXX executable ../../../../bin/lldb-server   
cd /home/vedranm/workspace/llvm/build-master/tools/lldb/tools/lldb-server &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/lldb-server.dir/link.txt
--verbose=1  /usr/lib/ccache/c++-fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wn
o-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing
-Wno-deprecated-register -Wno-vla-extension -g   -Wl,-allow-shlib-undefined 
-Wl,-rpath-link,/home/vedranm/workspace/llvm/build-master/./lib 
CMakeFiles/lldb-server.dir/Acceptor.cpp.o
CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o C
MakeFiles/lldb-server.dir/lldb-platform.cpp.o
CMakeFiles/lldb-server.dir/lldb-server.cpp.o
CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o  -o
../../../../bin/lldb-server -Wl,-rpath,"\$ORIGIN/../lib" -lpthread
../../../../lib/liblldbBase.a ../../../../lib/liblldbCore.a
../../../../lib/liblldbHost.a ../../../../lib/liblldbInitialization.a
../../../../lib/liblldbInterpreter.
a ../../../../lib/liblldbPluginProcessLinux.a -ledit -lcurses
/usr/lib/x86_64-linux-gnu/libform.so /usr/lib/x86_64-linux-gnu/libpanel.so
-ltinfo /usr/lib/x86_64-linux-gnu/libpython2.7.so
/usr/lib/x86_64-linux-gnu/libxml2.so -lpthread -ldl -lcurses
/usr/lib/x86_64-linux-gnu/libform.so /usr/lib/x86_64-linux-gnu/libpanel.so
-ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr
/lib/x86_64-linux-gnu/libpanel.so -ltinfo
/usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so
-lpthread -ldl -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr/lib
/x86_64-linux-gnu/libpanel.so -ledit -ltinfo
/usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so
-lpthread -ldl -ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.s
o /usr/lib/x86_64-linux-gnu/libpanel.so -ltinfo
/usr/lib/x86_64-linux-gnu/libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so
-lpthread -ldl ../../../../lib/liblldbPluginInstructionARM.a ..
/../../../lib/liblldbPluginInstructionMIPS.a
../../../../lib/liblldbPluginInstructionMIPS64.a
../../../../lib/libLLVMMC.so.6.0.0svn
../../../../lib/libLLVMMipsCodeGen.so.6.0.0svn ../../../..
/lib/libLLVMMipsAsmPrinter.so.6.0.0svn
../../../../lib/libLLVMMipsAsmParser.so.6.0.0svn
../../../../lib/libLLVMMipsDesc.so.6.0.0svn
../../../../lib/libLLVMMipsInfo.so.6.0.0svn ../../../../li
b/libLLVMMipsDisassembler.so.6.0.0svn
../../../../lib/liblldbPluginObjectContainerMachOArchive.a
../../../../lib/liblldbPluginObjectFilePECOFF.a
../../../../lib/liblldbPluginProcessGDBRemote
.a ../../../../lib/liblldbPluginPlatformMacOSX.a
../../../../lib/liblldbPluginPlatformPOSIX.a
../../../../lib/liblldbPluginProcessPOSIX.a ../../../../lib/liblldbCore.a
../../../../lib/liblld
bHost.a ../../../../lib/liblldbInterpreter.a
../../../../lib/liblldbBreakpoint.a ../../../../lib/liblldbDataFormatters.a
../../../../lib/liblldbExpression.a ../../../../lib/liblldbSymbol.a .
./../../../lib/liblldbTarget.a ../../../../lib/liblldbPluginProcessUtility.a
../../../../lib/liblldbPluginCPlusPlusLanguage.a
../../../../lib/liblldbPluginObjCLanguage.a

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

2017-07-31 Thread Eli Zaretskii via lldb-dev 
> From: "Ted Woodward" 
> Cc: 
> Date: Mon, 31 Jul 2017 13:24:31 -0500
> 
> The best thing to do is give us a list of commands that are failing, in a bug 
> opened in Bugzilla at http://bugs.llvm.org .

The URL I provided (after several mistaken attempts ;-) included a
lits of the failing commands.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

2017-07-31 Thread Ted Woodward via lldb-dev 
The original lldb-mi implementation was to get Eclipse talking to lldb. Since 
then there have been other people working on it, and other clients, but lldb-mi 
is not a full implementation of the MI protocol.

The best thing to do is give us a list of commands that are failing, in a bug 
opened in Bugzilla at http://bugs.llvm.org .

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hafiz
> Abid Qadeer via lldb-dev
> Sent: Monday, July 31, 2017 5:04 AM
> To: Eli Zaretskii ; Zachary Turner ; Jan
> Kratochvil ; Eli Zaretskii via lldb-dev  d...@lists.llvm.org>
> Cc: yllumin...@gmail.com
> Subject: Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> 
> 
> >>> Last time I tried, it wasn't "reasonable" enough to start debugging
> >> a
> >>> program under Emacs.  See this discussion for details:
> >>>
> >>> http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html
> >>>
> >>> The failed commands it shows are the initial ones issued by Emacs
> >>> when a debugging session starts.  Without support of these commands
> >> in
> >>> lldb-mi there's no hope for any
> >>> practical debugging using lldb.
> >>> If llvm developers could implement those minimal commands, maybe
> the
> >>> rest would be easier.
> 
> I will try to add those command when my time allows. If there are others that
> are needed to make Emacs work then please let me know or better open a
> bug.
> 
> Thanks,
> Abid
> 
> --
> Hafiz Abid Qadeer
> Mentor Embedded/CodeSourcery
> ___
> 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] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

2017-07-31 Thread Dimitry Andric via lldb-dev 
On 31 Jul 2017, at 19:26, Hans Wennborg  wrote:
> 
> On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric  wrote:
>> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev  
>> wrote:
>>> 
>>> 5.0.0-rc1 has just been tagged.
>>> 
>>> Please build, test and upload binaries to the sftp. Let me know if
>>> there are any issues.
>> 
>> Built and tested rc1.  Test failures on amd64-freebsd10:
>> 
>> FAIL: LLVM-Unit :: 
>> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 
>> 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 
>> 38616)
>> FAIL: AddressSanitizer-Unit :: 
>> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
...
> Do we know what's up with all of these ASan failures? Is there a bug for it?

I spent a limited amount of debugging on it, but the common problem is that on 
i386 (aka 32-bit x86) all programs compiled with -fsanitize=address now die 
with:

==11122==AddressSanitizer CHECK failed: 
/usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36 
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
#0 0x806f163 in __asan::AsanCheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x806f163)
#1 0x805dce3 in __sanitizer::CheckFailed(char const*, int, char const, 
unsigned long long, unsigned long long) (/share/dim/src/misc/hw+0x805dce3)
#2 0x80dfc65 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned 
char) (/share/dim/src/misc/hw+0x80dfc65)
#3 0x80696dd in __asan::AsanThread::Init(void) 
(/share/dim/src/misc/hw+0x80696dd)
#4 0x806997f in __asan::AsanThread::ThreadStart(unsigned long, 
__sanitizer::atomic_uintptr_t*) (/share/dim/src/misc/hw+0x806997f)
#5 0x806ecf3 in __asan::AsanInitInternal(void) 
(/share/dim/src/misc/hw+0x806ecf3)
#6 0x8092785 in clock_gettime (/share/dim/src/misc/hw+0x8092785)

When I put some printfs in there, it showed that the expected address 
granularity is 8, but the address to be checked was aligned on 4 bytes:

DBG: addr=0x284429f4, granularity=8

Tracing back the definitions, I found:

#define SHADOW_GRANULARITY (1ULL << SHADOW_SCALE)

then:

#define SHADOW_SCALE kDefaultShadowScale


then:

static const u64 kDefaultShadowScale = 3;

So this seems to be hardcoded.  There is a similar declaration in llvm's 
lib/Transforms/Instrumentation/AddressSanitizer.cpp.

I know that it *did* work at some point in the past, but it got broken in 
recent history.  I will have to do some archeology to figure out what happened.

Does anybody know whether the shadow granularity was different at some point?

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged

2017-07-31 Thread Hans Wennborg via lldb-dev 
On Sat, Jul 29, 2017 at 4:59 AM, Dimitry Andric  wrote:
> On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev  
> wrote:
>>
>> 5.0.0-rc1 has just been tagged.
>>
>> Please build, test and upload binaries to the sftp. Let me know if
>> there are any issues.
>
> Built and tested rc1.  Test failures on amd64-freebsd10:
>
> FAIL: LLVM-Unit :: 
> ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-with-calls-Test/AddressSanitizer.DoubleFreeTest (2589 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2615 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2651 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-i386-with-calls-Test/AddressSanitizer.WrongFreeTest (2655 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-inline-Test/AddressSanitizer.DoubleFreeTest (2698 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2723 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2762 of 
> 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-inline-Test/AddressSanitizer.WrongFreeTest (2765 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-with-calls-Test/AddressSanitizer.DoubleFreeTest (2808 of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2833 
> of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2870 
> of 38616)
> FAIL: AddressSanitizer-Unit :: 
> ./Asan-x86_64-with-calls-Test/AddressSanitizer.WrongFreeTest (2875 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp (2998 
> of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: 
> TestCases/Posix/asan-symbolize-sanity-test.cc (3000 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/closed-fds.cc (3001 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/deep_thread_stack.cc 
> (3005 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc (3007 
> of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: 
> TestCases/Posix/interception-in-shared-lib-test.cc (3019 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/shared-lib-test.cc 
> (3029 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: 
> TestCases/Posix/stack-use-after-return.cc (3030 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/strndup_oob_test.cc 
> (3035 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait.cc (3037 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait3.cc (3038 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait4.cc (3040 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/waitid.cc (3139 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_big_alignment.cc 
> (3140 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: 
> TestCases/alloca_detect_custom_size_.cc (3142 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_partial.cc 
> (3144 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_right.cc 
> (3146 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_underflow_left.cc 
> (3148 of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_double_free.cc (3163 
> of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_stacks.cc (3167 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_report.cc (3168 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/deep_stack_uaf.cc (3170 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/describe_address.cc (3172 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/double-free.cc (3173 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/frexp_interceptor.cc (3178 
> of 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/global-overflow.cc (3180 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/heap-overflow.cc (3184 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/heavy_uar_test.cc (3185 of 
> 38616)
> FAIL: AddressSanitizer-i386-freebsd :: TestCases/initialization-bug.cc (3188 
> of

Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

2017-07-31 Thread Hafiz Abid Qadeer via lldb-dev 

>>> Last time I tried, it wasn't "reasonable" enough to start debugging
>> a
>>> program under Emacs.  See this discussion for details:
>>>
>>> http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html
>>>
>>> The failed commands it shows are the initial ones issued by Emacs
>>> when a debugging session starts.  Without support of these commands
>> in
>>> lldb-mi there's no hope for any
>>> practical debugging using lldb.
>>> If llvm developers could implement those minimal commands, maybe the
>>> rest would be easier.

I will try to add those command when my time allows. If there are others
that are needed to make Emacs work then please let me know or better
open a bug.

Thanks,
Abid

-- 
Hafiz Abid Qadeer
Mentor Embedded/CodeSourcery
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev